Add-On Releases - Post Edit History (PEH)

Edithistory (1.5.0 B 3)

What does this Modification?
This Modification saves a version of a post if someone edits it. If there are saved edits for a post, you can view the "Post History" and you are able to restore old posts.
Also you can compare saved versions of a post.

Installation
Installation-Instructions are included in the zip-File

What's new in Version 1.5.0 B 2?

In this version i made a lot of improvement: eg. I've overwritten the code, the Ajax Compare function now works properly (Screen #3) and I implented a function to mass restore posts of a user. (Screen #6)

Screenshots

#1
Attachment 71292

#2
Attachment 71293

#3 (Compare saved version)
Attachment 71294

#4 (Usergroup Permissions)
Attachment 71295

#5
Attachment 71296

#6 (Mass Restore posts of a user)
Attachment 71297

Not translated yet
- Admin Help

[HR]ss[/HR]
I only get a blank page after the update, waht can I do?

See the new FAQ
[HR]ss[/HR]

Regards
Surviver

PS: I'm very sorry about my bad english

PPS:If you use it, please klick install!

[Surviver]

Originally Posted by Viper007Bond

Sadly, it doesn't.

Database error in vBulletin 3.6.4:
Invalid SQL:
INSERT INTO vb_edithistory
       (postid, oldtitle, newtitle, oldtxt, newtxt, newreason, oldreason, dateline, edituserid, editusername)
