[wp-trac] [WordPress Trac] #32273: TinyMCE results in lost data if post save fails and back button is clicked

[WordPress Trac]

#32273: TinyMCE results in lost data if post save fails and back button is clicked
-------------------------------+------------------------------
 Reporter:  archon810          |       Owner:
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  TinyMCE            |     Version:  4.2.1
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:  javascript
-------------------------------+------------------------------

Comment (by archon810):

 Replying to [comment:5 azaozz]:
 > Replying to [comment:4 archon810]:
 >
 > Right, not exact duplicate, just related. I've repeated the same steps:
 > - Edit or create a post.
 > - Trigger `wp_die()` on attempting to save or update it.
 > - Press the Back button in the browser.
 >
 > At this point the last saved revision (or autosave) is loaded in the
 browser, and the "restore from the data in browser storage" notice is
 triggered.
 >
 > I'm not sure we can do anything more in WordPress to remedy this
 situation. Restoring from the backup in the browser works properly and
 brings the post content back.

 Wait, are you saying it brings the post content that you've edited or the
 post content that was available as of the last recorded db revision, as in
 losing all the changes you've just put in? Because if the latter, that's
 exactly the bug I'm trying to get sorted - WP should save the changes to
 the form using the browser cache and restore than instead of the original
 data. I think it's a TinyMCE issue because the logic there goes through
 the original data and uses JS to populate it in the form, actively
 disregarding any edited form data.

 >
 > > We actually tried to change this otherwise ideal behavior to return
 admin_notices instead, thus saving the revision instead of wp_die()ing...
 >
 > This should work: when the post is being saved (as draft or published),
 you can block updating it in the DB, save it somewhere temporary (post-
 meta perhaps), then load the rejected post_content in the editor when the
 Edit Post page loads after the redirect, and delete the meta.

 That's an idea, but it feels so dirty and prone to breaking. Ughhh. :( But
 without introducing more post states (like published but a new revision
 pending), it's probably the best we can do. However, maybe there's some
 merit in looking into the ability to draft updates to existing published
 posts?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32273#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform