Changeset generated even if no change?

[pavelevap]

I went to Customizer, changed Color scheme, but I did not like it, so I changed it back. So, nothing was really changed, but:

• "Save & Publish" button is active?

• Changeset parameter was generated (and saved into database) with value for colorscheme which is set currently (no change here). This changeset should not be created or recycled later, I guess...

[westonruter]

This is expected. Once you change a setting in the customizer, it becomes dirty, and will remain dirty even if you set it back to what it was previously. I suggest following #21666 for having a specific UI for undo/redo history in a given customization session.

And since the setting is made dirty, a customize_changeset post is indeed created. If you never publish the changes, it will remain with an auto-draft status and the post will be garbage-collected after a week. This is the same behavior as when you land on wp-admin/post-new.php: a new auto-draft is inserted every time you land on this page to create a new post, even if you never explicitly save a draft.

[pavelevap]

So, every changeset is deleted after a week (when not changed)? When I send it to my colleague to review theme suggestions and he will click it after a week (not so rare), it will be deleted automatically?

[westonruter]

@pavelevap at the moment in core, yes. However, it should be a week from the last time the lost was modified not created. The Customize Snapshots plugin allows you to transition the changeset post to a persistent draft via a new Draft button, but this can also be done programmatically via the JS call: wp.customize.previewer.save({status:'draft'}). You could add a little plugin which adds a button that does this if you don't want the full Customize Snapshots plugin, which again is not quite yet updated for 4.7.

[pavelevap]

Thank you for explanation! I checked #21666, but it is probably a little bit different.

Main purpose of this ticket is experience for users:

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).

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

• 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.

[westonruter]

Replying to 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,