Foundry does a substantial amount of work with WordPress. It’s by far the most popular combination blog/CMS for small websites, and frequently clients request it specifically or are already using it. And if not, then sometimes we recommend it based on clients’ business requirements, technical expertise, or other factors.
Recently we finished our first production deployment of WordPress on Heroku. Heroku presents an application hosting solution that has the performance and reliability of dedicated hosting, but relieves the client of the long-term obligation of maintaining one or more virtual private servers.
I’ll go into detail about why we chose Heroku and what challenges we faced deploying WordPress there in the near future. But before that, I want to answer another question: why WordPress?
Why not WordPress?
Because WordPress is terrible.
- It’s a monolithic application loaded with features that can’t be turned off but aren’t useful in every case, which increases the attack surface and memory footprint.
- It’s built on PHP, which has little to recommend it against more modern, disciplined interpreted languages like Python and Ruby, except perhaps that it is suitable for cheap shared hosting environments.
- Its separation of framework, application, configuration, and data is very poor. For instance, some configuration lives in a file in the filesystem and some lives in the database, and the database schema can sometimes change based on what plugins are being used and how they are configured. This makes data migration during major upgrades or for new deployments challenging.
- It’s slow, in part because it is undisciplined about how the database is accessed and because PHP applications must choose between speed and code organization.
- It is built with the expectation that the application can safely modify its own filesystem (for instance, uploading image files in subdirectories of the application, or caching data to disk in plugin subdirectories). This even extends to being able to update WordPress itself through WordPress’ own admin console, which sounds convenient but which has deleterious side-effects that make it unsuitable for multi-web server environments, where multiple servers need to have synchronized copies of the same framework and application code.
- It’s known to have significant security issues, which are exacerbated by deployments that allow the application to overwrite its own application code. One way to mitigate this is to deploy the application in such a way that it cannot modify its own filesystem (ensuring the webserver does not have suitable permissions etc.), but this is complex: features that rely on filesystem modification cannot be hidden and will appear broken if a user attempts to use them, and many plugins require certain directories to be writable in order to function.
- Its database schema changes during upgrades, but the specifics of how it changes during each upgrade are not well-documented. Because of this, automatic schema migrations can not be safely rolled back without also resorting to a database backup (costing the user all content and comments committed after the backup).
- Its technical documentation is uneven, and searching the web for information on common WordPress issues often exposes answers which are out-of-date or which make assumptions about the application’s environment.
- It is only compatible with MySQL, which among other things means that schema migrations for WordPress upgrades, plugin installation, etc. cannot be done inside a transaction.
- Its community-provided plugins are typically poorly or totally un-documented and are rarely verifiably functional on the latest version of the framework.
I could go on.
To summarize, WordPress is built on antiquated technologies, has substantial technical debt, and is not compatible with modern best practices on how to serve and scale web applications. It does everything, but it doesn’t do anything particularly well.
So, why WordPress?
My laundry list of technical issues above may make me out to be anti-WordPress, but we still use it. Why?
Primarily for three reasons: because the parts of the application that the client uses (the admin interface) are presentable, because the features cover a lot of bases, and because there aren’t many good alternatives.
All of the features built into WordPress, plus the breadth of plugins available, combine to serve most of the business requirements of our small clients. Even though I complained about the “bloat” of WordPress in just the previous section, the fact that so many features are available is a plus in the end. WordPress is most suitable when used as a blog, but it is also a passable CMS (at least when compared to the thin ranks of modern non-PHP CMSes). It can even be converted partially or wholly into an e-commerce platform, although recently we’ve started encouraging clients to adopt Shopify instead of tacking on e-commerce to WordPress for most situations.
Although plugin support and quality is uneven, there is a WordPress plugin to address nearly every need. Even those that they are technically poor may be full of features that are useful to clients. And usually, technical issues with plugins are just a problem for the developer to solve, whereas once they are working they are a benefit to the user.
Some of the plugins we use frequently include:
- W3 Total Cache, which speeds up WordPress considerably for cache hits, at the cost of a dramatic increase in configuration complexity.
- WordPress SEO, which tailors WordPress to be in line with more-or-less up-to-date thinking on search engine optimization.
- WPtouch Pro, which renders acceptably styled pages for mobile and tablet devices with very little configuration.
- Disqus, which replaces the troubled and slow native WordPress comment system with a much more scalable, social media-friendly solution.
- Google Analytics for WordPress, which allows for highly granular customization of Google Analytics tracking from within WordPress.
Additionally, it’s at least minimally user-friendly for content producers. While the technical internals of WordPress are poorly documented, the documentation for user-facing parts of WordPress is not as bad, and WordPress is so widely used that it’s possible to get help for most common problems one way or another.
Perhaps for these reasons, some companies use WordPress for extremely high-traffic sites despite the technical challenges: for instance, the New York Times, CNN and Reuters (all three for blogs) and Gawker (for their main content, which is also essentially a collection of blogs).
Every time we have the opportunity, we explore options for specific clients other than WordPress, especially those running on modern frameworks such as Django or Rails, but usually we run into the same problems:
- The client may need a feature that is included in WordPress or available as a plugin, and is not available for other candidates. Even if it’s fairly minor, any feature that needs to be written from scratch will be expensive and time-consuming to implement on another platform.
- The client’s requirements may be vague or uncertain enough that we can’t risk selecting a platform that is less all-purpose than WordPress without running the risk of expensive custom implementation later on.
- The client may have stakeholders and content creators who are already familiar with WordPress, and the opportunity cost of selecting any other platform would therefore be higher.
- CMS, blog and combination CMS/blog alternatives to WordPress that run on modern, well-supported frameworks such as Django and Rails tend to be immature and not widely-used, so adopting them is a bit of a gamble, for both developers and end users.
At Foundry, we’ve often discussed adopting a competent modern alternative to WordPress, trying to build up technical knowledge on how to apply it, and contributing to the project to remedy deficiencies if possible. However, we’re still looking for a candidate that even comes close to being as broadly useful to our clients as WordPress.
In the meantime, we go to war with the CMS we have.