WordPress.org

Make WordPress Core

Opened 6 years ago

Last modified 4 years ago

#30028 closed enhancement

Load Customizer preview iframe with natural URL — at Initial Version

Reported by: westonruter Owned by:
Milestone: 4.7 Priority: normal
Severity: normal Version:
Component: Customize Keywords: has-patch needs-testing
Focuses: javascript Cc:

Description

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.

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.

Change History (0)

Note: See TracTickets for help on using tickets.