The Register has a refreshing take on the whole AI Thing.
I subscribe to Warren Ellis’ Orbital Operations newsletter, his regular Sunday rundown on where he’s at and what he’s doing. I always intended this site to work in a similar fashion to the warrenellis.com of old, a hark back to an earlier, slightly wilder web, and OO, for me at least, feels like a weekly best-of of that site.
Anyway, in this week’s edition, he refers to preparing for Autumn as “rig[ging] for the long dark” as opposed to Spring cleaning. That appeals to me at a very base level, that hunkering down and hiding from the encroaching darkness and sitting by the fire, spices and smoke in the air.
I’ve been on a four week death march for work, and have escaped to France for a week to unwind and see old friends. It’ll be good for me, and when I return I’ll be bouncing straight out to Ireland for DrupalCon, to learn and connect and embed in a new ecosystem. I’m looking forward to that, but for this week I am planning on burying myself in cheese and wine.
Online advertising: frogmarching us ever forward into the grim meathook future?
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 WordPress.com) 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.
Been happily massaging my aching brain to this, this afternoon.
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.
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.
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.
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.