Open letter to Matt Mullenweg

Dear Matt,

I’ve been a long-time user of WordPress, clocking up well over a decade both publishing on and building plugins for it. I love it – and I even tried to get a job at Automattic (but that’s a story for another time).

Recently I’ve been really impressed with the work done around privacy, mostly prompted by GDPR. Well done for ensuring the considerable effort this required was made, and that privacy now has a much more prominent place in WordPress.

However, the trolling of privacy standards which I saw (online) at WPEU this week threatens to undermine a nascent and fragile respect of data privacy. I understand there are cultural differences between the EU and the US regarding personal data, but the WordPress community should – has to – be better than this, in the same way that we should be, and are being, better than to engage in other damaging activities (GamerGate culture, for example).

A possible immediate fall-out of these unhelpful comments was that, while 80 people were registered for Heather’s Developing for Privacy and Data Protection workshop, fewer than 35 showed up. We need *more* designers and developers to care about data protection, so anything that puts them off learning has the potential to be massively damaging to the privacy of thousands, possibly millions, of users their work will touch.

Heather has done amazing work in the UK and beyond for years, banging the drum that as a web industry we must professionalise to be taken seriously by users, legislators, and other industries. She was instrumental in the setting up of an industry body for the web in the UK. A commitment to privacy and data protection is a huge part of professionalising the web industry, in the same way that a commitment to safety is a huge part of a civil engineer’s attitude to their profession. It would be a huge shame to see WordPress further the “we got all your data, lolz suckas!” attitude shown by other big online players (looking at you, Facebook).

Please can you consider whether trolling comments like that help or hinder important work, while you continue to do a great job leading Automattic.

Kind regards, and thanks for all you’ve done for the web community.

Chris Taylor

Unit testing in WordPress

One of the things I really appreciate about developing in the .Net stack is the fantastic unit test support. Using mocking libraries like moq and leaning on the power of nunit to handle my dependencies means I can write unit tests that truly do test just the unit under test. True unit tests are useful for three very important reasons:

  1. That the code is doing what it should
  2. That the code handles unexpected inputs correctly
  3. That after refactoring the code continues to do what it did before

A robust, extensive suite of tests – both unit and integration tests – are crucial for good quality software and, fortunately, have been pretty common in the .Net development world for a long while.

When developing for WordPress, however, it’s not always been that way. I remember not so many years ago that test of any kind wasn’t something often talked about in the WordPress community. I guess we were focussed on getting code shipped.

Things have changed, and automated testing is now a recognised part of the WordPress development workflow. One of the problems with the WordPress Unit Test Suite, as pointed out by Greg Boone, is that it’s not actually a suite of unit tests – it has dependencies like a MySQL database, so would be more correctly called a suite of integrations tests. Pippin also calls these kind of tests “unit”, but they are definitely integration tests.

I’m at risk of over-egging this point, so please read this good description of the difference between unit and integration tests.

To ensure the large WordPress plugin I’m currently building is as good as it can be I want to build a suite of (true) unit tests. That means I need way of mocking WordPress functions (such as do_action, apply_filters and wp_insert_post) and globals such as $current_user and – crucially – $wpdb. It turns out there are a few options, which I’ve briefly investigated. I’ll be using WP_Mock and the PHPUnit test double features.

The well-known WP_Mock from the clever guys at 10up is the backbone of mocking WordPress. It allows you to mock any WordPress function with some simple syntax:

\WP_Mock::wpFunction( 'get_permalink', array(
            'args' => 42,
            'times' => 1,
            'return' => ''
        ) );

This will mock the get_permalink method when the only argument is the integer 42, ensuring it is only called once, and returning the string ‘’. Clever stuff.

There are other static methods in the WP_Mock class which allow you to:

  • Mock a method which returns the same value (a pass-through method)
  • Mock the calling of filters and actions
  • Mock the setting of actions and filters

Mocking $wpdb turns out to be pretty simple, as I can use the built-in test double functionality in PHPUnit. Sample code in the MockPress project wiki shows I can do this:

// in my test setUp method:
global $wpdb;

// whenever I want to mock a $wpdb function I set up the method to mock:
$wpdb = $this->getMock('wpdb', array('get_var'));
// and set the value I want to be returned from my mock method:

// now I can check the mock returns what I want:
$result = $wpdb->get_var("select anything from anywhere");
$this->assertEquals(1, $result);

I now just have to ensure my code is written in such a way as to make unit testing easy! I can highly recommend The Art of Unit Testing by Roy Osherove if you want to get into this deeply.

WordPress Calypso

Recently Automattic have announced the release of Calypso, a next-generation interface to manage or Jetpack-enabled sites. It’s a very ambitious project, but I believe they have some of the best developers in the world. Plus Andy Peatling, who I’ve had a huge amount of respect for since he initiated the BuddyPress project, ran the team.

The interesting thing for developers is their choice of technology stack. Calypso is a single-page app, powered by Facebook’s React library, node.js, with data coming from the WordPress REST API. All mod cons, and the interface is certainly beautiful, easy to use and very fast.

