Firefox PHP

Phorum the Future, revisited!

Posted by Brian Moon 
Phorum the Future, revisited!
May 03, 2010 01:04AM
Back in 2007, I started about a thread about the future of Phorum after version 5. That has been nearly 3 years ago. So, what happened to those plans? Well, I started on that plan several times and could never find my way to something I liked. Looking back, part of the reason was that PHP did not have the tools I needed to really make it happen. However, PHP 5.2 and higher has finally brought the feature set and performance that is needed to pull off the things I wanted to do.

I have started doing some work on what may become Phorum 6. I am timid to call it Phorum 6 because even numbered versions of Phorum have been doomed to failure in the past. Ironically, the things that doomed Phorum 4 are the things I am doing now. OOP in PHP was horribly slow and very immature in PHP 4. But, it is much better now.

Essentially, the experimental code is broken down into 3 categories of code:
  1. Data gathering and manipulation - Forum, Message, User objects
  2. Output - Pager creation, Template handling, Date formatting
  3. Application glue - the code that ties the two pieces together.
So, how closely am I following that original plan? Lets quote some stuff from that wiki page and I will grade myself so far.

Quote

In this new world, we would separate the parts of Phorum into independent objects. No one part would require any other part.

Well, "require" is a strong word. I am still working on simply building Phorum as a forum application. So, I have not started working on private messages and the like. When I retrieve user information, I use a User object or in the case where I gather a whole set of user information, I use a function on the primary Phorum object that has hooks in place to allow modules to gather the data instead of the Phorum core.

The way it is written, you could (once they are done) create an application on top of the Phorum stack that only dealt with private messages. To get to a user in the Phorum system, you only need to run about 200 lines of code. You don't have to be in any special directory. No more chdir() stuff. Just include a file and create a new Phorum API object.

Quote

The Phorum Base would be the basic code that supplied the CMS-like functionality for non-embedded Phorum installs. This would include but not be limited to: user system, output control, base admin interface, etc. This would be as slim as possible. It is not the goal of the project to make yet another Drupal, Joomla, etc.

This part has not really been conceived just yet. Not as a separate piece. But, each piece is independent. I have already thought of taking the new Template object for use in other applications. Perhaps my goal needs to be to build my other applications on the Phorum Base. That may help me stay on target.

What is very thin however is the application glue for the actual forum application. This is progressing very well. I could explain it, but just have a look at what is now list.php. I would say that is pretty lightweight. The work is done where it should be (I hope).

One example is something that Maurice was already thinking about and I came up with as well. That is that the template system handles escaping of data and not the core. This keeps the core free from deciding what to escape and when. It is now escaped when it is output. This should help with XSS issues. The core in Phorum 5 makes assumptions about what data a template author will want to use. With this new feature, we can expose as much data as we like to the template and if it is used it will be escaped. If not, we don't incur a performance hit for the escaping.

Quote

Forums - This would be the bread and butter application of the Phorum team. It would use an external user and output control system. This can be the Phorum Base but could also be things like Drupal, Joomla, Wordpress, or any other application that could work with an embedded application.

So far so good I think. There really is no Forum part other than there are objects that represent what makes up a forum. That is forums and messages. Either I was too abstract before I am being too abstract now. I am not sure which.

Quote

Each component should adhere to a well documented and robust API so that other developers could develop components that would work in the same systems.

I am doing my best to stick to a consistent API for every object. For example, the Forum, User and Message objects all have build_urls() and format() methods for handling those parts. get_?? methods return arrays of "objects". If you want to use the array data as an object, each class has a load() method that will take that array and load the data as an object that can then be worked on. A lot of this is for speed. Remember, speed comes first. It would be easy to return an array of objects. But, that would be more overhead.

So, what is left to do? Heh, a crap load. I have only gotten to the point I can read the forum data and show a list of messages. No read page yet. No posting. No forum creation. No user creation of any kind. So, this is still years from being done. There is still time to change directions. Also, the data set I am working with is based on Phorum 5.2. I have not incorporated anything from 5.3 into this. There are also only one or two small minor features added. In short, it is only the beginning.

Brian - Cowboy Ninja Coder - Personal Blog - Twitter
Re: Phorum the Future, revisited!
August 19, 2010 06:13PM
I've just started using Zope's TAL inside PHP using my own XML parser.
The way TAL works actually eliminates the overhead of passing values to a template system.

Why, you ask?

Well, most of the time you do something like this:
Language: PHP
<?php $result = $DB->query(';SELECT message_id AS id, subject, body FROM phorum_messages WHERE forum_id=2';); while ($message = $result->fetch_row()) { $template->set_loop_vars(';messages';, $row); } ?>
You fetch rows and push them into a template array.
Then the template parser converts html into PHP code and then processes the data.

What if you could do:
Language: PHP
<?php $template->forum_messages = $DB->query(';SELECT message_id AS id, subject, body FROM phorum_messages WHERE forum_id=2';); ?>

Yes you can with PHP5!
The trick is to use the Iterator interface as query result object.

Language: PHP
<?php class Phorum_SQL_Adapter_MySQLi extends MySQLi { public function real_query($query, $unbuffered=0) { if (!parent::real_query($query)) { throw new Phorum_SQL_Exception($this->error, $this->errno, $query); } if ($this->field_count) { # SELECT, SHOW, DESCRIBE return $unbuffered ? $this->use_result() : $this->store_result(); } # INSERT, UPDATE, DELETE return true; } public function store_result() { return new Phorum_MySQLi_Result($this); } public function use_result() { return new Phorum_MySQLi_UseResult($this); } }   class Phorum_MySQLi_Result extends MySQLi_Result implements Countable, Iterator { function __construct(MySQLi $obj) { parent::__construct($obj); }   protected $i = 0; protected $row = null; public function data_seek($offset) { return parent::data_seek($offset); } public function fetch_field_direct($offset) { return parent::fetch_field_direct($offset); } public function field_seek($offset) { return parent::field_seek($offset); }   # Countable public function count() { return $this->num_rows; }   # Iterator steps: rewind() valid() current() key() next() valid() current() key() public function key() { return $this->i; } public function current() { return $this->row; } public function next() { $this->row = $this->fetch_assoc(); ++$this->i; } public function rewind() { $this->data_seek($this->i = 0); $this->row = $this->fetch_assoc(); } public function valid() { return $this->i < $this->num_rows; } }
More information about MySQLi: [php.net]

The template code is very simple
Language: HTML
<tr tal:repeat="message forum_messages"> <td> <h4><a href="#" tal:content="message/subject">Phorum the Future, revisited!</a></h4> by <a href="http://www.phorum.org/phorum5/profile.php?14,2">Brian Moon</a> </td> </tr>

A simple "forum" page takes around 20ms (0.02 seconds) to parse and execute with my code on an Intel Duo E6750

Just send me a PM when you're interested in some PHP52 code ;)

[edit] Or try a different PHP approach using the PHPTAL project



Edited 1 time(s). Last edit at 08/19/2010 06:18PM by DJ Maze.
Re: Phorum the Future, revisited!
August 20, 2010 11:28AM
For Phorum I don't really see this pass-em-on-right-away method as very feasible.

Phorum often does quite a bit of processing on the data that was retrieved from the database, before passing it on to the template system. If you do not do that, then for anything more than simple displaying of data, there's a risk of implementing big fat features in the templates to make them work eventually.

Also, what you are doing in the code is not what you are advertising IMO. You claim to remove overhead from the code, but what you actually do, is add a big layer with overhead code. What you did, is removing the overhead of writing a few lines of extra code. Really? Yeah, really. Just count the number of code lines in your two examples and you'll see the difference. You're not only still passing on variables to the template system, but you are doing it in a more complicated way as well.

Despite all that, I agree that having things like the Iterator interface in PHP5 is pretty cool and one can write some nice constructions, however Phorum is not reall about slick OO-based code constructions :-)


Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce
tips for major future version
November 29, 2010 01:51AM
I would like future version to finally
  1. start using database transactions, it will make database writes way faster and fixed some problems with inconsistent data like message post counts.
  2. emit more standard SQL commands. I sent few patches for correcting SQL commands so they are standard and understood by non mysql databases and mysql also but there is no interrest from developers to accept them.
  3. I am willing to contribute IBM DB2 database module, if there is enough interest. (it emits more standard SQL then mysql so it can be used for Oracle and PGSQL as well with minor changes after customizing database specific full text search system).
  4. save draft feature
  5. i wonder if it is possible to have schema upgrades database independent, there are some libraries for doing it

otherwise phorum is really well designed (for PHP coding standard) and fast, it can be integrated into another application very easily due to BSD license, can do threaded view, hook system is very good and modules are great.
Re: tips for major future version
November 29, 2010 03:46AM
1)

where did you find that using transactions makes a database faster? My experience is that it makes things slower.

Transactions can be used to make multiple queries act as an atomic operation. This is mostly useful for rolling back a whole bunch of queries when one fails along the way. It does not fully protect against inconsistency. I can perfectly well start two transactions on two connections and let the second commit wreck the data of the first commit. If you need consistency in situations where race conditions might occur, then locking is the way to go and for the post counts, race conditions is what you are looking at IMO. Locking is not really something that Phorum developers are fond of, since locking is a great way to slow down the application (since requests will start blocking other requests.)

Additionally, I am not aware of any really big inconsistency issues. Even though there are routes through which for example a post counter could be off, I haven't encountered an issue on my live board so far.

2)

