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

WordPress Trac noreply at wordpress.org
Fri Jun 20 20:09:07 UTC 2014


#28602: Transparently route frontend browsing through Customizer for logged-in
editors
-------------------------------------+------------------------------
 Reporter:  westonruter              |       Owner:
     Type:  feature request          |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Customize                |     Version:  3.4
 Severity:  normal                   |  Resolution:
 Keywords:  needs-patch ux-feedback  |     Focuses:  ui, javascript
-------------------------------------+------------------------------
Description changed by westonruter:

Old description:

> As [https://irclogs.wordpress.org/chanlog.php?channel=wordpress-
> dev&day=2014-06-20&sort=asc#m873451 discussed on IRC]:
>
> What if when you are logged in to WP and are an editor, if you always
> viewed the site through the Customizer?
>
> When 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.
>
> 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.
>
> The 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`).
>
> Addresses #28580 (Speed up customizer by lazy-loading controls and
> settings as needed)
> Depends on #20714 (Theme customizer: Impossible to preview a search
> results page)
> Depends on #28536       (Add browser history and deep linking for
> navigation in Customizer preview)
> Depends on #28542 (Navigating within Customizer preview should update
> parent document title)
> May invalidate #28570 (Introduce pretty permalinks for Customizer)

New description:

 As [https://irclogs.wordpress.org/chanlog.php?channel=wordpress-
 dev&day=2014-06-20&sort=asc#m873451 discussed on IRC]:

 What if when you are logged in to WP and are an editor, if you always
 viewed the site through the Customizer?

 When 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.

 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. The URL bar in the browser would
 mirror the URL loaded into the preview iframe via HTML5 history
 (`pushState`/`popState`).

 The 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`).

 Addresses #28580 (Speed up customizer by lazy-loading controls and
 settings as needed)
 Depends on #20714 (Theme customizer: Impossible to preview a search
 results page)
 Depends on #28536       (Add browser history and deep linking for
 navigation in Customizer preview)
 Depends on #28542 (Navigating within Customizer preview should update
 parent document title)
 May invalidate #28570 (Introduce pretty permalinks for Customizer)

--

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


More information about the wp-trac mailing list