WordPress.org

Make WordPress Core

Opened 3 years ago

#39913 new defect (bug)

Customize: Disable auto-trashing of published changesets in anticipation of revisions

Reported by: westonruter Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.7
Component: Customize Keywords:
Focuses: Cc:

Description

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 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?

Change History (0)

Note: See TracTickets for help on using tickets.