VALUES
       ((366862, '', '', '[post contents removed]', '', '', 1165684492, 13306, '[username removed]');
MySQL Error  : Unknown column 'newreason' in 'field list'
Error Number : 1054
Date         : Saturday, December 9th 2006 @ 05:14:52 PM
Script       : http://forums.finalgear.com/editpost...&postid=366862
Referrer     :
IP Address   : [removed]
Username     : [removed]
Classname    : vb_database

Did you make sure to add in upgrade code that'd ALTER the table?

The install code had the false Version

new Version attached

[Viper007Bond]

Thanks.

EDIT: Bah!

Altering Table edithistory ...
Fatal error: Call to a member function on a non-object in [...]/forums/htdocs/admincp/plugin.php(1941) : eval()'d code on line 3

[Surviver]

Originally Posted by Viper007Bond

Thanks.

EDIT: Bah!

Altering Table edithistory ...
Fatal error: Call to a member function on a non-object in [...]/forums/htdocs/admincp/plugin.php(1941) : eval()'d code on line 3

Ok, Got to ACP -> Plugins & Products -> Manage Products -> Post Edit History -> Edit -> Go -> Version -> Enter 1.2.0 -> Save.

The Import the ATtached Produkt !

Say if it works

Greetings SUrviver

[Viper007Bond]

Version was already at 1.2.0 (guess it never got updated since the import failed).

Importing the file you just attached results in a DB error:

Database error in vBulletin 3.6.4:

Invalid SQL:
ALTER TABLE vb_edithistory CHANGE reason oldreason varchar(255);

MySQL Error  : Unknown column 'reason' in 'vb_edithistory'
Error Number : 1054
Date         : Sunday, December 10th 2006 @ 08:14:17 AM
Script       : http://forums.finalgear.com/admincp/plugin.php?do=productimport
Referrer     : http://forums.finalgear.com/admincp/plugin.php?do=productadd
IP Address   : [removed]
Username     : Viper007Bond
Classname    : vb_database

[Surviver]

Originally Posted by Viper007Bond

Version was already at 1.2.0 (guess it never got updated since the import failed).

Importing the file you just attached results in a DB error:

Database error in vBulletin 3.6.4:

Invalid SQL:
ALTER TABLE vb_edithistory CHANGE reason oldreason varchar(255);

MySQL Error  : Unknown column 'reason' in 'vb_edithistory'
Error Number : 1054
Date         : Sunday, December 10th 2006 @ 08:14:17 AM
Script       : http://forums.finalgear.com/admincp/plugin.php?do=productimport
Referrer     : http://forums.finalgear.com/admincp/plugin.php?do=productadd
IP Address   : [removed]
Username     : Viper007Bond
Classname    : vb_database

Sorry my Mistake, run the following QUery

ALTER TABLE vb_edithistory CHANGE oldreason reason varchar(255);

Then import the product again !

Greetings Surviver

[Nathan2006]

Thanks Surviver,

Updated and working great!

[Viper007Bond]

Ran the query, changed the version number in my admin area to 1.2.1 (so the broken upgrade code wouldn't run), and ran the XML you had attached. Everything works now.

[Surviver]

Originally Posted by Viper007Bond

Ran the query, changed the version number in my admin area to 1.2.1 (so the broken upgrade code wouldn't run), and ran the XML you had attached. Everything works now.

Cool, and Sorry for my Mistakes

[Protonus]

Updated, works, thanx!

[Jackal von ?RF]

At my forums there have been two cases when a user edited all of his messages to remove them from the forums (in one case he had over a thousand messages and it took him two days to edit them). What I've done to them is ban them (removing their right to edit their own posts) and restored all the messages from a backup (takes a couple of hours when writing some SQL scripts manually).

It would be nice if this mod offered the possibility to mass-undo all edits which a user made within a specific time frame. The same way as the prune tools in vB's Admin CP work. It should show all individual edits (before and after editing), when it was done, who edited it, and there should be a checkbox for selecting the edits which should be undone.

It would also be nice for the program to send a PM to the admins/moderators when a user edits many of his old messages in a short time. It should be configurable so, that editing even one old message (for example older than 30 days) would send a PM. Then the moderators could quickly stop the user from editing all of his messages away.

Anyways, thanks for your work. Your script looks promising. I'll try it soon. I first thought about creating a similar script myself, but luckily you had already done the job. (I might even offer some help in adding these features I requested, if I really like your script and I have the time.)

EDIT 1:
I looked quickly through your code (v1.2.1) and noticed the query in \includes\cron\edithistory.php. Wouldn't it look much nicer if it was written like this?

$vbulletin->db->query_write("
	DELETE edithistory
	FROM " . TABLE_PREFIX . "edithistory AS edithistory
	LEFT JOIN " . TABLE_PREFIX . "post AS post ON (post.postid = edithistory.postid)
	WHERE post.postid IS NULL
");

Or does this have to do with the incompatibility between MySQL 4.0 and 4.1 as mentioned here? In that case how about writing it without the "AS" keyword like this? Also there should be a comment which would tell about the incompatibility and why the SQL had to be written in an ugly way. (In any case format the SQL to have less tabs; indentation of one tab instead of eight.)

$vbulletin->db->query_write("
	DELETE " . TABLE_PREFIX . "edithistory
	FROM " . TABLE_PREFIX . "edithistory
	LEFT JOIN " . TABLE_PREFIX . "post ON (" . TABLE_PREFIX . "post.postid = " . TABLE_PREFIX . "edithistory.postid)
	WHERE " . TABLE_PREFIX . "post.postid IS NULL
");

EDIT 2:
Does the field edithistory.postid have an index at all? I noticed quite many queries use it in the WHERE condition, but I didn't find anywhere an index for it to be created. This might create full scans of the edithistory table...

Also, I noticed the following line of code. Since reason is a text field, the value assigned to it should be quoted in the SQL query. It would be a good habbit to always quote the values, even if you know that they are numeric.

$db->query_write("UPDATE " .TABLE_PREFIX. "editlog SET reason = ".$edit['oldreason']." WHERE postid = ".$postinfo['postid']."");

Also, I noticed from my DB dump of vB3.5.x (first install was 2.3.5 or older) that the editlog.reason field is defined as `reason` varchar(200) NOT NULL default '' but in your code you have the oldreason and newreason fields defined as varchar(255). Could somebody with a clean vB3.6.x install check that what the size should be?

EDIT 3:
As somebody already mentioned, there's no need for the cron job to run more often that once a day or week (I think it's now by default once an hour). It's rare that posts get physically deleted, so most of the time the cron job would do nothing. I hope you have checked that it uses indexes correctly and runs quickly. I'm just a bit worried because checking every postid might take some time for a big board... My board has some 300K posts and also boards with millions of posts exist. It would be better to remove those rows from edithistory when a post gets physically deleted, and not in a cron job.


PS: I think you should tick the boxes "Additional files" and "Is in Beta stage" for this mod. Also I recommend you to write more comments in your code (I didn't notice any).