[wp-trac] [WordPress Trac] #28602: Transparently route frontend browsing through Customizer for logged-in editors

WordPress Trac noreply at wordpress.org
Fri Aug 12 06:06:50 UTC 2016


#28602: Transparently route frontend browsing through Customizer for logged-in
editors
-----------------------------+-----------------------------
 Reporter:  westonruter      |       Owner:
     Type:  feature request  |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  Customize        |     Version:  3.4
 Severity:  normal           |  Resolution:  maybelater
 Keywords:                   |     Focuses:  ui, javascript
-----------------------------+-----------------------------
Changes (by westonruter):

 * keywords:  needs-patch ux-feedback =>
 * status:  new => closed
 * resolution:   => maybelater
 * milestone:  Awaiting Review =>


Comment:

 Closing this as I think the prototype and approach here are less than
 ideal. Instead of transparently loading the existing customizer app
 (`customize.php`) into an `iframe` on a page that gets a URL that looks
 like the frontend URL, I think it will be much better to work toward
 bootstrapping the Customizer on the frontend itself. With live JS-based
 previewing of setting changes and now with selective refresh, there is
 less and less cause for doing full-page refreshes to preview changes.
 These full-page refreshes are what necessitated the `iframe` to begin
 with. If settings don't use the `refresh` transport, then we can lazy-load
 the Customizer components onto any existing frontend page. These can be
 asynchronously loaded for any logged-in user as well so that they appear
 instantly. Also, since selective refresh normally has selectors associated
 with the partials, any control that have setting(s) associated with a
 given partial could appear floating next to the element being previewed,
 as opposed to only appearing in the customizer pane.

 Persisting the customized state across frontend page loads would be the
 responsibility of transactions (#30937), now available as a feature plugin
 in [https://github.com/xwp/wp-customize-snapshots Customize Snapshots].
 Once an initial setting is modified, this can create a new
 transaction/snapshot for the customizer session which can follow the user
 around as they make changes to different pages of the site. Once in this
 editing mode, the admin bar could have a link showing similar to the “Save
 & Publish” now appearing in the existing Customizer.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/28602#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list