My phpBB Summer of Code project involves the implementation of a Post Edit History, that is Post Revisions, system. This is a completely optional feature that keeps track of changes made to posts (each edit is called a “revision”). I have tried to write up a brief but informative post detailing what all is being done in regards to this feature.

As I mentioned, each time a post is edited, a new revision, containing the content of the post prior to being edited, is created and stored in the database. The text is stored in full, rather than as diff instructions, so that we can circumvent any potential issues that could arise (for instance, if a revision is deleted, the diff instructions between the remaining revisions would have to be recalculated, resulting in a potential for unresolveable conflicts).

One issue, however, with storing the entire content of the post each time it is edited is that there is potential for a significant increase in database usage and a decrease in performance for large boards with lots of posts (especially long posts) and active users. To combat this, administrators can configure the maximum number of revisions to save per post, as well as the maximum length of time that any given revision should be stored. After all, how often will you need to view a post 6 revisions ago or see what it said 10 months ago? Old and excess revisions are automatically, periodically pruned. Additionally, the entire post revision tracking system can be disabled, and a new option has been added to immediately purge all revisions from the database. While that may be drastic and ideally will not be used very often, it can help decrease the amount of load put on the server, as well as reduce the volume of content stored in the database.

A new page, revisions.php, is being added to allow authorized members to view and manage any given post’s revisions. By default, when viewing this page, you will see a list of the revisions made to a post, in order, detailing who made each revision, when it was made, and for what reason (if provided). Each revision will have a checkbox next to it, allowing you to mark it for deletion or protection (see below). Underneath the revision list you will see a rendered diff (i.e. a visual representation of the changes made between two given texts) between the oldest available revision and the current post, as it exists on the *_posts table. You will be able to constrain the comparison by selecting a starting point and an ending point. You are also able to view an individual revision, by itself. Lastly, the post can also be reverted to any revision in the list.

In the previous paragraph, I mentioned the ability to mark revisions as protected. In some cases, you may wish to save a previous version of a post. Therefore, revisions can be marked as “protected”, and will not be included in the automatic revision pruning cron tasks, and will only be deleted if done so manually either via the post revisions view page or the mass revision purge option in the ACP.

One application of the Post Revisions system has also been implemented: wiki-style posts. Any user with the “f_wiki_create” permission can mark a post they have made to be a “wiki post”. Once this is done, the post can be publicly edited by anyone with the “f_wiki_edit” permission. When paired with the revisions system, changes can be tracked and reverted as needed. Note that there are separate settings for wiki posts to regulate the total allowable number of revisions per wiki post and the age of wiki post revisions; this way, you can keep track of more history of a wiki post for a shorter or longer period of time than for normal posts.

Well, I’m not done yet, and here is a list of some of the things I have yet to do
– Attachment versioning – I still have to figure out the best way to do this (if at all)
– Stress testing with a large board/userbase
– Figure out what Diff engine to use (I’m currently using PHP FineDiff, but I’m really looking for a UTF-8 compatible one, so if anyone has suggestions, feel free to let me know!)
– Further integration with the viewtopic screen – Currently, most of the revision-related front-end is contained in revisions.php; the only way to get there is from the edit count on viewtopic. So, for instance, I might display a compact list of revisions on a post, or maybe incorporate AJAX in some ways, etc.
– SubSilver2 changes (currently I have only done proSilver)
– More? I’d love to hear suggestions and comments.

For those interested, you may test what I have done so far, follow progressing development, and provide input by viewing the GitHub Pull Request and the RFC Topic (on the phpBB Area51 Development Board).

Thank you for your time!

During Google Summer of Code, I have been working on refactoring the authentication system (login and registration) to allow for login via OpenID providers and Facebook Connect [code]. The system’s old authentication plugins (db, ldap, apache) have all been ported to the new authentication provider system and can be enabled/disabled via the administration control panel. Currently, OpenID is implemented using the Zend Framework 2 OpenID package. The Zend Framework 2 OpenID code, currently does not allow login via Google (a popular OpenID provider), however, support for login via Google should be available by the end of Google Summer of Code. The user interface has been nominally changed from its previous look, however, additional changes to the interface will be made to make logging in via various popular providers more convenient for users.

The current (temporary) login box design.

The current (temporary) registration design.

As can be seen from the images, not much work has been done on styling the interface. It currently is focused on functionality for use in tests. The design of the interface will undoubtedly change before the end of Google Summer of Code.

For the remainder of the summer, I will be implementing login via Facebook Connect and potentially (time permitting) adding general support for OAuth2.0 providers. I will also be writing a wrapper class that will handle old authentication plugins so that they will continue to work while they are being transferred over to the new provider system.

I look forward to continue working with my mentor, Nils Adermann, on the remainder of the project. It has been a great experience so far contributing to phpBB, and although I’m am uncertain of how much time I will be able to commit after this summer, I look forward to continuing to work with phpBB and its community.

During Google Summer of Code, I have been working on Search Backend Refactoring. The project involves minimizing code duplications by improving class abstraction in search backends and integrating PostgreSQL fulltext search [Code] and Sphinx search [Code] into phpBB core. Up till now, the progress has been good with PostgreSQL fulltext search backend already integrated into phpBB 3.1 and Sphinx backend nearing completion too.

The project has been a great learning experience. Apart from learning the various features of Git, I have been able to understand the basics of PostgreSQL and MySQL Databases more clearly. I was introduced to Sphinx during the course of project and honestly I was quite impressed by its performance. All boards running on MySQL and PgSQL databases will soon be able to switch to Sphinx search backend for faster indexing and searching.

Next I intend to start code refactoring and fixing bugs in multiple search backends to provide better search functionality to both users and administrators (by exposing more options in ACP). I will also be writing automated tests side by side to ensure search functionality continues to work correctly.

All this has been possible only because of the timely help I have received from mentors and other team members. They have been patient and appropriately guided me at all times. The overall development experience in the phpBB community has been fantastic, I would love to remain involved and contribute even after GSoC.

During the Google Summer of Code I’ve been working on improving the current attachment system to have a bit more of a modern feel to it. I’m integrating Plupload which has a variety of features such as drag-and-drop, multiple file uploads and an upload queue.

The work has been pretty straightforward and I’ve been getting a lot of help from mentors and other team members so I’ve made considerable progress in a short time. The following screenshot shows Plupload integrated with phpBB and you can also look at the code itself in my pull request:

By the end of it, phpBB users (with modern browsers) should be able to enjoy a much smoother attachment experience without a bunch of page refreshes interrupting their posting or waiting ages for a file to upload only to find out it was too big.

It’s not my first time contributing to an open source project but, surprisingly, one of the most useful things I’ve learnt is actually how to use git properly. There are a huge number of really useful features that I’ve never had to use until I started contributing to a project of this size. It’s given me more than my fair share of headaches and some of my activity history on github is a bit embarrassing now but everyone’s been really patient and helpful and I like to think I’m starting to get the hang of things now.

I’m having a lot of fun and intend to keep contributing to the project long after the GSoC has finished.