The install code had the false Version ;)

new Version attached :)

Thanks. :)

EDIT: Bah!

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

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:

Sorry my Mistake, run the following QUery

ALTER TABLE vb_edithistory CHANGE oldreason reason varchar(255);

Then import the product again !

Greetings Surviver

Thanks Surviver,

Updated and working great!

;)

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 ;)

Updated, works, thanx!

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?
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.)
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.
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).

I will see, waht I can do ;)
This would add 1-2 Querys if you edit a post ... (And not nany user would use ist)
Or does this have to do with the incompatibility between MySQL 4.0 and 4.1 as mentioned here? Yes !
I will add it !
I will fix it ! :)
Why is the size important? ;)
I will check Additional Files, but it is not really a beta Release.
Maybe it has some bug, but its no relly Beta ;)

Thanky for your feedback !

Greetings Surviver

Another way would be have search functions in the Admin CP, with which it would be possible to search for suspicious mass edits of old messages. For example in the same place where the controls for mass undoing the edits would be. Or some other way to view all edits which the users have done (just like there is the Moderator Log to see all moderation actions). The biggest problem might be, that how a large number of edits could be visualized informatively and effectively in a small space.

The feature of sending automatic PMs is not very important (and might not even be the optimal solution to the problem), so don't worry about implementing it yet. Maybe I'll make a custom tool for analyzing the edit actions. In any case I'll first need to experiment a bit to find a good way to visualize the edits, after I've had the edit history in use for some time and gathered real usage data.

I'll keep you informed if I get some good ideas.

Well, since they are VARCHAR fields, I suppose it doesn't take any more space from the database than a VARCHAR(200) would take. So it's not really a problem. Just a matter of style and consistency.

Ok, i will canch it in the new version. Annd i'll add an index ;)

This has not yet been fixed in v1.2.2. Also, the value needs to be escaped. If only single quotes are added to the query, it will make the database vulnerable to SQL injection attack:
I also found that the rest of your the code is vulnerable to SQL injection attacks. You must ALWAYS escape EVERY parameter that is put to an SQL query:

I've attached a version of edithistory.php where the above security holes have been fixed.

All users of PEH 1.2.2 (and below) are STRONGLY RECOMMENDED to apply this patch, or disable PEH.


PS: I noticed that there are more detailed instructions for installing PEH at http://www.my-vb.org/board/showthread.php?t=236 (fortunately I can read German, I'm worried about everybody else ;)). Could you also make the English instructions more detailed? Also, please include the instructions as a text file to the ZIP file, so that it would not be necessary to read this thread for the instructions.

Thank you, this is MY Mistake. I will attache a complete fixed Version in the first post, i inserted your name as co-author ;)

I'll include the Installation Instructions,. but the Problem is, my English is too bad :(

I'll give my best ;)

Greetings SUrviver

Update, Thanks again !

I tried to update it to 1.2.3 (upload all new files and import xml with "allow overwrite") and got:

Database error in vBulletin 3.6.4:

Invalid SQL:
ALTER TABLE edithistory CHANGE reason oldreason varchar(200);

MySQL Error : Unknown column 'reason' in 'edithistory'
Error Number : 1054
Date : Friday, January 12th 2007 @ 09:50:17 AM
Script : xxxxxxplugin.php?do=productimport
Referrer : xxxxxxx?do=productadd
IP Address : xx.xx.xx.xx
Username : xxxxx
Classname : vb_database

EDIT: Got it working by running query

ALTER TABLE edithistory CHANGE oldreason reason varchar(255);

and then doing the import again.

Very nice, perhaps u can add in the explanations that by default NO usergroup can view the historys!! :P

I'll look at this

//I can nnot repoduce the Problem.
It works fine for me ;)

This is Default

Thanks Surviver,

Updated and working :)

I have made all the changes on 3.6.3 but it did not work.
I could not see the edit history link anywhere?

If I want this hack, is it necessary to upgrade the version of vb?

you must use a 3.6.x Version of vB. Did you the Template-Edits and are you sure youzr members have the right rights ?

Greeetins Surviver

Hello,

Nice Script. Thank you.

But I can´t find the link "Edit History" in my Forum.

What might be wrong ?

regards

1.) IT's not active in the specified Forum
2.) The User has not the rights
3.) You didn't the Template Edit

Greetings Surviver

1.) Where can i activate it ?
2.) The User is the Superadmin
3.) Done

1.) AdminCP -> Forum Manager -> Select Forum -> Edithistory Active ?
1.) That has nothing to say. AdminCP -> Usergroupmanager ->Select usergroups -> Post Edit History Permissions

Greetins Surviver

I have followed the setup instructions to the letter:

-uploaded files
-installed product
-modified templates

But I still do not see the option to enable this feature in the Forum Manager >Edit section. I cannot locate the Edithistory Active setting. What am I missing??? I'm looking forward to using this mod.

ST

Hello Surviver,

Thank you very much!
It works now !!

The permissions in the Usergroupmanager was the problem.

have a nice day ! :)

Thats good, thanks ;)

Greetins Surviver

The link to the video does not work.

I uninstalled and reinstalled and got it to work. Nice MOD! Thank you.

ST

I use a customized postbit and I laid out the edit display differently than the coder's.....

Its not much...but it saves room if there are no edits on that perticular post...all are free to use it if they wish :)

With the author's permission i'd like to release it as a template mod too :o

If you like .. Release id as a template mod :)

If I have to update from a previous version what must i do?

Regards

Overite all Files an import the Product again, ALlow Override ;)

Nevermind

This seems to have stopped working for 3.6.6 :(

Can anyone else confirm?

It is working fine for me in 3.6.7.

Works for me too....

You may have reverted your templates to accommodate the changes in the 3.6.6 release...you'd need to reapply them afterwards :)

Just installed it. It works fine for me in 3.6.7.
Here's a change I made.
I edited the phrase to "Edit History" like you can see on the first page. However, I also made use of the $post[editcount] feature by not having the "Edit History" link even show up if there is no edit history. Just a small change, but real handy dandy.


Oh, and I suggest that you add to the readme the fact that you need to allow this for usergroups before it'll work. I was confused at first but started reading the thread and found out that way. Other people might not be so fortunate.