"but there is no interrest from developers to accept them" ... excuse me? What does "no interest" mean to you and where did we show this lack of interest?

Some of the constructions in the MySQL db layer are MySQL-specific, no doubt about that. Many of the special constructions that you find in there, are created for the sole purpose of speeding up the application. You praise Phorum for it being fast. Well, there are reasons for the speed. One of them is having a db layer that is tailored to the specifics of the database that we are talking to. But if there are SQL constructions that are not needed to speed things up, then Phorum developer do not mind updating them to standards compliant SQL.

3)

You are welcome to contribute a database layer for DB2. Do note that we do not use it ourselves though, so we'll have to depend on you for doing support and code updates.

4)

Nice feature for a module.

5)

It probably is possible, but because of the reason stated above (tailored db layer), this should not go further than the schema upgrades. Libraries that I know, tend to want to be in charge of everything (including query building and execution), adding a big layer between the application and the database, which is another great way to slow down an application.


Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce
Re: tips for major future version
November 29, 2010 06:23AM
1. Transactions makes writes faster because there is no need to wait for flushing data to database log file after each statement. Flushing logfile is slowest part of transaction. Some operations for example posting new message require several database writes and with transactions it can be way faster on any database systems which flushes logfile at end of transaction. MySQL cheats on this because it can be set in innodb to do only 1 flush per second, but real database systems can not be set that way because there will be possibility of data loss on crash.

Transactions might introduce locking, depending on isolation level, if you want no lock behaviour then go for uncommited read. With uncommited read you will still get transaction atomicity and batched log file updates. It is still better than no transactions at all.

Transactions can guard against race conditions too in serializable isolation level, but it depends how this level is implemented in database. For example in Oracle and Postgresql there is still possibility to do races because they do not implement predicate based locking (used in IBM DB2) so you must do explicit locking (SELECT FOR UPDATE) to work around it. In DB2 no other work is needed except switching isolation level. serializable isolation level is not often used because it leads to deadlocks, so application must be written to retry transactions if deadlocks occurs. Currently most used isolation level in enterprise applications is optimistic locking used by ORM drivers. They add version number to each row in database and use it to simulate serializable level (applications still have to retry transaction) but without locking.

2. You accepted some of my make phorum more db-independent patches, but show no interest in fixing mysql specific syntax sugar. MySQL 5 accepts pretty much standard SQL, so there is no need to use mysql specific syntax now where sql standard syntax will do as well. My submitted patches has nothing to do with performance loss. I talk about ticket 846, 824, 966. Please make clear statement if you are willing to accept these fixes or not, i can send some more.

3. problem with current phorum is that is not too much database independant friendly. submitting oracle and db2 drives (my pgsql driver is untested in production) will require from me to maintain 2x 250KB files and this is quite a lot work. With minor architecture changes, it can reduce db dependant database drivers to tiny files, but it will require to do #2 first. I will write about this later in new thread.

