[wp-trac] [WordPress Trac] #39913: Customize: Disable auto-trashing of published changesets in anticipation of revisions

[WordPress Trac]

#39913: Customize: Disable auto-trashing of published changesets in anticipation of
revisions
--------------------------+-----------------------------
 Reporter:  westonruter   |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Customize     |    Version:  4.7
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 When changesets were introduced in 4.7 (via #30937), we decided by default
 to auto-trash a `customize_changeset` post upon publishing. The reason for
 this is that there was no UI for changesets and there would be no way to
 clean up old revisions from the UI, meaning the posts would just be added
 indefinitely. However, with revisions being planned for 4.8 being planned
 for in #31089 and #21666, it would perhaps be beneficial to disable the
 auto-trashing behavior so that once revisions support ''is'' added the
 revision history won't be empty.

 Nevertheless, even with changesets not being auto-trashed, there would
 still be [https://core.trac.wordpress.org/ticket/21666#comment:33
 challenges] with reverting to a previously-published changeset:

 > == Challenges of Reverting to a Previously-published Changeset ==
 >
 > Reverting to a revision of a changeset is easier than reverting to a
 previously-published changeset. When reverting to a revision of the
 current changeset, all this means basically is to reset the settings to
 match the state of the changeset at that revision. However, reverting to a
 previously-published changeset is more complicated/interesting. Take this
 changelog:
 >
 > 1. January 1st: User changes site title to “Foo”.
 > 2. January 2nd: User changes site tagline.
 > 3. January 3rd: User changes site title to “Bar”.
 >
 > Now, if the user clicks the changeset revision for January 1st, my
 assumption is that this will restore the site title of “Foo”. However,
 will it also include a revert of the change made to the tagline on January
 2nd? Each changeset only contains the settings that were modified, so as
 it stands right now we would not know what to revert the tagline to since
 it's previous value is not captured. Whenever a changeset is about to be
 published, we could capture the current value for each setting prior to
 saving. This would allow us to roll back all of the changes made to the
 site between two published changesets. The process would involve walking
 over the previous changesets to gather up a list of the previous values
 and merge them and apply them to the current changeset for previewing.
 >
 > Complication: What about when a user makes a change to the tagline
 ''outside'' of the customizer? In that case the tagline would not be
 referenced in any changeset, and reverting to the changeset on the 1st
 would only rollback the site title. Would this be expected behavior?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/39913>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform