[wp-trac] [WordPress Trac] #39228: Changeset generated even if no change?

[WordPress Trac]

#39228: Changeset generated even if no change?
--------------------------+----------------------
 Reporter:  pavelevap     |       Owner:
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Customize     |     Version:  4.7
 Severity:  normal        |  Resolution:  invalid
 Keywords:                |     Focuses:
--------------------------+----------------------

Comment (by westonruter):

 Replying to [comment:4 pavelevap]:
 > 1) When I want to use changesets feature, it will work only for 7 days
 and then automatically deleted (without any notification for user). But
 when you publish changes, `customize_changeset` (which is obsolete now) is
 trashed and stored in database for 30 days. I would expected that current
 changesets have longer active period (for example 30 days) and published
 changesets can be deleted immediatelly (not trashed).

 That's right. But again, there is no UI for changesets in core, and so
 users should expect their changes to be automatically deleted. Changesets
 are just re-using the core `EMPTY_TRASH_DAYS` to know how long to hold
 onto those deleted posts.

 > 2) I still do not see any point for saving changesets with no change,
 but it is probably a deeper problem as you explained with "dirty" change.
 I understand that "dirty" status is needed for some things and functions,
 but for user is "dirty" status very unpleasant in this case:
 >
 > - "Save & Publish" button is active even if no "real" change was made.
 This is not related only to changesets, it could be possible to check
 current status to saved `theme_mods_*`? Customizer is used very often for
 testing purposes, that means: change one thing, see how it looks, change
 it back to see that it was better :-) In this case '''active button is
 really misleading''', because nothing was changed and '''user does not
 know if he changed something other''' when button is active. So user
 prefers to leave and there is another warning browser window (see #39228)
 that other changes were made. It was misleading for me at the first sight
 without finding what is going on in database...

 The changeset post would get created regardless, but in terms of the UI it
 would be possible to clear the dirty state if the user changed all
 settings back to their original values, and in doing so the AYS dialog
 could be removed and the Save button could be re-disabled. This seems like
 the scope of #21666. This also seems like a somewhat uncommon scenario for
 a user to carefully manually reset all of their changes back to the
 original values.

 > - I understand that `customize_changeset` have to be created probably as
 a draft in this case, but why it contains change in `post_content` when
 there was no change? When plugins try to extend this feature, it can be
 disappointing, because there is tracked change which actually did not
 happen.

 The changeset is just storing whatever settings were ''touched'' in a
 given customizer session. A plugin could add a filter for
 `customize_changeset_save_data` to strip out any values from the changeset
 which match their current saved values in the DB,

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