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.