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!