[RFC] Post Revisions

[Pony99CA]

My two cents:

If an owner edits their own post I don't care.

If a non-owner edits the post then I do care. For example, I don't want a moderator or admin editing someone else's post without recording why. The post revisions process takes care of the "what" and "when" of the event, but not the why.

I agree with that for normal posts. However, I think that Wiki posts should always require a reason for editing, even by the owner. Those are probably meant more for reference, so each revision should have a reason.

Steve

[Pony99CA]

Code is written in lines. Posts aren't lines but rather are paragraphs. If you go with line diff, you're basically doing a paragraph diff. For example, this entire series of sentences is only one line so if I edit only one word in the entire paragraph, then the line-diff process will show the entire paragraph as being updated.

Remember that posts can have CODE tags in them.

Also, is there a reason that we're using PHP FineDiff instead of the Diff engine from the phpBB Updater? That allows several ways to view changes and I presume supports UTF8. (I skimmed the topic -- except for the IRC parts -- so if I missed the reason, just link me to the post.)

Also, while I like the idea of the Diff, the Revisions blog post says that it will be "between the oldest available revision and the current post". I don't think that's sufficient -- I want to be able to select any two revisions and see the diff between them. I think that I would often more interested in the diff between the current and next-to-last than the current and oldest versions. The default should either be between current and oldest (as it is now apparently) or between current and next-to-last.

Steve

[Pony99CA]

The Revisions blog post says that protected revisions "will only be deleted if done so manually either via the post revisions view page or the mass revision purge option in the ACP".

That's fine, but I hope that the Purge feature will also have an option to keep protected revisions. It's similar to having the option to keep or delete posts when pruning users.

Steve

[imkingdavid]

Code is written in lines. Posts aren't lines but rather are paragraphs. If you go with line diff, you're basically doing a paragraph diff. For example, this entire series of sentences is only one line so if I edit only one word in the entire paragraph, then the line-diff process will show the entire paragraph as being updated.

Remember that posts can have CODE tags in them.

Unfortunately, it really isn't smart enough to differentiate between text within and without the code tags. Also, diffs are shown between the decoded text, not the parsed text. So when you view the diff, you see all the bbcode tags, but they are not parsed. This may change, but I figured that would be the best way to do it (otherwise, how do you show that the bbcode tags themselves were changed?).

Also, is there a reason that we're using PHP FineDiff instead of the Diff engine from the phpBB Updater? That allows several ways to view changes and I presume supports UTF8. (I skimmed the topic -- except for the IRC parts -- so if I missed the reason, just link me to the post.)

I was told to not use the one already shipped with phpBB already it is not UTF-8 compatible. That being said, the PHP FineDiff is also not UTF-8 compatible, so it is not a permanent solution either. I am just using it so there is something during the development process. The problem is, there isn't a very large selection of good Diff engines written in PHP out there.

Also, while I like the idea of the Diff, the Revisions blog post says that it will be "between the oldest available revision and the current post". I don't think that's sufficient -- I want to be able to select any two revisions and see the diff between them. I think that I would often more interested in the diff between the current and next-to-last than the current and oldest versions. The default should either be between current and oldest (as it is now apparently) or between current and next-to-last.

The default is currently between the oldest available (i.e. usually the original post text, if that one has not been deleted) and the current post. You will be able to manually set a revision range to compare between (you can currently do it via the URL manually, but eventually there will be a way to easily select the starting point and ending point in the comparison).

[Pony99CA]

Code is written in lines. Posts aren't lines but rather are paragraphs. If you go with line diff, you're basically doing a paragraph diff. For example, this entire series of sentences is only one line so if I edit only one word in the entire paragraph, then the line-diff process will show the entire paragraph as being updated.

Remember that posts can have CODE tags in them.

Unfortunately, it really isn't smart enough to differentiate between text within and without the code tags. Also, diffs are shown between the decoded text, not the parsed text. So when you view the diff, you see all the bbcode tags, but they are not parsed. This may change, but I figured that would be the best way to do it (otherwise, how do you show that the bbcode tags themselves were changed?).