4. i was told 2009-04 on IRC by some phorum dev member that module can not do that due to some missing functionality, modules introduce another challenge to make them database independent if they needs to create own set of tables. Currently there is support for custom profile fields, it probably needs to be extended for per message and per forum custom fields as well.

5. Yes, i wanted it to do schema-only too. I didn't have good experience with php libraries like ADOdb, causes more problems then they solve. I found that best way to do Oracle/Mysql PHP app is to use mini db specific driver and use standard SQL. Similar to design what phorum is using now. Oracle is more difficult then DB2, DB2 PHP driver is very similar to MySQL. MSSQL is hardest to port from MySQL, luckily it does not run on UNIX.
Re: tips for major future version
November 29, 2010 07:22AM
Quote
Radim Kolar
2. You accepted some of my make phorum more db-independent patches, but show no interest in fixing mysql specific syntax sugar. MySQL 5 accepts pretty much standard SQL, so there is no need to use mysql specific syntax now where sql standard syntax will do as well. My submitted patches has nothing to do with performance loss. I talk about ticket 846, 824, 966. Please make clear statement if you are willing to accept these fixes or not, i can send some more.

Thats why the layer is called mysql and not general-sql. Complaining that a ticket from yesterday has not yet been worked on isn't really helpful. And 846 has been put into ideas too - and wasn't declined.
We are looking into your (and others) *changes* but we are not a 100+ people team to do all the work at once or all good ideas at all.


Quote
Radim Kolar
4. i was told 2009-04 on IRC by some phorum dev member that module can not do that due to some missing functionality, modules introduce another challenge to make them database independent if they needs to create own set of tables. Currently there is support for custom profile fields, it probably needs to be extended for per message and per forum custom fields as well.

5.3 aka trunk adds custom profile fields to messages and forums.

Quote
Radim Kolar
5. Yes, i wanted it to do schema-only too. I didn't have good experience with php libraries like ADOdb, causes more problems then they solve. I found that best way to do Oracle/Mysql PHP app is to use mini db specific driver and use standard SQL. Similar to design what phorum is using now. Oracle is more difficult then DB2, DB2 PHP driver is very similar to MySQL. MSSQL is hardest to port from MySQL, luckily it does not run on UNIX.

Like Maurice said, probably possible but not easy for sure. Patches welcome.


Thomas Seifert
Re: Phorum the Future, revisited!
April 06, 2011 01:46AM
So... do all of you think we will see version 5.3 come out by the end of 2011?

I can respect that all you guys have full-time jobs and do Phorum on the side. My concern is that while the core functionality is great, there are new neat features being incorporated into competing forum software. I know there are add-ons and such which I am using.

But I would love to see a mobile version, better Facebook integration, and better SEO, permalinks support for example.

I will say that your small updates always seem to work well. There is something to be said with incremental updates vs. wholesale version updates. I think 5.3 and 5.4 releases would still make many people happy.

Matthew
Re: Phorum the Future, revisited!
April 08, 2011 02:45PM
Yes, I do think that 5.3 will see the light before the end of 2011. Lately, I have been working hard on a new version of my own forum site, based on 5.3. Things are going pretty well and the current 5.3 code base feels stable.

About things that you request:

  • Mobile version: work has been started on that by Brian. This is a first version and it is not yet perfect (especially in the field of compatibility with installed modules), but there is progress in this field. A mobile version does not need a new Phorum version. A large part of mobile is only about writing a useful template. This can be done on 5.2 too.
  • Better Facebook integration: I'm working on authentication integration in the form of a module for 5.3 (which also incorporates integration with twitter and various OpenID services).
  • Better SEO: Please explain what is wrong with that currently. Search engines have no problems finding posts on Phorum websites.
  • Permalinks: Permalinks for what? Permalinks for messages can be done at the template level already. For example a permalink for your message is this one. There has been some discussions on that in the past, e.g. this one.


Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce
Re: Phorum the Future, revisited!
April 13, 2011 11:24PM
I read this article about SMS today and I was wondering whether the Phorum development team ever thought about tuning Phorum to become SMS-ready!? I believe the possibilities could be phenomenal..
Re: Phorum the Future, revisited!
April 14, 2011 01:28AM
I see nothing in phorum that would be needed for it.
Just import SMS messages and turn them into messages and send out SMS messages through the gateway of your choice (there is no common interface for SMS messages). Yes, you need to write a module for it but I also don't see any possibilities with that.


