[wp-trac] [WordPress Trac] #23220: Extend autosave to use the browser's local storage in addition to saving to the server

[WordPress Trac]

#23220: Extend autosave to use the browser's local storage in addition to saving to
the server
----------------------------+------------------
 Reporter:  azaozz          |       Owner:
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  3.6
Component:  Autosave        |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  autosave-redo   |
----------------------------+------------------

Comment (by azaozz):

 The above patch creates a "local backup system" that stores the content on
 the user's hard disk for 24 hours and has a
 [http://make.wordpress.org/core/files/2013/02/localsaves_screenshot.png
 simple UI] to restore that content if the user ever needs it. As discussed
 in IRC, this may be more than we need. Another concern when using
 localStorage is that anything saved there will stay on the computer's HD
 until deleted which is not ideal for public or multi-user computers where
 all users share the same account.

 In that terms we should go in another direction. The localStorage should
 only be used between autosaves and while saving the post and emptied right
 after.

 The main reasons for loosing content are:

 1. Bad connectivity. The Internet connection is down or is very slow/has
 high packet loss resulting in the server timing out.
 2. Expired login cookies or nonces. This would be handled better when
 #23295 gets in.
 3. JS fatal errors. Most errors occur at page load, but we use more and
 more XHRs that may cause a fatal error and prevent proper saving or send
 empty post content. Relevant when the Visual editor is used.
 4. Browser or computer crash.
 5. Partial or corrupted content (extremely rare).

 Cases (1), (2) and (4) can be avoided by storing the last autosave data in
 browserStorage and re-send it to the server after the connection is
 restored or the user has logged in again. In this case all can be handled
 in the background.

 For case (5) we can add a simple integrity check (`strlen()` should be
 enough) on the post content, verify it in PHP and set a 'success' flag on
 the redirect (next page load). The same flag would be used to delete the
 data from localStorage.

 Case (3) would be harder to catch. Depending on where and when the JS
 error occurs TinyMCE may still work properly. In some cases other
 functions can fail and the textarea can be empty despite that the content
 is still in the editor. So if `$_POST['content']` is empty we should be
 rejecting the save/autosave and perhaps asking the user to reload.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/23220#comment:15>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software