Actual issue here: https://github.com/silverstripe/silverstripe-framework/issues/7498
This is a good idea, so I'll build on it.
Note that this could also possibly cause issues with validation (since validation still occurs on draft save, as it should). This means that an auto-save would have to be it's own separate action that would need to be able to suppress validation when executing.
Personally I'm not too worried about auto-save creating too many versions. In fact, you should probably just ensure that an auto-save (now it's own action) doesn't create multiple separate versions, but just maintains one separate record, separate from draft, _Versions and separate from _Live. I also think that another reason why auto-saved content is best kept separate from from draft is because if it's stored in the main table (the draft table) then it should be validated.
Auto-saved content is "cutting edge", it's not validated nor is it intended to be, it's only a backup in case of failure. The next step is figuring out:
- How to handle presenting auto-saved content to user (in case we think we are now in recovery).
- How to handle when user leaves page *intentionally* without saving.
Both could likely be handled in UI/UX by presenting a small but easily visible yellow banner at the top indicating that an auto-saved version which is newer than the draft version is available and can be recovered by clicking a button. If you save your current draft or continue editing the current draft, after enough changes to that current draft, the auto-saved version could be overwritten (intentionally) with the current auto-saved version.
Please subscribe to the Github issue: https://github.com/silverstripe/silverstripe-framework/issues/6202
Original issue: https://github.com/silverstripe/silverstripe-cms/issues/1227
Originally posted here: https://github.com/silverstripe/silverstripe-framework/issues/5762
Implemented as a module: https://github.com/patricknelson/silverstripe-migrations/
SilverStripe have planned this item
Re: Mar's comment on extensibility for *core* classes.
Has anyone put much thought into exposing core functionality via service providers + facades, similar to how this is done in Laravel? I noticed that when I needed to roll out a modification to how something in the core worked, it was as simple as extending some of the core classes with my own classes, setting up a new service provider to point to that class and then update the facade alias (in bootstrap config) to point to my custom implementation instead of Laravel's default. It's pretty simple and it covers all of these bases.
Here's my +1. For the record, I'd recommend an implementation that exposes the <option> HTML as actual instances of (i.e. descended from) the Field PHP object, so that it's more extensible and inherits more functionality for more edge cases other than just this one.