WordPress.org

Make WordPress Core

Changes between Version 6 and Version 12 of Ticket #30028


Ignore:
Timestamp:
02/14/2016 07:55:16 AM (4 years ago)
Author:
westonruter
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #30028

    • Property Owner set to westonruter
    • Property Status changed from new to assigned
    • Property Keywords early added
    • Property Milestone changed from 4.2 to Future Release
  • Ticket #30028 – Description

    v6 v12  
    1 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.
     1Currently 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.
    22
    33To implement this (as discussed on [https://core.trac.wordpress.org/ticket/23225#comment:21 #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.