Post Revisions/Edit Log

David K.

Short description: Currently, when a post is edited, the previous contents of a post are lost; the only way to restore the post is to restore a backup, and doing so would restore everything else back to how it was before. I propose implementing post revisions, which will allow users with the proper permissions to view the differences between each edit/revision of a post.

Additional info: http://area51.phpbb.com/phpBB/viewtopic.php?f=7...

About Me

Name: David King

Age: 20

Location: Alexandria, VA

Experience with PHP: On and off since I was around 11, I really got back into it about 3 years ago and have been doing it since.

Experience with phpBB: 3+ years MOD development, Former MOD Team member, Current Development team member

Education: Currently attending Northern Virginia Community College full time (16 credit hours), working towards an Associates of Science degree in Information Technology (will be moving to a 4 year institution to get a Bachelors when I’m done at the community college).

 

Project Proposal

 

A post revision system feature has been discussion for inclusion in phpBB 4.0, in this topic: http://area51.phpbb.com/phpBB/viewtopic.php?f=78&t=32637&start=20 However, I think that it would be feasible to include it into phpBB 3.x if done properly.

 

Ultimately, these are the changes I foresee needing to make in order to implement this feature.

 

First a new table will need to be made, called phpbb_post_revisions. The table will have the following columns:

  • revision_id MEDIUMINT(8) UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  • post_id MEDIUMINT(8) UNSIGNED NOT NULL DEFAULT 0,
  • revision_text MEDIUMTEXT NOT NULL,
  • revision_subject VARCHAR(255) NOT NULL DEFAULT ‘’,
  • bbcode_uid VARCHAR(8) NOT NULL DEFAULT ‘’,
  • bbcode_bitfield VARCHAR(255) NOT NULL DEFAULT ‘’,
  • revision_time INT(11) UNSIGNED NOT NULL DEFAULT 0
  • revision_user_id MEDIUMINT(8) NOT NULL DEFAULT 0,
  • revision_checksum VARCHAR(32) NOT NULL DEFAULT ‘’,
  • revision_reasonVARCHAR(255) NOT NULL DEFAULT ‘’,

·revision_attachment TINYINT(1) NOT NULL DEFAULT 0

 

Also, a new permission will need to be added, as a global moderator permission called “m_post_revisions” with the text “Can view post revisions”. This allows moderators to view a list of revisions, or view each one individually. The permission also allows moderators to switch between revisions and compare the difference between two revisions.

 

Revisions are stored in full, not as diffs. Instead, I propose to use a diff engine to display the changes made between two revisions. I have looked around and like how this one works, https://github.com/gorhill/PHP-FineDiff (it is licensed under MIT, which I believe is compatible with GPL v2), but I will make a decision on which diff engine to use later.

 

The revisions will be accessible through the already-present Post Details module in the ACP, located beneath the Moderator Options block. The revisions listing will contain a link to view each revision as a post, a link to view the diff between two revisions, the fully linked/colored username of the user that made the revision as well as the time at which the revisions was made, and the revision reason, if not blank. There will also be a way (link or button?) to restore a post to a specific revision, either forwards or backwards from the current revision. Speaking of which, the current revision will be clearly marked so there is no confusion. Finally, there will be a link to delete a revision from the list as well (does this need its own permission?).

 

Two problems that could arise from the implementation of this feature are reduced performance when there are a lot of revisions, and (related) a high MySQL space consumption (since each revision is saved in full rather than as a diff).

 

To combat these issues, this feature will have a global kill switch (should it default to on or off?) in the ACP “Post settings” called “Keep track of post revisions”. Turning it off will not delete post revisions and it will not keep moderators from viewing saved revision or from reverting a post to a specific revision; it will simply make sure no new revisions are saved. The feature will not be configurable per forum or per group/user unless we decide that is necessary (I don’t think it is).

 

There will also be a setting in the ACP to allow administrators to specify under which circumstances (if any) post revisions should be automatically pruned. Time is one option (honestly, how many times do you need to revert a revision after it’s been live for a few months? Sure it can be helpful for historic information, but really post revisions aren’t needed after a while), and the admin can specify how long to hold onto revisions. A second option is to prune based on how many revisions are there overall, as well as (potentially) how many revisions each post should have (how often do you need to revert a post to 20 revisions ago?).

 

Benefits of this feature:

·         Allows moderators to undo a change in a post

·         Prevents users from edit-spamming (i.e. a spammer signs up, posts a legitimate post, and then later returns and edits it for the sake of spam. Instead, the post can be reverted and locked from future edits).

·         Improves accountability. When arguments or unpleasant situations arise, there is a log of what was actually said, so that someone cannot edit their post after the fact to make their position look better. (i.e. “he said XYZ” “No I didn’t.. as you can see, my post says “ABC”)

 

Timeline

Personally, I don’t foresee this spanning the entirety of GSoC, however, I am really not the greatest at estimating how long something will take me and then being right about it. But, because I will be working for the stipend and will therefore be devoting the majority of my time to the creation of this feature, it should be done sooner rather than later, especially since I am already familiar with the phpBB code-base and coding guidelines, and already have a firm grasp of how contribution to the project is done. I estimate about a month and a half at most, if it even takes that long.

 

When this feature is done, I plan to finish some of the tickets assigned to me in the tracker, specifically the User Self-Delete one. It is currently shaping up but I have a bit more to do on it. Anyway, since I am a Dev team member, I can pretty safely say that I will always have something else I can be working on if I finish all of this before GSoC ends.