Customizer Features for WordPress 4.3 Kickoff

Here are the features I have suggested/proposed during the WordPress 4.3 kickoff:

Partial Refresh

This greatly improves performance of previewing changes in the Customizer for non-postMessage transport settings (JS-applied changes) by just refreshing the area of the page that has been changed. As such it eliminates some of the need to do postMessage in the first place, while also reducing the amount of duplicated logic that would have to be implemented in JS to mirror what is being done in PHP. This resurrects some code from the old Widget Customizer feature plugin developed for 3.9. Writeup and feature plugin are available.


A low-level re-architecture of the Customizer plumbing that has a lot of side benefits and bugfixes, introducing some exciting possibilities for future feature plugins like scheduled settings, setting revisions, and drafted/pending settings. Partial Refresh is a dependency for this. Pull request available, but needs refresh. See proposal.


This is an important one for a client project I’m involved with, and so I’m having to prioritize it. I’m working on a client site that will have many users in the Customizer at a time, and given the way the Customizer is currently implemented (as with most areas of WP), there is no concurrency/locking support. So I’m working on adding locking at the control/setting level. See #31436.

(Cross-posted in comment.)

WordCamp Sydney talk: Customize all the things!

Today at WordCamp Sydney, I speak on The Customizer:

The Customizer is one of the least known yet most powerful features of WordPress. We need to get past thinking of it as the “Theme Customizer” which only good for tweaking colors and a limited number of settings. No, the Customizer provides a framework for live-previewing any change to WordPress.

In WordPress 3.9 I led development of incorporating Widget management to the Customizer, and I’d like to get on a soapbox to get people excited about developing their own custom controls for the Customizer.

Here’s my presentation:

I’m also happy that we at XWP (X-Team WP) and Stream are among the sponsors of the WordCamp:

I'm speaking at WordCamp Sydney September 27-28, 2014 I'm sponsoring at WordCamp Sydney September 27-28, 2014

Re: Edit WordPress Posts and Postmeta in the Customizer

I couldn’t reply to Jeff’s comment on Sarah’s WP Tavern post because of a Jetpack problem, so I’m posting it here:

With the Front-end Editor using the Customizer as a framework, I wonder if the interface will look similar to this experiment? I hope not.

This plugin is really a prototype to demonstrate how the Customizer can be used to preview changes to posts/postmeta at an architectural level. Hardly any consideration has been given to UI, which Avryl has been doing a great job with in her Front-end editor.

Ultimately, I’m interested to see how the Front-end Editor comes into play when previewing a post or writing a draft post. Will we be able to use it to write a post or will the editor be refrained from use until after a post/page is published?

You can use this Customize Posts plugin to edit drafts as well. Just create a new post post, save a draft, and then click Preview. You can then click Customize in the admin bar to then access that post from the Customizer and you can make changes, including transitioning the post draft to a published post. This relates to a previous prototype I worked on in the Customizer Everywhere plugin, which replaces the “Preview” button with a “Preview & Customize” button.

In this case and as I’ve seen mentioned already, editing should be done inline and not with boxes popping up around the content.

In terms of a prototype which demonstrates how inline editing can be added to the Customizer, see my other prototype: Customize Inline Editing.

Failures related to the WordPress APC Object Cache plugin

On a site for a newer X-Team client, APC was previously chosen as the object cache plugin. This has caused some headaches due to APC not being available while in CLI mode, rendering WP-CLI mostly broken: any commands which change parts of the database which get object-cached won’t appear until the cache gets invalidated, which may not happen anytime soon. For example, plugin (de)activation is broken in WP-CLI with APC Object Cache, as the manifest of activated plugins is cached.

Today I encountered a more serious problem with APC Object Cache.

I was making some widget changes, and I saw that my changes weren’t being reflected on the frontend. Upon reloading the widgets admin page, I also noticed that my changes didn’t seem to get saved. But if I ran wp option get widget_text, I could see my changes had been written to the database (as, of course, WP-CLI here was bypassing the APC object cache). So for some reason, APC was refusing to invalidate widget caches. Doing some more digging, I was shocked to see that the the Text widgets used in the sidebar, had multi-widget instance numbers surpassing 560,000,000. That’s right, 560 million.  The output of wp option get widget_text included:

array (
  526001242 =>
  array (
    'title' => 'Lorem Ipsum',
    'text' => 'Hello World',
    'filter' => false,
  '_multiwidget' => 1,

Some plugin must have at some time bumped that widget instance number up, because there’s no way there have been millions of Text widgets used on the site. Only a couple dozen Text widget instances are currently present.

In any case, this incredibly-sparse PHP array seemed like a good candidate for what was causing APC cache to fail. I swapped out APC for Memcached Object Cache, and the problem went away. While the Memcached plugin stores arrays as serialized strings, just as they get stored in the options table, the APC plugin is apc_store’ing the array wrapped in an ArrayObject instance:

if ( is_array( $data ) )
    $store_data = new ArrayObject( $data );

While I couldn’t reproduce this problem on VVV or on the site’s staging environment, for some reason on production this array object failed to get stored by APC.

I’ve never had any issues with Memcached Object Cache, so I’m glad I made the switch. Not only did it fix this strange widgets issue, but it’s great to be able to once again rely on WP-CLI!

Easily turn any webcam image into video on an OS X Dashboard widget

I have a few webcams on my network which I can access via URLs like Here’s a handy little bookmarklet (pagelet?) which allows you to turn any such webcam URL into live video (here, 1 fps):

data:text/html,<img src="" onload="var img = this; setTimeout( function(){ img.src = img.src; }, 1000 )">

Paste this  data:  URL into Safari and then turn it into a Dashboard widget via File > Open in Dashboard. Now you have a video Dashboard widget for your webcam! (Of course you could create a standalone HTML page and load it instead, but data: URLs are cooler and easier!)

WARNING: This could get interpreted as a Denial of Service (DOS) attack if you point this at a URL on a public web server. So it’s best to only do this for cameras on your local network.

Of course, if your camera supports MJPEG aka server-push (multipart/x-mixed-replace), you should just reference that MJPEG URL directly without any such code above.