WordPress.org

Make WordPress Core

Changes between Initial Version and Version 3 of Ticket #28602


Ignore:
Timestamp:
06/20/2014 08:09:06 PM (8 years ago)
Author:
westonruter
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #28602 – Description

    initial v3  
    55When you’re log in, you could actually get sent to the Customizer, with the preview iframe filling the whole view. Then when selecting “Customize” it could just bring the customizer panel into view. You then can make a setting change, and then continue browsing the site like normal… and the setting change would remain pending until Saving. Any site browsing activity done on the normal frontend could also be done from within the Customizer. In this way, there would be no need for a `/wp-customize/` rewrite base, or a `/customize/` endpoint (#28570); if you’re logged in, you would be in the Customizer already.
    66
    7 There would be some initial overhead when navigating to the frontend from somewhere else (like the WP admin), since it would re-initialize the customizer. But subsequent navigation on the frontend would happen all within the customizer preview iframe.
     7There would be some initial overhead when navigating to the frontend from somewhere else (like the WP admin), since it would re-initialize the customizer. But subsequent navigation on the frontend would happen all within the customizer preview iframe. The URL bar in the browser would mirror the URL loaded into the preview iframe via HTML5 history (`pushState`/`popState`).
    88
    99The work here would nicely compliment the work on the WP Front-end Editor, as the Customizer would allow previewing changes to any post type and associated postmeta via `transport=refresh` so that the theme need not add explicit support for doing inline live editing (i.e. `transport=postMessage`).