[wp-trac] [WordPress Trac] #30937: Add Customizer state persistence in changesets (formerly “transactions”)

[WordPress Trac]

#30937: Add Customizer state persistence in changesets (formerly “transactions”)
-------------------------------------------------+-------------------------
 Reporter:  westonruter                          |       Owner:
     Type:  feature request                      |  westonruter
 Priority:  high                                 |      Status:  closed
Component:  Customize                            |   Milestone:  4.7
 Severity:  normal                               |     Version:
 Keywords:  has-patch needs-testing needs-unit-  |  Resolution:  fixed
  tests                                          |     Focuses:
-------------------------------------------------+-------------------------

Comment (by westonruter):

 Replying to [comment:81 nikeo]:
 > So now the setting changes and the changeset silent updates are 2
 different processes living their own lives.
 > When the preview frame gets refreshed with api.previewer.refresh(), the
 dirty settings are always posted (with a temporary {{{<form>}}}), even the
 ones that have been saved in the changeset. Is that correct ?

 No, that's not correct. Actually, when you first load up the customizer
 and haven't made any changes, there will not be a `form` created at all,
 and the `iframe` will get a `src` that points to the previewed URL with
 the `customize_changeset_uuid` query param added. This is because all of
 the changes have been written into the changeset at that point. However,
 once you do make a change, then that change will not have been written
 into the changeset yet and a `form` will be created which will `POST` the
 `customized` value into the preview.

 However, after the `AUTOSAVE_INTERVAL` of 60 seconds, or when focus is
 taken off of the customizer or it is unloaded, any such modifications get
 written to the changeset post. When there are no changes that are not yet
 written into the changeset, then it uses a regular `iframe` with a `src`.
 The `POST` data is only used for changes not yet written into the
 changeset. I ended up taking this approach because DB writes are very slow
 and so there needed to be a buffer between making changes to settings and
 the changes being written into the DB.

 > I'm currently developing a feature relying server side on the incoming
 {{{$_POST['customized']}}}
 > . I need to know if there's a plan to totally remove this source of
 customized data in the future, or if it will always be available and
 accessible server side. With the current implementation, I plan to do it
 with
 >
 >
 > {{{
 > $customized_posted_value = $setting -> unsanitized_post_values(
 >     array(
 >       'exclude_changeset' => true ,
 >       'exclude_post_data' => false
 >     )
 >   );
 > }}}

 That won't work because once the changes have been written into the
 changeset, then the `POST` input will be empty. When all pending changes
 are written into the changeset, then the values are only sourced from the
 changeset and not from the `POST` input.

 What feature are you developing that requires inspection of
 `$_POST['customized']`? Why can't you use
 `$wp_customize->unsanitized_post_values()` alone? It will contain the
 changeset values with any `$_POST['customized']` values merged on top of
 it. If you need to override the values you can use
 `$wp_customize->set_post_value()`.

 Feel free to ping me on #core-customize in Slack to chat about this
 further as it's probably a better place to discuss your use case.

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