Load Customizer preview iframe with natural URL

[westonruter]

Currently the Customizer preview is populated by doing an Ajax POST request to a the previewed URL and then the Ajax response is written to an iframe which has an about:blank. This works well to make sure that the change settings get passed along to the Customizer for the refresh, but there are some unintended side effects. For one, the location.href of the window in the Customizer preview reflects the location of the parent window, not the location of the URL being previewed. This breaks things like jQuery UI (#23225) when it checks if links are in-page targets. Other aspects of the Customizer preview can be improved if the natural URL is loaded instead of using Ajax, namely the navigation within the preview can be much more robust without needing to implement hacks for catching clicks on link elements to route the URL change up to the Customizer; this will also fix #20714, allowing forms to be interacted with in the Customizer as expected. Lastly, it may resolve #35824 where SVG images sometimes currently fail to render in the preview.

To implement this (as discussed on #23225:22) we'll need to introduce a new communications channel to push Customizer settings changes into the preview when a refresh transport is invoked. Instead of sending the settings with POST request to load the page, we'll need to send settings changes into a transient which the Customizer preview can read from when loading a page via a regular GET request. A side effect of this may be that we need to disallow a user from opening the Customizer in multiple windows, since the Customizer preview won't know which Customizer pane it is associated with.

Another gotcha here, perhaps another reason why document.write() was chosen for populating a blank iframe, is maintaining the scroll position when a refresh happens. Doing a location.reload() in the preview window may not have a seamless preservation of the scroll position. We may need to make sure the Customizer preview gets sent back with output buffering so that the entire document is sent all at once so that incremental rendering does not interfere with the prior scroll position.

Fixes #23225 (Customizer is Incompatible with jQuery UI Tabs)
Also should fix #22037 (Customizer: Live preview fetches page but does not display)

[deltafactory]

Would it make sense to trigger the Customizer preview in a way vaguely similar to a post preview? I imagine something like a special URL parameter that provides a random/nonce-value that is associated with the transient that stores the customizer's configured state.

I'm not sure how to address the JS-based customizer preview calls.

Is it important to be able to navigate/interact with existing pages with this mode enabled?

[westonruter]

I've started some experimenting with this: ​https://github.com/xwp/wordpress-develop/compare/customize-transactions

[westonruter]

Some todos I've been brainstorming on: ​https://github.com/xwp/wordpress-develop/issues/60

[westonruter]

I have an alpha state for this in ​https://github.com/xwp/wordpress-develop/pull/61

Some additional improvements in this are that form submissions and Ajax requests can now be previewed properly. See also #20714.

[westonruter]

Moving this to 4.2 since the issue would be resolved by #30937.

The new communications channel mentioned in the description is the “Customize transactions” proposed in #30937. Instead of the current Ajax POST + document.write() approach for populating the Customizer preview, the patch developed for that ticket implements the loading of the preview iframe with a normal GET request for the desired URL with a transaction ID query argument added.

[celloexpressions]

This is fixed by customizer transactions. Running list of tickets that this particular piece of that should fix: #34142, #31641, #23225, #22037, #20714.

[westonruter]

Removing early according to transaction dependency #30937.

[westonruter]

Punting due to transactions being too large to finish patch and test in time for 4.6.

[westonruter]

This has been implemented in the patch for #30937.

Please test: grunt patch:https://github.com/xwp/wordpress-develop/pull/161

[westonruter]

In 38810:

Customize: Implement customized state persistence with changesets.

Includes infrastructure developed in the Customize Snapshots feature plugin.

See ​https://make.wordpress.org/core/2016/10/12/customize-changesets-technical-design-decisions/

Props westonruter, valendesigns, utkarshpatel, stubgo, lgedeon, ocean90, ryankienstra, mihai2u, dlh, aaroncampbell, jonathanbardo, jorbin.
See #28721.
See #31089.
Fixes #30937.
Fixes #31517.
Fixes #30028.
Fixes #23225.
Fixes #34142.
Fixes #36485.