Undo Feature

[svasti]

It is possible to click the name of the backup, which will display the backup's contents.

Wow, I wasn't aware of that.

it's a good idea to develop a prototypal plugin for this purpose first.

I think that's best, because then we know what we are talking about.

So now for 1.6.3 it's just the question if Holger's backup is going to be implemented. Well, yes, I would delete them on logout.

[cmb]

So now for 1.6.3 it's just the question if Holger's backup is going to be implemented. Well, yes, I would delete them on logout.

So I have added the following note in the roadmap now:

Whenever content.htm is modified, a TEMPORARY backup is created, that can be easily restored

[Holger]

Nice that this feature is on the roadmap .

Some thoughts:
would you really save a backup whenever the content gets saved? Shouldn't there be a limit to the amount of backups?
However, deleting the temp-files only on logout will not work, if the user just closes the browser-window.
So maybe it's better to create an additional clean-up after login .

And why won't you keep a (maybe configurable) amount of "step-back-backup files" over the session?
I would put those files in a /temp-folder below /content and if they're there on login, I would use them.
The only issue I could imagine is, when a user changes offline content.htm - but even then it seems not to be a problem.
And even if he made a restore of a "normal" backup - the "step-back" with the last temp-backup seems to be correct to me.

[svasti]

save a backup whenever the content gets saved

How else? That's the trigger. However if only one comma is being changed and the content file is pretty big, hm. What would you propose?

Shouldn't there be a limit to the amount of backups?

Yes, preferably configurable? Default 10?

keep a (maybe configurable) amount of "step-back-backup files" over the session?

+1

put those files in a /temp-folder below /content and if they're there on login, I would use them.

+1
So no deleting the step-back-backup files on logoff, just deleting the last one on adding a new one.

I'd propose that the user will not only be able to go back, but will also be able to go from a step back version again forward to the actual version.

[Holger]

How else? That's the trigger. However if only one comma is being changed and the content file is pretty big, hm.

I just meant that there has to be a limit for the number of backups. Saving the content thousand times should not result in 1000 backups.
Sorry for confusion.

Yes, preferably configurable? Default 10?

+1

So no deleting the step-back-backup files on logoff, just deleting the last one on adding a new one.

IMO that's no problem, so +1

I'd propose that the user will not only be able to go back, but will also be able to go from a step back version again forward to the actual version.

Not sure if that's so easy to do without wasting much more resources.
Just "step back" is fine with me.

[svasti]

I'd propose that the user will not only be able to go back, but will also be able to go from a step back version again forward to the actual version.

Not sure if that's so easy to do without wasting much more resources.
Just "step back" is fine with me.

So a person is editing and there is the content.htm and temp-backups tb1 (newest), tb2, tb3, tb4, tb5, tb6, tb7, tb8, tb9, tb10
Now he wants to go back and t1 becomes the content.htm. What happens to the old content.htm? It could be named tf1 (temporary forward), Now he can do 3 things:

1. going back even further -> content.htm becomes tf2 and tb2 becomes content.htm
2. starts editing and saving -> tf1 gets geleted and the old content.htm becomes tb1
3. goes forward again -> content.htm becomes tb1 and tf1 becomes content.htm

[cmb]

Shouldn't there be a limit to the amount of backups?

Yes, preferably configurable? Default 10?

+ 1

So no deleting the step-back-backup files on logoff, just deleting the last one on adding a new one.

+ 1 (we can use the same the algorithm as for the persistent backups, basically)

I'd propose that the user will not only be able to go back, but will also be able to go from a step back version again forward to the actual version.

Not sure if that's so easy to do without wasting much more resources.
Just "step back" is fine with me.

So a person is editing and there is the content.htm and temp-backups tb1 (newest), tb2, tb3, tb4, tb5, tb6, tb7, tb8, tb9, tb10
Now he wants to go back and t1 becomes the content.htm. What happens to the old content.htm? It could be named tf1 (temporary forward), Now he can do 3 things:

1. going back even further -> content.htm becomes tf2 and tb2 becomes content.htm
2. starts editing and saving -> tf1 gets geleted and the old content.htm becomes tb1
3. goes forward again -> content.htm becomes tb1 and tf1 becomes content.htm

Basically, I like the idea of a full undo/redo feature. However, renaming the files might not be the best idea, because it might be necessary to rename multiple files. Another option might be to store the undo and redo stacks (simple arrays) with the names of the files in the session. This should make the handling of multilevel undo/redo simple. It would imply that the temporary backups are "gone" after the session is destroyed, but that might even be regarded as a feature.

Either way, we have to consider how this functionality could be access by the user. I suggest to have to buttons: "redo" and "undo". I'm not sure where to put them best to avoid wasting screen space.

As we might introduce that in a revision, I suggest that we make at least a working proof of concept, before we finally vote.

[svasti]

I suggest to have to buttons: "redo" and "undo". I'm not sure where to put them best to avoid wasting screen space.

Maybe next to |Meta|Page|... ??
But somehow it must be clear that it is a Serverside redo and not a simple editor redo.
We could use title tags "Serverside redo, going back to the last saved version" and give it a symbol with the letter S,
S<-, S-> ?

[cmb]

Maybe next to |Meta|Page|... ??

Seems be a sensible solution. We could let it float:right, to avoid problems with many tabs in a small template, I suppose.

But somehow it must be clear that it is a Serverside redo and not a simple editor redo.

Somehow you're right. On the other hand that might not be too much of an issue; if the user made changes to the editor content, and clicks (server) undo/redo, he will see the editors warning ("do you really want to leave"). If they had not made any changes to the editor, they could easily revert the undo/redo.

However, I'm still concerned about the lacking POC. On Sunday I started one, but it didn't come far due to the other discussion, and the following security patches, which I had to release. Not sure, if I can catch up till Thursday.

[cmb]

However if only one comma is being changed and the content file is pretty big, hm. What would you propose?

We could save diffs, but that would make the restoration much more difficult. I'm not sure if that's worth the trouble, considering the typical content sizes of CMSimple_XH (less than 1 MB).