As I mentioned in the thread @Jan cited, IMHO revisioning only makes sense if the versions are accessible/comparabe via the panel, at least for all editors who only have access to the panel and not necessarily to the file system.
Maybe it reminds of the thumbs or the cache folder and yes it would be.
Additional hooks would be for deleting, renaming and changing template. That to always keep in sync.
The revisions is not a part of the content folder, which means it does not slow down your site.
By limit to like 2 or 10 revisions the site will not grow forever.
Because the folder structure is the same as in content, it’s easy to see what it is even for the human eye.
The dates are a human friendly kind of timestamp.
Multi language support.
To really make this useful a field would be required to show the revisions for the current page in the panel. Clicking on a revision could bring it back, after asking the user first.
My idea is that only the text is used for revisioning. That’s the only thing you edit in the panel. Even if there are images, they are not edited in any way. It also would be much faster to just save a text file than save a whole folder complete with images.
Do you want a plugin like this? Should I build it, or some kind of collaboration? @1n3JgKl9pQ6cUMrW?
That would be a really good feature to have. I might be able to help test and perhaps write bits of it.
You probably would need to move versions on the panel.page.move hook, because otherwise if the editor decides to rename a page’s slug… the revisions would be lost. But it might get a bit tricky.
Bastian has written previously that he had thought about versioning a few times, but it would add a lot of complexity so he’s not keen on going along with it. Writing a plugin as a proof of concept would be interesting, at the very least.
I think a plugin would be great. Integrating this into the core would increase complexity by a lot, but a separate plugin can’t be wrong here, so I think experimenting with this in a plugin would be cool.
I’m curious what you can make.
One idea though: Maybe it makes sense to listen for file hooks as well. And then on every hook besides the page move hook, you just copy the whole directory (excluding subdirectories) of the page to the revisions directory so that files are backed up and versioned as well.
Also one potential issue we need to think about: What about subpages? Subpages are stored in their parent’s revision directory, so what should happen if the parent page is changed? The subpages definitely need to be preserved somehow.
What is making the versioning of files an option which is turned off by default? This way, people who really need it could turn it on if they really want to…
Theoretically, you could have a subpage/child called ‘revision’, than the model would break… maybe just add an underscore before the date? This usually isn’t possible in the panel and should be safe to use. Every other key word could be used by a child otherwise and break the whole thing.
Another interesting point is definitely the user interface. Will you be able to restore single fields as well as the whole page? Or just “klick-and-restore-last-revision”? This change should also be undoable, so you also always need to store the current version as revision… and, a problem I have seen lately, was that hooks currently can’t access old data, so you’d need some kind of compare-fields. Lot’s of things to be aware of… here is @texnixe’s approach which I used (and which works like charm ;)): Listen to certain page changes in hooks
Great idea by the way, would love to test this out
Diff is not mandatory, but I thought sometimes we may want to revert a single field, not the whole page. Being able to display a previous version and simply copy/paste the content of a field could be useful.