Transparently route frontend browsing through Customizer for logged-in editors

[westonruter]

As ​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)

[westonruter]

I'm planning to work on a POC.

[azaozz]

Not sure this is a good idea.

1. Why would we want the logged-in admins to browse the front-end in a "constant" preview? It has a substantial overhead and quite a few quirks (compared to a no-iframe, no extra JS browser tab), not even talking about multisite, domain mapping, ssl/no ssl, etc. It would also break or cause problems for many plugins and themes that "do more" on the front. Things like P2, front-end editors, infinite scroll, etc.

2. Even if we spend the time/effort on making this work and not have back-compat problems, what are the benefits? A bit faster loading of the customizer if an admin clicks an "Edit" link (not for post or comment) on the front-end? How often does that happen and is the faster loading worth it, considering the increased complexity and potential incompatibilities?

[westonruter]

It would make particular sense if the Customizer were used as the underlying mechanism for front-end editing, instead of just for managing some site wide options. (For instance, as of 3.9 you can now edit widgets in the Customizer.) As such, it would probably be better entered into as an edit mode instead of being always on. For example, there could be a toggle that appears in the admin bar.

[azaozz]

...it would probably be better entered into as an edit mode instead of being always on.
...there could be a toggle that appears in the admin bar.

Yep, or "Edit" links next to all editable components (perhaps more discoverable), or... Something better. Having a separate edit mode is the way to go, imho.

[westonruter]

I put together a proof of concept for a “window wrapper” which is one way that the Customizer could be pre-loaded when logging in: ​http://westonruter.github.io/window-wrapper/

In the POC you see there is a persistent bar that appears at the bottom of the page when this feature is active, and this bar persists even across page loads as you navigate. Imagine instead that this persistent bar is the Customizer panel on the left, and that it could be hidden by default until called for. Thus, when opening the Customizer, you would not need to reload the page to load the Customizer app: you would already have it loaded, and it would just slide in from the left. Likewise, the DOM of the currently-loaded page wouldn't need to be thrown when opening the Customizer away since there would already be a preview iframe there ready to use.

Implementing this would result in a much faster loading of the Customizer than even #28661 (Improve loading of Customizer from front-end by leveraging customize-loader.js). It would be instant.

[karmatosed]

I would probably suggest that a separate editor mode is the way to go, however I would also suggest we user test solutions before deciding on either. I totally feel there probably is a middle ground between the two to explore.

In saying the above though, I am not commenting on the behind scenes. Whatever we can do to make the loading of Customizer and editor faster - absolutely lets do it.

My gut says this method makes it hard to know if you're in edit or not. Now, in saying that there is a move toward being able to edit everything all the time. You still should have some indication I feel. Again, this is something to test.

Visually the bar needs some serious work, but again that's probably the middle ground I mention and part of iterating. As it stands, what you have is a nice experiment to user test and explore. That's a great first step.

[westonruter]

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