CMS auto-saving

[silverstripe-issues]

created by: @sminnee (sminnee)
created at: 2012-05-29
original ticket: http://open.silverstripe.org/ticket/7411

---

Raised by Sig as a frequent source of pain when using SS3 for a whole day...

Web applications aren't as stable as desktop apps, and when they crash, it's very frustrating if you lose your content.

There are two ways this could be implemented:

• Auto-click the save button. This has the disadvantage of adding extra network traffic, but prevents multiple copies of content from appearing. However, given the CMS lacks record locking this could lead to accidental overwrites if multiple people were logged into the CMS with the same page open. The best way to address that might be with record locking.
• Save content to localStorage. This limits the extra network traffic and the chance of accidental overwrites, but it does mean that there are now 2 copies of the content, which might get out of sync. Presumably the best way of addressing this would be to discard local content if the record had be subsequently modified, but that may lead to data-loss. It would still be helpful for the use case of "the browser crashed and I logged back in". Unless the glitch that caused you to restart the browser also cleared out local storage. Bugs in server-side auto-saving would at least let you go back through historical versions.

Although I'd be happy to see either approach, I'd probably go with record-locking + server-side auto-saving. The fact that we need record-locking to stop it from being horrible makes it a non-trivial change, though.

• Prerequisite: http://open.silverstripe.org/ticket/7452 (Reducing / eliminating the page refreshes upon saving)

[silverstripe-issues]

comment by: @sminnee (sminnee)
created at: 2012-05-31

---

Hamish says:

I wouldn't go with record locking - it's way too easy to end up with a record locked by someone who's wandered off & left it locked (see: our pain with passwords.kdb). Any sort of algorithm to deal with this, like an auto-unlock after a given time, has it's own problems (user locks, wanders off, comes back to site 3 days later, lock has expired but client doesn't know it, user can still overwrite other user's changes)

We could go with dirty detection + a warning. Keep auto-saving, but on save send the current version that particular client thinks the page is. On the server the version is checked - if it's higher than the client thinks it is, someone else has written to it, so alert the user

Ultimately you have the same issue even without auto-saving. Alice opens page Foo, Bob opens page Foo. Bob saves changes. Alice saves changes, overwriting Bob's changes.

We could also combine the above with local Storage. Again, store the current version in local Storage along with the content. When the page is reloaded, if the version from the server still matches, just reload the content from local Storage. If it's different, alert the user and ask what to do.

I prefer local Storage to auto-saving because the version history looses what little sense it has if you're auto-saving - instead of a few different versions, you'd end up with hundreds of them all 1 minute apart.

[silverstripe-issues]

comment by: @smagnusson (smagnusson)
created at: 2012-06-13

---

Hamish, I think if autosaving lots of versions to DB is the key issue to avoid saving to server, then batch autosaves into one row. E.g. an autosave clobbers the previous autosave for 10 minutes, before beginning a new row in the database.

Also, autosave should occur whenever you leave the editor, e.g. clicking on another page to edit, or leaving the CMS.

Then, users have high degree of faith of whatever they've typed into the CMS will be kept as a draft in spite of user error or browser crashes. Yay :)

[tractorcow]

I like the idea of localstorage persisting unsaved changes; Maybe 5.0 / react cms?

[unclecheese]

Digging up this old chestnut, as it's been on my radar lately. Have moved it to an RFC. Would love everyone's feedback.

[unclecheese]

Closing, as migrated to RFC