WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 13 months ago

#30028 closed enhancement (fixed)

Load Customizer preview iframe with natural URL

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

Description (last modified by 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)

Change History (21)

#1 @deltafactory
3 years ago

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?

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


3 years ago

#5 @westonruter
3 years ago

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.

#6 @westonruter
3 years ago

  • Description modified (diff)
  • Milestone changed from Awaiting Review to 4.2

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.

#7 @westonruter
3 years ago

  • Owner set to westonruter
  • Status changed from new to assigned

#8 @celloexpressions
3 years ago

  • Milestone changed from 4.2 to Future Release

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


3 years ago

#10 @westonruter
2 years ago

  • Milestone changed from Future Release to 4.5

#11 @westonruter
22 months ago

  • Keywords early added
  • Milestone changed from 4.5 to Future Release

#12 @westonruter
22 months ago

  • Description modified (diff)

#13 @westonruter
19 months ago

  • Description modified (diff)

#14 @westonruter
19 months ago

  • Milestone changed from Future Release to 4.6

#15 @celloexpressions
19 months ago

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

#16 @westonruter
19 months ago

  • Keywords early removed

Removing early according to transaction dependency #30937.

#17 @westonruter
18 months ago

  • Milestone changed from 4.6 to Future Release

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

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


14 months ago

#19 @westonruter
14 months ago

  • Keywords has-patch needs-testing added; needs-patch removed
  • Milestone changed from Future Release to 4.7

This has been implemented in the patch for #30937.

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

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


13 months ago

#21 @westonruter
13 months ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.