For many BBCode changes, you'd see that they were changed by the effect -- text was normal before, now it's bold. The only two standard BBCodes that I can think of that might not show a change are URL= (if you change the hyperlink and keep the text the same) and IMG (if you change the URL but the image looks the same).

If that's not sufficient, you could always try wrapping CSS around changed items to display a border or different background color.

Also, while I like the idea of the Diff, the Revisions blog post says that it will be "between the oldest available revision and the current post". I don't think that's sufficient -- I want to be able to select any two revisions and see the diff between them. I think that I would often more interested in the diff between the current and next-to-last than the current and oldest versions. The default should either be between current and oldest (as it is now apparently) or between current and next-to-last.

The default is currently between the oldest available (i.e. usually the original post text, if that one has not been deleted) and the current post. You will be able to manually set a revision range to compare between (you can currently do it via the URL manually, but eventually there will be a way to easily select the starting point and ending point in the comparison).

OK, that sounds good.

Steve

[Pony99CA]

By the way, I love the Wiki concept, so kudos to whoever suggested it. I don't know that I'll use revisions much, but I've seen the need for Wiki posts (generally in the first post of reference topics).

I just want to confirm a couple of things.

First, if somebody has Wiki creation permissions, I presume that there will be a "Make Wiki post" option on the posting page (similar to the Sticky/Announcement/Global Announcement options) and that will also allow me to convert existing non-Wiki posts into Wiki posts, right? If so, who will be able to turn posts from a Wiki post back to a normal post -- nobody, only those with Wiki creation permissions and/or those with Wiki editing permissions, only moderators or something else?

Second, will there be some kind of indicator that a topic contains Wiki posts and that a post itself is a Wiki post? If so, will those indications be available even to those people who don't have Wiki editing permissions (in other words, will people without the editing permission know that the topic contains Wiki posts and that a post is a Wiki post)?

Finally, will there be any options for sorting Wiki posts (like making them sticky in a topic so that they are displayed first or at the top of each topic page)?

Steve

[imkingdavid]

Code is written in lines. Posts aren't lines but rather are paragraphs. If you go with line diff, you're basically doing a paragraph diff. For example, this entire series of sentences is only one line so if I edit only one word in the entire paragraph, then the line-diff process will show the entire paragraph as being updated.

Remember that posts can have CODE tags in them.

Unfortunately, it really isn't smart enough to differentiate between text within and without the code tags. Also, diffs are shown between the decoded text, not the parsed text. So when you view the diff, you see all the bbcode tags, but they are not parsed. This may change, but I figured that would be the best way to do it (otherwise, how do you show that the bbcode tags themselves were changed?).

For many BBCode changes, you'd see that they were changed by the effect -- text was normal before, now it's bold. The only two standard BBCodes that I can think of that might not show a change are URL= (if you change the hyperlink and keep the text the same) and IMG (if you change the URL but the image looks the same).

If that's not sufficient, you could always try wrapping CSS around changed items to display a border or different background color.

But diffs aren't side-by-side, it's all in one place. So if I were to do what you're suggesting, you'd also need to open the first revision in another tab by itself to see which BBcodes were changed. Personally, I think that how I have it (displaying the changes with the bbcode unparsed) is the best way to go.

[imkingdavid]

First, if somebody has Wiki creation permissions, I presume that there will be a "Make Wiki post" option on the posting page (similar to the Sticky/Announcement/Global Announcement options) and that will also allow me to convert existing non-Wiki posts into Wiki posts, right? If so, who will be able to turn posts from a Wiki post back to a normal post -- nobody, only those with Wiki creation permissions and/or those with Wiki editing permissions, only moderators or something else?

The way it is currently, I have added a new checkbox to the "Options" tab below the posting editor box (above the topic review). If checked, the post behaves as a wiki post. If unchecked, the post behaves as a normal post. Anyone who can edit that post and has f_wiki_create can change that setting.