Thomas Seifert
Re: Phorum the Future, revisited!
July 10, 2011 10:31AM
A couple of really simple ideas (that you guys might already thought/did) for 5.3:

First, I'd suggest making signatures a module or preferably keeping it in the code (its such a standard these days) and creating a signature class so that their isn't a need for a module to "format" them. I mean, its not a bad idea to keep the format signatures module, as some may find it useful to add other code to the signatures that way but it might be cleaner. This point is more about my next one really lol.

Second, add a css class for the "edited" post note that gets attached to the posts. This would allow to further customize the boards template... Maybe someone wants a different color or like myself, to make it a smaller font (or even italic).

Third: This idea is already handled in a way with custom profile fields and the banner mod: Have something for code blocks that can be edited easily in the phorum admin interface. This can be used for information that may change more often. It could also be used for custom menus and the like. This would be preferable to updating template files if something is changed more often than not or if and end user isn't comfortable modifying their templates. I just realized how easy this one might be by adapting the banner mod actually.. I'm not sure how well it'll turn out of I try but try I will. Something like this would be nice to be "built-in" though.

The work you guys have done is awesome and thank you! I actually enjoy just playing with this software versus everything feeling like work lol.

~ Be Kind, Please Rewind! ~
Re: Phorum the Future, revisited! SMS notifications
September 23, 2011 08:38AM
Thomas, thanks for your clarification! Working on 5.3 I believe leadership should consider giving users a choice of being notified by email or SMS. I have noticed that this option becomes more and more popular on websites/forums.
Re: Phorum the Future, revisited! SMS notifications
September 23, 2011 09:16AM
There is a choice, there is always a choice.
Just build the module for it if you need it.
Phorum is not and has never been about "it's what the others do too!". It's about what the developers care about and want to put time in.

Of course we can consider it. Just provide us with the details on how to make SMS work for every single of our administrators out there, in every country on any kind of system. Maybe when that is all clearly specified, we could look into how to integrate that into Phorum as a module at some point.


Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce
Re: Phorum the Future, revisited! SMS notifications
September 23, 2011 12:56PM
Just to add: rereading my message above I obviously meant that "I don't see any problems with that.", regarding writing a module to add this.


Thomas Seifert
Re: Phorum the Future, revisited!
September 25, 2011 09:25PM
Quote
Maurice Makaay
Yes, I do think that 5.3 will see the light before the end of 2011. Lately, I have been working hard on a new version of my own forum site, based on 5.3. Things are going pretty well and the current 5.3 code base feels stable.

I was wondering if this optimistic projection remains the same. Some mentioned 5.3 features look very promising.

Although, I am also curious about backwards compatibility with 5.2, as I have my own extremely modified custom template, both on the web side and on the mobile side, that I would hate to have to rewrite from scratch.


Robert Angle
Phorum lover, nothing more.
Ruminations
Re: Phorum the Future, revisited!
September 26, 2011 03:04AM
After various setbacks in the personal field (amongst which some really dirty work because of a broken sewer pit ;-) I have started again on doing fun stuff for my site. I am still optimistic.

For 5.2, we set the goal not to change the templates. There are some new features that require template upgrades, but if you do not have an updated template, Phorum won't break. The feature will simply not be available. Therefore, you could choose to upgrade to 5.3 and put in the missing features at a later time.


Maurice Makaay
Phorum Development Team
my blog linkedin profile secret sauce
Re: Phorum the Future, revisited!
September 26, 2011 03:10AM
Quote
Maurice Makaay
For 5.2, we set the goal not to change the templates.

For 5.3 that is.

Also my phorum hosting is moving to 5.3 (from 5.1 ;)) in around a month which is a nice way to iron out remaining bugs.


