Weston Ruter

<p>This plugin consists of lab features and a testbed for improvements to Widgets and the Customizer.</p>
<p>Requires PHP 5.3+.</p>
<p><strong>Development of this plugin is done <a href="https://github.com/xwp/wp-customize-widgets-plus" rel="nofollow ugc">on GitHub</a>. Pull requests welcome. Please see <a href="https://github.com/xwp/wp-customize-widgets-plus/issues" rel="nofollow ugc">issues</a> reported there before going to the <a href="https://wordpress.org/support/plugin/customize-widgets-plus" rel="ugc">plugin forum</a>.</strong></p>
<p>Current features:</p>
<h4>Non-Autoloaded Widget Options</h4>
<p>Widgets are stored in options (normally). Multi-widgets store all of their instances in one big serialized array specific to that type. When there are many widgets of a given type, the size of the serialized array can grow very large. What’s more is that <code>WP_Widget</code> does not explicitly <code>add_option(... 'no' )</code> before calling <code>update_option()</code>, and so all of the settings get added with autoloading. This is very bad when using Memcached Object Cache specifically because it can result in the total <code>alloptions</code> cache key to become larger than 1MB and result in Memcached failing to store the value in the cache. On WordPress.com the result is a <a href="https://github.com/Automattic/vip-quickstart/blob/master/www/wp-content/mu-plugins/alloptions-limit.php" rel="nofollow ugc">“Matt’s fault” error</a> which has to be fixed by the VIP team. Widget settings should not be stored in serialized arrays to begin with; each widget instance should be stored in a custom post type. But until this is done we should stop autoloading options. See also <a href="https://core.trac.wordpress.org/ticket/26876" rel="nofollow ugc">#26876</a> and <a href="https://core.trac.wordpress.org/ticket/23909" rel="nofollow ugc">#23909</a>.</p>
<h4>Widget Number Incrementing</h4>
<p>Implements fixes for Core issue <a href="https://core.trac.wordpress.org/ticket/32183" rel="nofollow ugc">#32183</a> (Widget ID auto-increments conflict for concurrent users). The stored widget_number option provides a centralized auto-increment number for whenever a widget is instantiated, even widgets in the Customizer that are not yet saved.</p>
<h4>Efficient Multidimensional Setting Sanitizing</h4>
<p>Settings for multidimensional options and theme_mods are extremely inefficient to sanitize in Core because all of the Customizer settings registered for the subsets of the <code>option</code> or <code>theme_mod</code> need filters that are added to the entire value, meaning sanitizing one single setting will result in all filters for all other settings in that <code>option</code>/<code>theme_mod</code> will also get applied. This functionality seeks to improve this as much as possible, especially for widgets which are the worst offenders. Implements partial fix for <a href="https://core.trac.wordpress.org/ticket/32103" rel="nofollow ugc">#32103</a>.</p>
<h4>HTTPS Resource Proxy</h4>
<p>When <code>FORCE_SSL_ADMIN</code> is enabled (such as on WordPress.com), the Customizer will load the site into the preview iframe using HTTPS as well. If, however, external resources are being referenced which are not HTTPS, they will fail to load due to the browser’s security model raise mixed content warnings. This functionality will attempt to rewrite any HTTP URLs to be HTTPS ones via a WordPress-based proxy.</p>
<h4>Widget Posts</h4>
<p>Store widget instances in posts instead of options. Requires trunk due to patch committed in <a href="https://core.trac.wordpress.org/ticket/32474" rel="nofollow ugc">#32474</a>. More details forthcoming…</p>


Customize Widgets Plus

Lab features and a testbed for improvements to Widgets and the Customizer.

<p><em>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</em></p>
<p>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.</p>
<p>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.</p>
<p>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>.</p>
<p>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:</p>
<pre>
autofocus[panel]=nav_menus&autofocus[section]=nav_menu[87]&autofocus[control]=nav_menu_item[5123]
</pre>
<p>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.</p>
<p>Note that the <code>url</code> param will be URL-encoded. So a typical Customizer URL would get updated to look like:</p>
<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>
<p>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.</p>
<p>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.</p>
<p><strong>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>.</strong></p>


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.

Customize Widgets Plus vs Customizer Browser History