[wp-trac] [WordPress Trac] #39896: Customizer: Allow users to Draft changes before Publishing

[WordPress Trac]

#39896: Customizer: Allow users to Draft changes before Publishing
-------------------------+------------------------------
 Reporter:  melchoyce    |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Customize    |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  ui
-------------------------+------------------------------

Comment (by westonruter):

 In terms of how to implement drafting as proposed here technically, this
 is what I have in mind:

 After you hit Save Draft, and then leave the customizer, if you come back
 to click Customize and go straight to `customize.php` you would get the
 previous drafted changes restored. Currently each time a user starts
 customization a new changeset is spun up into existence with a unique
 UUID. So potentially instead of creating a new UUID, we could instead
 first query the changesets to see if there is a draft and instead use it
 instead. This behavior should be customizable by plugins (e.g. Customize
 Snapshots) so that concurrent non-linear drafts of changes could be made.
 But in core, only one draft would normally exist at a time, for the
 initial iteration.

 When you start a new customization session from scratch, as you make
 changes those changes currently get autosaved into the `auto-draft`
 changeset periodically so that if you navigate away from the customizer
 you can get the changes restored. (Also this allows you to share the URL
 with another user so they can preview and make additional changes on top
 of what you have done.) Still, when you try to leave the customizer it
 still presents you with the AYS dialog since there is no UI to return to
 that changeset, which is what introducing a Draft button will address, as
 will restoring the last drafted changeset to the customizer the next time
 someone starts a session.

 The moment that someone hits Save Draft this should cause the AYS dialog
 to be removed and it should stop the autosave behavior which writes new
 changes directly on top of the changeset, since it is now a `draft` and
 not an `auto-draft`. Subsequent changes should be autosaved into ''a new
 autosave revision'' of the changeset instead of writing onto the changeset
 post itself. A subsequent change should also cause the `onbeforeunload`
 AYS dialog to be restored, until which the user hits Save Draft again
 which should result in the changes being written on top of the changeset
 post directly (and if `revisions` support is enabled for
 `customize_changeset` posts, this should cause a new normal revision to be
 made).

 If the user has made changes to a Draft and leaves the customizer ignoring
 the AYS dialog, a user could be notified that there are autosave changes
 that ''are'' saved in the changeset's autosave revision (as noted in the
 ticket description) which could then be restored be merging them on top of
 the saved changeset (and then either reloading the customizer or
 dynamically populating up the customizer settings in JS, assuming that the
 UI will dynamically respond to create corresponding sections and controls
 in response to settings being spun into existence), as noted above.

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