My project manager asked me recently whether Drupal or WordPress was the better choice for building a “long term, scalable” solution for a potential client project. With no other information, I submitted WordPress, as I’m convinced that the long-term development goals of the WordPress core team, plus the proven scalability of WordPress (amply demonstrated by makes it a solid choice for scalable content management, and I don’t like Drupal’s approach at all, even if it has a reputation for “enterprise-ready” content management.

However, it did get me thinking about what people mean when they say “scalable” in this context. If we assume one baseline definition of scalability as “able to cope with the growing demands of an increasingly large user base”, then a series of other priorities come to the fore. Not only does it have to cope with increases and spikes in traffic (let’s set that baseline as “not likely to crash after getting Reddited”), but it has to do it within a certain budget and with the minimum of technical input from a team of people who may or may not be technically comfortable, or indeed competent, with the underlying technologies.

There’s a bit of a recipe you can follow for scalability with WordPress. It starts at the foundational level of WordPress itself, and how you extend it. If you abide by best practices in development, don’t overload it with leaky, inefficient plugins and keep your assets lean and mean, you’re off to a good start. Standard front-end development best-practices such as concatenation and minification of site-wide assets such as JS and CSS, using a CDN to deliver those assets, enabling caching on the server and client side, etc. will save you a lot of headaches later.

Specifically to WordPress, you’ll save yourself a lot of time and heartache if you stick to using the built-in database structure and queries – I’ve seen cludged-together, bolted-on solutions to WordPress projects that reinvent the wheel doing things that WordPress does natively, and does well. These do nothing but betray the developers’ inexperience with the platform and create problems for future developers. More often than not, when WP developers complain of legacy code in a clients codebase, this is the kind of thing they’re referring to.

This leads us into a different definition of scalability – the ability for the site to grow organically without constant rebuilds or hacks. WordPress is excellent at this if you make use of hooks and filters, both of which can be augmented by the developer.

For instance, if you’re creating a new theme for a client, and you know that there are going to be points in the future where they’re likely to want to bolt new bits into it, peppering your theme with theme-specific hooks to give those new bits somewhere to live will make everybody’s lives easier, without adding any real technical debt to the project. A good example of this is for seasonal promotions – if you know you’re likely to run a sub-header banner beneath your primary header across the Christmas period, having a predefined hook that you can create a feature plugin to hang on means you can leave the core theme files alone, preventing post-Christmas cleanup and the misery of keeping track of what extra bits you’ve introduced to core files. Separation of concerns in this regard is incredibly useful.

There is, of course, a lot more to scalability. Correct implementation of server-side technologies such as PHP7 and nginx will go a long way to ensuring the site is solid; a strong content strategy to ensure that content is properly organised and searchable; a sensible approach to page caching with tools such as WP Super Cache – all of these things (and many more that I’ve left out here) are good first steps. I think that by abiding by best practices we can begin to seriously challenge the misconception that WordPress isn’t suitable for “enterprise” content, whatever that means.

Cunning Plans by Warren Ellis

Really enjoying this; Warren’s been one of my favourite writers for a long time,  Shivering Sands, Gun Machine and Crooked Little Vein have pride of place on my bookshelves, alongside a large number of his comics.

Undisclosed – 2F2D30

Really nice string of anonymous ambient releases from Headphone Commute. Great working music. The hex codes for the album titles are a nice touch, too.

Twenty nine

Greetings from Rhodes; we’re spending my birthday in Lindos, where Nim’s family have been visiting since the dark ages but I’ve been catching up on the fun for the last couple of years. I’m writing this from a sunny rooftop, on the WordPress app on my iPhone.

I survived another year. Hello.

Return to sender

“Postcard’s failure may be an indication that people are still not ready for decentralized social networking, where you host your own data and distribute it to third-party social networks at will.”

There’s more to it than that, I think, but it does tie in neatly to my previous post about IndieWeb. I’d like to think there’s a future for this kind of thinking, but the licensed content model might not be it.


I’ve been looking at what the IndieWeb guys have been doing, and so far I’m pretty impressed. It’s still perhaps a little too geek-centric for the normal people to grok, but that’s a matter of education and UX more than technology. Still, the personal-site-as-homepage harkens back to the early days of the web, which gives me a nice warm feeling.

Whatever happened to Diaspora? I’ll have to look that up again, although if I recall correctly the underpinning idea wasn’t too far off what BuddyPress has become.

Switching from Sublime to Atom

I switched from Sublime Text to Atom a few months ago, more on a whim than because I was dissatisfied with ST3. It’s hurtling towards its 1.0 release, at which point it will be deemed ‘stable’ by the core team.

It feels like the future of this kind of tool, because it uses the same technologies that underpin the modern web itself. You could build Atom with Atom. That’s pretty neat, in and of itself. I know it’s not unique – Brackets does the same thing, for instance – but the implementation is intuitive and generally pretty great.

It’s hard to nail down what draws me to Atom over Sublime. On the surface level, I found the learning curve of Sublime too high to delve very deeply into its customisation. Atom is laid out bare. Your favourite front-end framework doesn’t have a snippets library for Atom yet? Making one yourself is as smooth and painless as I’ve come across for that level of personal tooling. Want to inject some of your personality into your editor? Get hacking on the CSS. Not happy with a keyboard shortcut? Changing it is easy. It’s all right there.

But I think there’s something else. It’s not just about the technology, or the hackability of the thing – it has a really great feel. It feels like Slack or Dropbox, or Github itself. Modern and slick and well-built, friendly and inviting with being toylike or feeling underpowered. When you spend all day in front of a tool, that kind of thing goes beyond mere fripperies like usability or convenience and ascends it to something closer to joy.

Turbines to speed

I’ve lost count of the number of times I’ve built this site.

I mean seriously; I’m a web developer, this should have been done and dusted years ago. Problem is that I’m also my own worst client and every time I think I’ve nailed it into place, it slips away from me and I have to start again at square one. It’s a pretty classic designers’ dilemma.

So in the end I decided to hack together a Twenty Fifteen child theme and just get the hell on with it. It’s about the words, after all, and the WordPress core team has forgotten more about building blogs than I will ever learn, so why reinvent the wheel?

So here we are.