Skip to main content ↑ ↓
Topic: [Request] Edit History Log (Read 5973 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[Request] Edit History Log

Whenever a post is edited , the original text is saved and can be viewed as permission may be set in settings. Either to own or all posts and its set by board.
This feature I have always installed on my MyBB-Boards. It would be nice if Elk would have something similar. May be possible?  O:-)

Re: [Request] Edit History Log

Reply #1 –

This would be a pretty massive plugin, but it would be really nice to have. I think the best way to do it would be to just store the diff.

Re: [Request] Edit History Log

Reply #2 –

There is an addon for SMF named Post History. Maybe this can be a sample to port.

Re: [Request] Edit History Log

Reply #3 –

Quote from: groundup – This would be a pretty massive plugin, but it would be really nice to have. I think the best way to do it would be to just store the diff.
Yeah, that could be a nice technical solution, but it would require a "per word" diff (i.e. an explode(' ', $message) and then diff of that one), otherwise it wouldn't provide much advantages (if I understood why you suggested the diff instead of storing the full message).

Just some thoughts.
It should be possible to write the "core" of the mod by using hooks: integrate_before_modify_post passes the new body and the id of the message, so it would just be a matter of grabbing the original message and do the "diff".
To show the previous revisions, I see two ways: 1) make the "modified by" a link (the same solution used in the mod) and load the previous versions, 2) add a new button to the dropdown of the message buttons. In both cases the hook to use is integrate_prepare_display_context. In case 1 it is possible to modify the $message['modified']['last_edit_text'] value, adding the link to the page where the old versions are displayed (or to attach the event or whatever), in case 2 it is possible to use the $context['additional_drop_buttons'] array, that will add new buttons to the end of the droppy.
In case of the option 1, it may even not be necessary to use a hook at all: it is enough to bind an event via jQuery to the "modified" class and add that way whatever is necessary.

Regarding the features of the addon, I'm seeing it in function on a forum I'm providing support to. TBH for people like me that do quite a lot of typos and come back later to fix them, is a bit annoying. I'd like to see at least a couple or three ways to avoid the message to show: 1) a time-based limit (below x seconds/minutes the message is not added), 2) a group based limit (i.e. admins, or moderators, or whatever are allowed not to show it), 3) separation of permissions/settings between own/any post, 4) consistency of the changes (i.e. a comma, or a typo do not save, more than that save). Yes I know 4 may be controversial, but... honestly, if the limit is three/four characters who would edit tens of times the same message to change the meaning? Just very, very, very few.
Bugs creator.
Features destroyer.
Template killer.

Re: [Request] Edit History Log

Reply #4 –

Why do I write such long and useless messages?... dunno.
Whatever.
Yesterday I saw the title and I started writing few lines of code:
https://github.com/emanuele45/MessageHistory

Nothing usable yet. It should just be able to save the modified messages in another table, it should also be able to show the history, but only if you write the URL by yourself. In other words I (still) have to write the UI for it. :P
Bugs creator.
Features destroyer.
Template killer.

Re: [Request] Edit History Log

Reply #5 –

Cool! Maybe add a field on the messages table, "num_edits" so you can show that without an additional query.

Re: [Request] Edit History Log

Reply #6 –

Good point. nods

ETA: though, thinking about it again, that would require anyway a query, because basicMessageInfo wouldn't be able to grab that new column. Though there is still the advantage that would be a query a lot less expensive (just a SELECT on an index) than the current one.
Last Edit: August 15, 2014, 06:23:27 pm by emanuele
Bugs creator.
Features destroyer.
Template killer.

Re: [Request] Edit History Log

Reply #7 –

That looks like a really good place to add a hook. Pass the SQL and the function parameters to it.

Re: [Request] Edit History Log

Reply #8 –

Yeah, it would, but at the moment it is just one of many functions that query that table, so I'd better wait until all those functions have been consolidated into few, so that we will not have to change hooks or add tons of hooks in the same function working slightly differently ,etc. ;)
Bugs creator.
Features destroyer.
Template killer.

Re: [Request] Edit History Log

Reply #9 –

I found a good candidate to test how Angular.js works! O:-)

https://github.com/emanuele45/MessageHistory/commit/f2204133f8be82f36b1622264f57e96aa91810a6

The interesting thing about Angular, and that could be very handy in Elk, is that the template can be written in php as normal and shown only when necessary.

Again, the addon is not yet finished, but now it shows the history of a message in an overlay! :D
Now it needs to be prettify a bit (i.e. some css styling... that's the part I hate of any addon... anyone want to help? lol).
Bugs creator.
Features destroyer.
Template killer.

Re: [Request] Edit History Log

Reply #12 –

No, just store the diff.

Re: [Request] Edit History Log

Reply #13 –

I never tried, but I feel it would take pretty much an amount of space similar to the PMs, probably less.
PMs takes usually less than one tenth of the messages table.
Considering the headaches to compute backwards the first version of the message (starting from the stored one and applying all the diff backwards) I'll just go on storing the whole message. :P
Of course provide a diff feature is quite a cool thing! ;D
Bugs creator.
Features destroyer.
Template killer.

Re: [Request] Edit History Log

Reply #14 –

Laying in bed watching TV but something along the lines of

Code: [Select]
$result = $db->query('
    SELECT version, when, opcodes
    FROM msg_history
    WHERE id_msg = {int:id_msg}
        AND version > {int:version}
    ORDER BY version',
    ['id_msg' => 62, 'version' => 3]
);

// Didn't feel like writing a sort function here, but it would be sorted by version

// Put the result into an array = $history

$render =  = new cogpowered\FineDiff\Render\Text;
$msg = $original_msg;
foreach ($history as $post)
{
    $msg = $render->process($msg, $post['opcodes']);
}

return $msg;