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>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.</p>
<p>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 <em>mobile devices</em> on small screens where a user cannot both see the controls and preview at the same time, as can be compared here:</p>
<span class="embed-youtube" style="text-align:center; display: block;"><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></span>
<p>Inline editing in this way is also helpful for <em>accessibility</em> 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:</p>
<span class="embed-youtube" style="text-align:center; display: block;"><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></span>
<p>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.</p>
<p>Themes can opt-in to support this plugin’s inline editing within the customizer by assigning the appropriate type to the registered partials:</p>
<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>
<p>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.</p>
<p>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>).</p>
<p>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:</p>
<blockquote>
<p>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 <em>eliminate the Customizer altogether</em>. 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 <strong>frontend editing</strong>.</p>
</blockquote>
<p><strong>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>.</strong></p>


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.

Customize Widgets Plus vs Customize Inline Editing