Thomas Seifert
Re: Phorum the Future, revisited!
September 26, 2011 01:58PM
Quote
Maurice Makaay
For 5.2, we set the goal not to change the templates. There are some new features that require template upgrades, but if you do not have an updated template, Phorum won't break. The feature will simply not be available. Therefore, you could choose to upgrade to 5.3 and put in the missing features at a later time.

Excellent! My templates resemble nothing like what we started with anymore. I was worried that if I upgraded I would get all kinds of error notices and have to default to "emerald" or something till I had it all figured out again. I certainly don't mind adding new features by hand when the time comes.

Just the new avatar module alone will be a joy. I am always being asked to size down a picture because the user cannot figure out how to do it themselves.


Robert Angle
Phorum lover, nothing more.
Ruminations
Re: Phorum the Future, revisited!
May 07, 2012 08:09PM
Can we get an update on the progress of 5.3?
Are people using it on live sites yet?
I'm really looking forward to the authentication integration!

...
Steve H, currently on: (version 5.2.23)
contributions:
Birthdays mod, Top Users mod, Icon legend.tpl, (plus a handful of bugfixes and old 5.0 creations)
Re: Phorum the Future, revisited!
May 08, 2012 01:57AM
Yes, my forums are all running 5.3 already. Not with the authentication integration though as its a massive hosting site.


Thomas Seifert
Re: Phorum the Future, revisited!
September 08, 2013 05:17AM
Well, I'm not really against it, but what's the gain in doing that change?
I think there is nothing or not much in core depending on jquery itself so it shouldn't break much.

Btw. as I've seen your pull request, just a note: master is supposed to be Phorum 5.3 and there is also a separate branch for phorum 5.2 which is the current stable.


Thomas Seifert
Re: Phorum the Future, revisited!
September 09, 2013 04:18PM
true, but that's why it should be done in 5.3+ and not in the current stable 5.2 ;).


Thomas Seifert
Re: Phorum the Future, revisited!
February 01, 2014 03:23PM
It seem any active development were about 2 years ago.

Is Phorum still active development?

Thanks

[opensourceCMS.com]
[ongetc.com]
Chanh Ong
Re: Phorum the Future, revisited!
February 02, 2014 06:17AM
There is ongoing development every now and then but currently only for a completely new version, not based on the existing code.


Thomas Seifert
Re: Phorum the Future, revisited!
February 24, 2014 03:20PM
Does it mean that there will be no 5.3 version? Will the database become incompatible with a new version? How likely is it that Phorum will cease to exist?
Re: Phorum the Future, revisited!
July 17, 2014 01:06PM
Is there any future for phorum? If not, then we should know that.
I have to move forward and if phorum has stopped evolving, I have to find another solution.

Thank you
Re: Phorum the Future, revisited!
September 24, 2014 06:15PM
In several posts i have read some complains about the lack of new versions of phorum comparing to other forum scripts.
In my opinion phorum has for years already a complete and well working core. All other options are available via the module system and if not, you could write your own and even share it here. same counts for the templatesystem. create your own responsive design and you have a perfect layout too.

The plan was a new version based upon OOP. But this does not mean adding more forum-functionality. OOP maybe better for integration, reliability and maintenance issues, but the procedural codes used now, is still not outdated! You can use it for years. Phorm script can be used for free and for free software it is still amazingly well coded. And yes, sometimes you have to make changes mannually to get it working for some specific needs. So what? It's the price you pay for flexibility.
I myself, am not familiar with OOP but i can do a lot with this "old" version:) .

Remember that in most cases, other (free) forum scripts have many updates on regular base, mostly due to their incapability to write bugfree code. An increasing amount of updates, just means bad coding.....and/or to many options.

Unfortunately, i am not wellknown with OOP, else i should love to code on newer versions of Phorum.
However, i am thinking of adding phorum (with the procedural codes) to my own (still personal) cms (based on procedural codes).
I assume this is not against the license?
Re: Phorum the Future, revisited!
May 07, 2019 12:53AM
9 years later, no signs of life. Oh well. Good luck to those that still believe there's life in this system.
Re: Phorum the Future, revisited!
June 19, 2019 03:43PM
Yeah it looks like Phorum may be dead. Too bad as I currently use it on my site. Looks like it's time to find an alternative.
Sorry, only registered users may post in this forum.

Click here to login