But I have to admit I have concerns about single-page apps, and the “modern” approach of total reliance on JavaScript to power a UI. JavaScript is the least robust of the Holy Trinity of web technologies (HTML, CSS and JavaSscript) as it does not gracefully handle errors. Many sites fall into the trap of thinking they can rely on JavaScript when they can’t. CSS is in the same boat, although if you get *some* CSS then whatever you get will be used to style the page. If you get just *some* JavaScript the likelihood is that nothing will work. It’s clear that the only resource which we can really count on – and even then, it’s not 100% guaranteed – is the HTML.

So, using my favourite progressive enhancement testing tool (turning off JavaScript), what do you see in Calypso when javaScript fails? This:

Unfortunately there’s nothing there, just the WordPress logo. Perhaps showing the “unsupported” message by default would be better, as this is what the Calypso app redirects to if the browser doesn’t support some modern JavaScript APIs or is iOS version 5 or earlier.

Here’s the (JavaScript) code that checks whether the browser cuts the mustard, with comments from me:

(function() {
    function isSupported() {
        var ios, version, ua;
        ua = window.navigator.userAgent;
        // check if the browser supports window.history, which allows changing the displayed URL without refreshing the page
        if ( ! window.history ||
            ! window.history.pushState ||
            ! window.history.replaceState ||
            ! ( '__proto__' in Object.prototype )
        ) {
            return false;
        function getFirstMatch( regex ) {
            var match = ua.match( regex );
            return ( match && match.length > 1 && match[1] ) || '';
        ios = getFirstMatch( /(ipod|iphone|ipad)/i ).toLowerCase();
        version = getFirstMatch( /version\/(\d+(\.\d+)? )/i );
        // check if the browser looks like iOS version 5 or earlier
        if ( ios && version < 6 ) {
        // disable for now because it is breaking Chrome on iOS
        //return false;
        // if we get here we know we can run the app
        return true;
    if ( ! isSupported() ) {
        window.location = '' + encodeURIComponent( window.location );

And this is the “unsupported” message (with cute Nessie image):

OK, on to performance. As I’ve mentioned Calypso feels really fast. One of the principles for the project was speed, and it shows. It’s also responsive, which for a powerful “app” such as this is no mean feat.

The resource stats show that it’s pretty big, however (this is from Google Chrome dev tools for a new post edit page):


The breakdown of requests shows a large amount of JavaScript (as you’d expect) and quite a lot of CSS:

Resource type Requests Total filesize
All 93 1.9mb
HTML 1 2.2kb
CSS 22 322kb
JavaScript 17 1.4mb
Images 12 13.5kb
Fonts 17 137kb

I was surprised at the amount of web fonts, which led me to look at the dependencies on other domains. Here’s how that breaks down (again, this is for a edit post page):

Domain Requests Description 7 Avatars 5 Web font stylesheets 11 Web fonts 34 Stats collection, jQuery, stylesheets, favicons and widget HTML 13 Stylesheets, main JavaScript files 2 Analytics tracking 1 Chat facility, presumably for customer support

I ignored subdomains and XHR requests (which are the requests to the API to get data) for this table.

Better stats that don’t rely on me manually counting rows in dev tools could be got from WebPageTest, and I may do that when I figure out how to get WebPageTest to log in to Calypso.

My conclusion from this very quick investigation is that while Calypso is a very slick web app (whatever “web app may mean) its total reliance on JavaScript means it could easily break for users on low-powered devices or using it dodgy network conditions. If the aim of WordPress is to democratise publishing then this has to be for users is the worst of browsing scenarios as well as those of us lucky enough to have fast machines, modern browsers, and fast and stable networks.

My belief is that the WordPress team know this, and that work is already under way inside Automattic to enable things like server-side rendering and handling of POST requests. And, in the mean time, the classic admin interface is still available.

What this means for the huge plugin ecosystem will be very interesting to find out. That’s a topic for another post!

New WordPress plugins

I’ve released a couple of new WordPress plugins recently which I thought I’d waffle on about.

Theme Reset

I had a situation not too long ago on a WordPress MultiSite site I run where I had deleted some themes but there were still some sites using those themes. I needed to reset all the sites to use the same theme, but there wasn’t an easy way to do it. So I made a plugin.

And here it is: Theme Reset. There’s not much to it; you have to be a network admin to get the option, and you can choose any installed theme. That’s it.

Child Themes

The other plugin I released is also theme related. This one allows you to create a child theme from any installed theme. Just click “Create child theme” on the theme you want to be a parent, fill in a simple form and boom – the new child theme is created and installed.





I’m no designer (as you can probably tell) but this seemed like a good idea that could save people some time.

Responsified and updateified

That old proverb about the cobblers children going barefoot is true. For too long this site has been neglected and unloved. Well, no more! I’ve realigned (not redesigned) this site to take advantage of modern web development techniques. Of course, I’m talking about responsive design.

It’s not a radical departure from what was there before, and talking advantage of the excellent Bones starter theme meant the whole thing was done in a few hours. And even though I haven’t paid too much attention to performance I’ve still ended up with a respectable payload for the homepage:

Homepage payload

And even YSlow gives me a B grade:

YSlow grade B

I’ve also updated to WordPress 3.7, named in honour of the great Count Basie. The update was, it has to be said, not as slick as usual. I had “out of memory” problems which weren’t that hard to fix, but did cause me some stress.

WordPress 3.7 is the first version with auto-updating built in, so hopefully my installation will keep itself up to date and in tip-top condition while I’m asleep.