Evolving the Customizer

The Customizer is great. I’ve been working in and around it to offer site customization features to our WordPress.com users since it launched with 3.41, coinciding with when I joined Automattic on Team Custom. We’ve especially used it to build great tools as part of the Custom Design upgrade, but as we’ve pushed the boundaries of what awesomeness we can unlock for our users, certain aspects of the Customizer have started to create roadblocks for us. Some of these are addressable, and some probably aren’t.


The Customizer doesn’t work on a phone/small screen. Anyone who thinks this isn’t a dealbreaker is just wrong. The UI was designed for the desktop web. This could possibly be addressed in core, but it will require a pretty fundamental rethinking of the interface.


The Customizer can get really slow. This is partly because of its two-requests-to-load model: one for the customize.php app, and one for the frontend XHR that gets injected into a preview iframe. Any slowness on your server is multiplied x2 since there are two requests that happen serially.2 We’ve seen this hit up to 60 seconds on WP.com sometimes3, with similar reports from WP.org users on underpowered hosts like GoDaddy. Some performance work could probably be done here to start fetching the frontend sooner in the customize.php load process.

Speed could possibly be better served by a more fundamental rethink: what if the user wants to start customizing from the frontend of their site and clicking Customize just transitioned you seamlessly into a customization mode via an already bootstrapped, frontend customizer app? This actually has some serious UX considerations I’ll touch on later, but the big advantage for performance is that you’re not throwing away a perfectly good DOM to get the Customizer up and running.

Speed will also be hampered as more things are put in the Customizer. Putting Widgets in there in 3.9 is a great example of this: it’s made Widgets better, but the Customizer worse. As more things are added, speed will suffer, not to mention the UX cost of dumping so much in there.

Uncanny Valley UX

You can enter the Customizer through wp-admin or the frontend of your site via a Customize link in the adminbar. In both cases, the transition begs the question: am I still where I started? Is this admin, or my site? I believe that we should optimize for the frontend flow, where the app is bootstrapped and the Customizer becomes an editing mode you can seamlessly enter. Frontend editing for appearance.

WP Tunnel Vision

One thing we’ve seen in our user testing is that users (especially new ones) don’t care about or really understand the distinction between themes and the things you can do to customize them. They just want to get their site looking the way they want it to look. Therefore, the best customizer UX would blur the line between themes and customize-able options, freely allowing you to preview different “designs” (themes) while then tweaking that theme’s options. The Customizer’s current architecture would make this impossible, as the Customizer “app” itself must do a full refresh for each theme previewed, kicking off the slow 2-request cycle.


The Customizer is the first true JS-driven feature in core.4 It reimplements a bunch of Backbone internally, since this was a release before Backbone made it into core. It’s also a JS-driven app wrapped around a PHP-only public API,5 which is I guess about what you’d expect from an early WP foray into something JS-driven. But this fundamental PHP dependency makes it basically impossible to account for a seamless switching of state while changing a previewed theme: a full page reload has to happen. If the Customizer is going to be awesome, it needs to a seamless way to customize how your site looks – themes vs theme options are just implementation details.

Also, looking forward, the Customizer itself should be a client app of WP-API. Everything related to site appearance should be an API call away, rather than the tightly coupled thing that is the Customizer. This will open the door for, say, a native Customizer on Android or iOS or some other platform that doesn’t exist yet but will be important.6

Patches Welcome

Some folks might be reading this and wondering why I’m not trying to contribute this vision to core. ‘dI love to, but I don’t think it’s possible architecturally, and particularly not in a backwards compatible manner. This is certainly a case where the optimal use-case on WP.com (new user signup, pre-picked list of themes) may not line up with the best user experience for core users. I might be wrong about this, thus this post. I would genuinely love to be wrong, but I’ve worked with the Customizer extensively over the past two years and I’m pretty sure I’m not.

  1. Actually, 3.4 dropped on June 13, 2012, but we launched the Customizer for WP.com users on May 17. 
  2. Also, since the preview iframe just gets the frontend request injected upon XHR completion, any browsers’ optimizations to do things like prefetch resources like images or DNS entries before the page has even started rendering are nullified. The frontend also tends to be the more resource-intensive side of things, which compounds the problem since it’s loaded last. 
  3. Obviously there are issues for us to address here, but the previous footnote contains some gotchas that can’t be addressed in the current architecture. 
  4. As in, without JS, it just doesn’t work. Until then, everything else in core admin worked with JS disabled. 
  5. Many aspects of the JS API are “public” in the sense that they’re not hidden inside a closure, but they are not documented anywhere on the Codex that I’ve seen. I’ve even spoken about this
  6. Maybe I will customize my blog from my fridge. 

We are entering a new era for independent writers and publishers to embrace depth and quality, and WordPress.com is committed to empowering these creators — not just through tools and services that make the most of these evolving formats, but through community, distribution, and new ways to have your best work seen by millions of people across a wide range of diverse tastes and topics.

I’m really excited to have the Longreads team at Automattic. WordPress.com has been steadily getting better at showcasing fantastic writing from the millions of blogs we host, but this is going turn up the heat.


Why You Should Develop Plugins With wp-cli

I started work on a new plugin this week1 and I quickly started running into those little things that add up to a lot of wasted time while developing. So far that’s three things:

  1. Flushing a cache of data I retrieved from an API. (In this case, I process that data before caching it, so changes require a cache flush.)
  2. Saving setting data for the plugin.
  3. Getting the current setting data from the plugin.

In the past, I’ve done all kinds of silly things for these. For #1, I’ve hacked together one-off shell scripts, but usually just threw a delete_transient call in the plugin file and hit refresh. Fun times when you forget to remove that!

For #2, I’ve often hacked together a prototype of the eventual UI, and set up all the various save handlers (because that’s fun in WordPress!) just so that I could get data into the plugin. Oh, and then I change the data structure in mid-development and now I have to change the UI just to get that new data in.2 Fun! Or, when that approach grew tiresome, I’d take a cure from my #1 approach, and maybe hardcode an update_option call, or maybe override the getter function to return hardcoded data.

And #3 just comes in handy as a sanity check to see if the current data is what’s expected. Good for debugging. I won’t detail the hodgepodge of ways I’ve done this, you’re getting the idea.

This time, I started with a simple command: wp sekritplugin flush-cache. Then the curtain was drawn back, and I realized that three common tasks I’ve done in the past could be:

wp sekritplugin flush-cache
wp sekritplugin set --format=json < dummy.json
wp sekritplugin get

The great part about this is that in order to expose this functionality to wp-cli, I have to have it in my plugin, and I'm forced to make cleaner plugin API design decisions.

And here's a familiar scenario: I'm working on the backend of the plugin, while my teammate is working on the frontend UI. I realize there's deficiency in the data structure, and push a change. Previously, this wreaked havoc (been there). But now, I just pop a dummy.json file in our repo that replicates dummy content for the new data structure. My teammate runs:

wp sekritplugin set --format=json < dummy.json

…and is back up and running, no fuss, no muss. They can also look at the changset for the dummy.json file to get a quick sense of how the data structure changed.

Another great thing is that I can leave all of the data saving and validation tasks right until the end, when the data structure is finalized. No wasted time changing things in a rapidly changing plugin.

I'm sure I'll come up with more use cases as I move along, I'm only three days into this particular project.

So, tl;dr: adding wp-cli commands to your plugin is great for:

  1. Encouraging good API design
  2. Collaborating amidst a changing data structure
  3. Efficiency
  4. Better debugging

Commands are easy to write, so what's stopping you?

  1. Actually a ground-up rewrite, so new-ish. 
  2. If the data structure changes didn't break the UI prototype, which they probably did. 

Thanks WordPress

It’s tough to overstate the impact WordPress has had on my life. If it wasn’t for WordPress, I probably wouldn’t be working on the web, and I definitely wouldn’t be working for Automattic.

I’ve outlined my web development trajectory previously, so I won’t repeat those details here. What I do want to say is that I’m incredibly grateful to everyone in the WordPress community. To Matt and Mike, who started the ball rolling 10 years ago; to all the developers who’ve contributed; to all the unsung heroes in the forums; to all the theme designers who’ve made WP look a place we wanted to be; to all the bloggers graciously sharing their knowledge; to all the plugin developers making the ecosystem thrive, to everyone who’s been involved in ways that don’t quite fit into those categories: thank you, thank you, a thousand times thank you.

Web Development, WordPress

App Engine 1.8.0 is now available and includes a Limited Preview of the PHP runtime – your top requested feature. We’re bringing one of the most popular web programming languages to App Engine so that you can run open source apps like WordPress. It also offers deep integration with other parts of Cloud Platform including Google Cloud SQL and Cloud Storage.

This could be a big deal, especially if they build tools to make it easy to install WordPress on App Engine.

Google App Engine adds the PHP runtime