Every time add or edit a page in the panel a new revision is created.
Much more information here:
REQUIRES KIRBY 2.3 BETA
This is how the folder stucture looks like:
https://raw.githubusercontent.com/jenstornell/kirby-revisions/master/docs/system.png
This is how the field looks like (optional):
The big thing here is not the field. It’s what is happening to the revisions on the system.
Now when I have it I don’t think I could build a site witout it.
Feedback greatly appreciated!
Looks good, I’ll have to try it. 
Maybe it would be better to use a less technical name for panel users. Something like “Older versions” or “Previous versions”.
As a plugin name instead of “Kirby Revisions”, you want it to be called “Kirby Older versions”?
No the plugin name is alright. Developers will know what a “revision” is. But the developer-friendly name is not necessarily what non-dev users should see.
So I’m suggesting using “Previous Versions” as the field title in the panel.
Yes, that can be set to anything as label in the blueprint:
fields:
revisions:
label: Revisions
type: revisions
But maybe update the screenshot and docs a little then.
Wow another plugin from you Where do you find the time to be so active on these things? 
.This thing is very helpful by the way, i’m going to try it!
what is the Function From your Plugin?
Thanks! I need these plugins in a soon future myself so I’m thinking, I’ll try to write them well for everyone. If I get lucky someone will contribute in one way or another.
@thesmithy
I don’t understand your question. If you mean how to run it, the hooks are activated as soon as you drop the plugin in the plugins folder.
no i mean, what does this plugin
Yes. I really should explain this better in the docs.
They are all stored in a folder called revisions.
It’s like a backup. If you by accident saved and things was lost on the page content you will probably find an old version of it in the revisions folder.
okay i think now i understand it a little bit better, and what is in the file that be created in revisions
It’s a copy of the content text file, like a copy of default.txt if that is what your filename is.
really cool idea
I’m looking at the code a little bit. It looks like a great start (and a lot of work, congrats!). I have a few remarks.
plugin.revisions. prefix, instead of just revisions.?Revisions name, and having classes like RevisionContent. Or maybe, more likely, Kirby using that name internally at some point. Maybe using a namespace could help? (Like namespace RevisionsPlugin; or maybe namespace Kirby\Plugin\Revisions.)kirby()->roots()->site() . DS . 'revisions')? That way it’s already protected from direct access with the default .htaccess.I still need to install and try it to see what happens when you click on a revision’s link.
Config keys: maybe use a plugin.revisions. prefix, instead of just revisions.?
Maybe, maybe not.
My plugin name is revisions so that’s my prefix right now.
I’m aware of a potentially collision with the core if revisions are re-invented there. But if there would be revisions in the core we should probably use the core feature instead.
It’s also possible for other plugins to collide with the revisions prefix, but maybe the other plugin is prefixed plugin.revisions. I will never be collision safe against other plugins.
We had a discussion about this hard solved topic:
forum.getkirby.com/t/suggestions-for-kirby-options/3799
I wouldn’t bet against some PHP lib already using the Revisions name, and having classes like RevisionContent. Or maybe, more likely, Kirby using that name internally at some point. Maybe using a namespace could help? (Like namespace RevisionsPlugin; or maybe namespace Kirby\Plugin\Revisions.)
I will look into it. I added an issue about it.
Maybe the default folder for revisions should be kirby()->roots()->site() . DS . ‘revisions’)? That way it’s already protected from direct access with the default .htaccess.
Interesting idea. The default is the root because that’s where content, thumbs and cache are stored. Revisions are a kind of content and almost like a cache.
I’m not sure about add it to the site folder just because it’s protected by htaccess. I think the folder structure will be a little off. But it can be changed in the config if you are not happy about the path.
But this still gave me a thought. I will add some docs about how to add a row in the htaccess about revisions as well as a comment about the alternative to put it into one of the protected folders.
I still need to install and try it to see what happens when you click on a revision’s link.
Don’t expect too much. The big thing is not the field, it’s what happends behind the scenes.
Thanks for all your opinions. They are of great value!
Not a relevant argument IMO. Collisions with Kirby core are more critical and would affect many more users of your plugin than a collision with another plugin. If you can avoid collisions with core, does it really matter that it doesn’t also avoid a different class of problems?
(I chimed in in that topic you mentioned.)
Sounds good. 
Collisions with Kirby core are more critical and would affect many more users of your plugin than a collision with another plugin.
Agree. I added an issue.
Prefixed config and classes are included in this release.
Another thing is that the panel hooks continue to work, even if file permissions in the revisions folder is not writable. The idea is that the panel should always work regardless of what happends with the revisions.
More info in the changelog.
is it possible to disable the ‘delete’ action of the revisions plugin. so revisions are not removed if someone accidentally deleted a page?
No, not at the moment but I think it would be a good idea to make that optional.
I’ve added an issue: