Weston Ruter

This is a feature plugin intended to implement <a href="https://core.trac.wordpress.org/ticket/28536" rel="nofollow ugc">#28536</a>: Add browser history and deep linking for navigation in Customizer preview
This plugin keeps the Customizer URL in the browser updated with current previewed URL as the <code>url</code> query param and current expanded panel/section/control as <code>autofocus</code> params. This allows for bookmarking and also the ability to reload and return go the same view (which is great for developers), including which device you are previewing (desktop, tablet, or mobile). Not only will the URL be kept in sync with the current customizer UI, but new browser history entries will be added as you navigate around the site in the preview (via <code>history.pushState()</code>), allowing you to use the back/forward buttons as you would normally when browsing the site outside the customizer. The scroll position for each previewed URL is tracked as well, so that when you navigate back/forward the scroll position will be restored, just as happens when browsing the site outside the customizer preview. Restoring the scroll position also works when reloading the customizer, as the position is persisted in a <code>scroll</code> query parameter: again, this is extremely useful during development.
This plugin complements well the <a href="https://github.com/xwp/wp-customize-snapshots" rel="nofollow ugc">Customize Snapshots</a> plugin which allows you to save your Customizer state in a shapshot/changeset with an associated UUID that also gets added to the browser URL in the Customizer.
For example, if you load the Customizer and then click the “Site Identity” section, the URL will be replaced to add <code>autofocus[section]=title_tagline</code>.
If you navigate into the nav menus panel, open a menu section, and then expand a nav menu item control, then the URL will have these <code>autofocus</code> params added:
<pre>
autofocus[panel]=nav_menus&autofocus[section]=nav_menu[87]&autofocus[control]=nav_menu_item[5123]
</pre>
And while these changes to the <code>autofocus</code> params are being made in the browser’s URL as the Customizer UI is interacted with, if you navigate to another page in the preview the <code>url</code> parameter will also be replaced to reflect the new preview URL.
Note that the <code>url</code> param will be URL-encoded. So a typical Customizer URL would get updated to look like:
<pre>
http://example.com/wp-admin/customize.php?url=http%3A%2F%2Fexample.com%2Fsample-page%2F&autofocus[panel]=widgets&autofocus[section]=sidebar-widgets-sidebar-1&autofocus[control]=widget_text[10]&device=mobile&scroll=200
</pre>
The plugin will also persist the scroll position from the frontend to preview frame in the Customizer after clicking the “Customize” link in the frontend admin bar. This ensures you can quickly start editing whatever you were looking at the moment you clicked Customize, and it makes the Customizer load from the frontend in a more seamless way.
Additionally, as you navigate around the Customizer preview, the close link in the Customizer controls pane will keep updating to point to the same URL that you are previewing, along with persisting the scroll position. In this way, whenever you close the Customizer via this link the user experience is that the Customizer sidebar is just removed, similar to as if they clicked the “Hide Controls” link at the bottom of the sidebar. This behavior is only active if the user had clicked the Customize link from the frontend. If they clicked Customize from the admin, then the Close link will remain linking back to the admin page they came from. Note that for responsive themes like Twenty Seventeen, the synced scroll position between the frontend and backend won’t always appear seamless since the Customizer controls panel being expanded causes the element dimensions in the preview to change.
Development of this plugin is done <a href="https://github.com/xwp/wp-customizer-browser-history" rel="nofollow ugc">on GitHub</a>. Pull requests welcome. Please see <a href="https://github.com/xwp/wp-customizer-browser-history/issues" rel="nofollow ugc">issues</a> reported there before going to the <a href="https://wordpress.org/support/plugin/customizer-browser-history" rel="ugc">plugin forum</a>.

Customizer Browser History

This is a true time saver after Customizer reloads that really adds up....I've only used it for a day but I'm already so used to it I'm not sure I can do without it. Great job!



Resumable Customizer sessions are a big time saver

I was about to create a similar plugin myself, but I'm lucky to find this plugin. Now I'm happy to say that it saved me some time.

When refreshing the customizer browser frequently this plugin is really handy.

Thank you.

I was about to create a similar plugin myself, but...

Sync browser URL in Customizer with current preview URL and focused panels, sections, and controls.

In WordPress 4.5 the <a href="https://make.wordpress.org/core/2016/02/16/selective-refresh-in-the-customizer/" rel="nofollow ugc">selective refresh</a> framework was introduced in core. One of the key concepts in this framework is the “partial”, the region in a document which is selectively refreshed when a related setting is modified. This means that one or more settings are linked with a given element in the preview. When selective refresh was first was introduced it supported the ability for a user to “shift click” on a partial to jump to and focus on the related control in the pane. In WordPress 4.7 this was then enhanced with <a href="https://make.wordpress.org/core/2016/11/10/visible-edit-shortcuts-in-the-customizer-preview/" rel="nofollow ugc">visible edit shortcuts</a> so that users could click (touch even) on the icon to be able to reveal the control in the pane.
The Customize Inline Editing plugin builds on edit shortcuts by allowing the setting to be modified inline via direct manipulation in the preview without having focus removed and placed on the controls pane. This is particularly useful on mobile devices on small screens where a user cannot both see the controls and preview at the same time, as can be compared here:
<iframe loading="lazy" class="youtube-player" width="750" height="422" src="https://www.youtube.com/embed/w7WfSEtT8pc?version=3&rel=1&showsearch=0&showinfo=1&iv_load_policy=1&fs=1&hl=en-US&autohide=2&wmode=transparent" allowfullscreen="true" style="border:0;" sandbox="allow-scripts allow-same-origin allow-popups allow-presentation allow-popups-to-escape-sandbox"></iframe>
Inline editing in this way is also helpful for accessibility since keyboard focus remains in the preview at the element being edited, as can be seen in this demonstration of inline editing on a desktop browser:
<iframe loading="lazy" class="youtube-player" width="750" height="422" src="https://www.youtube.com/embed/KesM3vo5WyE?version=3&rel=1&showsearch=0&showinfo=1&iv_load_policy=1&fs=1&hl=en-US&autohide=2&wmode=transparent" allowfullscreen="true" style="border:0;" sandbox="allow-scripts allow-same-origin allow-popups allow-presentation allow-popups-to-escape-sandbox"></iframe>
This plugin provides one example implementation of inline editing this can be accomplished in the customizer. Version 0.1 of this plugin from 2014 was a precursor in some ways to selective refresh, specifically in regards to how CSS selectors are associated with customizer settings.
Themes can opt-in to support this plugin’s inline editing within the customizer by assigning the appropriate type to the registered partials:
<pre>
add_action( 'customize_register', function( $wp_customize ) {
 $opt_in_partials = array_filter( array(
 $wp_customize->selective_refresh->get_partial( 'blogname' ),
 $wp_customize->selective_refresh->get_partial( 'blogdescription' )
 ) );
 foreach ( $opt_in_partials as $partial ) {
 $partial->type = 'inline_editable';
 }
}, 100 );
</pre>
Click on the edit shortcut to begin editing the element, with keyboard focus then given to the editable element. If the value has a server-side rendered value (e.g. where PHP filters like <code>wptexturize</code> apply to improve typography), the raw value will be supplied when editing starts. Editing can be completed by clicking out of the editable element, tabbing out of the element (blurring it), or clicking the edit icon which then appears as a “done” checkmark icon. You may also shift-click on an element to edit it.
Currently only basic text fields can currently be edited; styling and any tags added to <code>contentEditable</code> areas will be stripped out. Eventually rich text formatting may be allowed, specifically for integrations with the Text widget (via <a href="https://github.com/xwp/wp-js-widgets" rel="nofollow ugc">JS Widgets</a>) or post content (via <a href="https://github.com/xwp/wp-customize-posts" rel="nofollow ugc">Customize Posts</a>).
The <a href="https://make.wordpress.org/core/2016/02/16/selective-refresh-in-the-customizer/" rel="nofollow ugc">selective refresh</a> writeup from 4.5 concludes with a section on a possible future for it and inline editing:
<blockquote>
If we can eliminate full-page refreshes from being the norm for the Customizer, we can start to introduce controls inline with the preview. If the entire preview does not reload, then the inline controls won’t get destroyed by the refresh with each change. For example, consider a widget control floating immediately next to the widget in the sidebar it is editing. With selective refresh, it will then also be possible to eliminate the Customizer altogether. The Customizer could be available to anyone who is logged in, with the controls being bootstrapped on demand when a user wants to edit a given element. There would be no need to navigate way from a page on the frontend to enter a unique Customizer state: the Customizer would come to the user. Any controls not relevant to being inline could remain in the Customizer pane, but it could slide in only as needed instead of appearing by default. That is to say, selective refresh makes the Customizer a much better framework for implementing frontend editing.
</blockquote>
Development of this plugin is done <a href="https://github.com/xwp/wp-customize-inline-editing" rel="nofollow ugc">on GitHub</a>. Pull requests welcome. Please see <a href="https://github.com/xwp/wp-customize-inline-editing/issues" rel="nofollow ugc">issues</a> reported there before going to the <a href="https://wordpress.org/support/plugin/customize-inline-editing" rel="ugc">plugin forum</a>.

Customize Inline Editing

Makes the whole text editing process smooth. From refresh to postMessage to inline editing awesome transition. Keep up the good work :)



Awesome

Demonstration of how inline editing can be implemented in the customizer.

Customizer Browser History vs Customize Inline Editing