Second, will there be some kind of indicator that a topic contains Wiki posts and that a post itself is a Wiki post? If so, will those indications be available even to those people who don't have Wiki editing permissions (in other words, will people without the editing permission know that the topic contains Wiki posts and that a post is a Wiki post)?

Currently there is not an indicator on the post or the topic noting that it is/has a wiki post. I plan on adding one, but have not decided what would look best. Suggestions?
As for who can see that a post is a wiki post, I think it should be viewable to anyone who can see the post. Otherwise, you get questions from people who don't know about the wiki-post, of why a post potentially was last edited by a non-moderator who is also not the author of the post.

Finally, will there be any options for sorting Wiki posts (like making them sticky in a topic so that they are displayed first or at the top of each topic page)?

I don't really like the idea of having sticky posts within a topic, and I don't think that falls within the scope of this feature. As for sorting, I can probably add a filter of some sort.

[EXreaction]

After trying it out:

ACP->Old revision pruning frequency, Excess revision pruning frequency
default is 0 seconds, the explanation could maybe be more descriptive, especially at 0 seconds. Seconds between running the tasks seems rather short as well, would hours or days be more fitting? Maybe the user shouldn't have to set this at all?

One thing that is mentioned is that the oldest revision is removed when things are pruned to make room for newer revisions. I think that a good option might be to always keep the very first revision of the post, and then delete old ones starting with the second oldest, if it's fairly easy. My thought behind this is that the posts in between are probably more likely to be corrections to spelling and such, and keeping the very first might be useful when looking back to see what happened to a post.

"Can view and manage own post revisions"
Are users able to delete post revisions and such with this permission setting? On my own board, I would like to allow users to view their own revisions and revert them, and possibly even see the revisions of other user's posts, but I definitely would not want to let them delete revisions. One of the reasons for post revisions is to make sure users can't get away with saying things, then hiding them by editing the post before a moderator or administrator sees it.

I would do the post revisions permissions like such:
Forum level:
Can view own post revisions (can view the post revisions and revert the current post back to any one of them)
Can view other's post revisions (can view the post revisions)

Moderator level:
Can view post revisions (can view the post revisions and set any to "protected", maybe even just use the Can view post details setting for this)
Can edit posts && Can view post revisions (can view the post revisions and revert the current post back to any one of them)

Does setting a revision as protected count against it's total number of revisions saved? It could cause some problems if it does (I did not look).

I think having the feature to delete revisions might even be unnecessary. If the administrators are worried about space, more strict limits on the number of revisions saved would do a far greater job then manually going in and pruning a few revisions, which would take forever and not really do much good without significant time. Having a log of edits is one of the reasons post revisions are so helpful, so the ability to remove things should be given out carefully, and without being able to directly delete, the only option would be to flood messages until the revision limit is reached, which would be very suspicious (but then at least there would be that trace).

I would also add an administrative permission for editing revision settings, since a lower level bad administrator could fairly easily switch the revision history off and do a lot of damage after the fact.

Looks really good so far, I'm looking forward to having this feature available.

[drathbun]

I think having the feature to delete revisions might even be unnecessary. ... Having a log of edits is one of the reasons post revisions are so helpful, so the ability to remove things should be given out carefully, and without being able to directly delete, the only option would be to flood messages until the revision limit is reached, which would be very suspicious (but then at least there would be that trace).

Agreed. In my opinion, I would not provide the ability to delete / prune revisions at all. If a post is deleted then obviously all traces of the post are removed, including revisions (soft delete being another discussion) but I don't see any reason to provide a delete feature, or frankly even a revision limit feature. Disk space is probably the last worry of most board admins. I know it's not even on my radar, and I run a board that's coming up on 800K posts.

Can someone fill up the revisions table with thousands of pointless revisions? Ok, yes. But how is that different from someone filling up the post table with thousands of pointless posts? Both have the same impact (filling up a table with useless stuff), it's just that one is more visible than the other.

As I have mentioned a couple of times, I've built this for my phpBB2 board, and there is no delete feature, nor will I put one in. I agree with EXreaction in that it's not necessary.