Wordpress vs. Drupal: Everyone’s Got A Weak Spot

Through (painful) trial and error, we know the secret to choosing between bad fast food on a long road trip: sometimes it’s best to focus less on the “positives” and to instead think, Which is going to hurt less tomorrow morning?

This exercise can actually be helpful in surprising places - even in the old WordPress vs. Drupal debate. Part of the secret to determining the best CMS for your site is figuring out which CMS is most likely to cause the least headaches when you go to put it in use.

Certainly, neither is the perfect option for any site, but knowing where each falls short can help decide which is worth sinking your time - and budget - into.

The Worst Warts of WordPress

Despite what many WordPress evangelists claim, WordPress is not a magical unicorn-powered web dev cure-all. As user-friendly and versatile as it may be, it does have some rather severe shortcomings.

Limited Functionality Out of the Box

WordPress was designed first and foremost as a blogging platform. That’s not to say it can’t be something different, but if you want extra features, you’ll have to install plugins. Lots of plugins.

Simple things like caching your site, customizing your admin menu, or managing your user permissions all require plugins in WordPress. The WordPress ecosystem is not as strongly devoted to compatibility as WordPress itself is, which means at some point in your site’s development, you will end up banging your head against your desk trying to figure out which two plugins just aren’t getting along.

What’s a Theme For, Anyway?

WordPress, like almost every other CMS, has the concept of themes and plugins. Themes are supposed to only affect how your site looks, while plugins are supposed to add additional features like new user roles, shortcodes, content types. There is supposed to be a clear boundary between them, so that you can easily swap out one theme for another one without completely breaking your site.

Unfortunately, many themes -- especially ones that market themselves as turn-key ‘theme engines’ -- hook into the WordPress innards and completely take over the functionality of your site. This can make it difficult to update the appearance of your site without doing a complete rebuild, because your content is completely locked into that particular theme.

Even if you’re just tweaking a theme, many WordPress guides tell you to add features to your site by putting snippets of code into a special file in your theme called functions.php. This file is intended to be used for things like defining new image styles for theme, or creating a function to add ellipses to text… But this is not what these guides tell you to use it for. They tell you to use it to define content types, user permissions, redirects, and even entire widgets. If you can dream of a feature, you can probably find a WordPress tutorial telling you to create that feature entirely in your functions.php file.

Adding new site features in your theme is so common that one of the first things you often try when debugging a WordPress site is to disable your custom theme and revert to one of the default WordPress themes, so that you can tell if your theme is causing a problem with your plugins.

The consequence of using your functions.php file as a code dump is that your theme is no longer concerned with only the appearance of your site. Instead, it’s now an integral part of your sites functionality. If you want to give your site a facelift down the road, you’ll be in for a painful experience, because your site’s appearance and functionality are squashed together in a big, dirty ball of mud.

To be fair, this is one of those things where if WordPress is ‘done right’, it’s not a problem. Doing it right in this case would mean that you would almost completely avoid functions.php in favor of site-specific plugins. But creating a site-specific plugin is harder than copy-pasting code into a single file, so even though this is a best practice, it’s rarely recommended -- especially to beginners -- and therefore rarely practiced.

Raw PHP templates?

By default, WordPress uses raw PHP code to build its templates. This makes sense on the surface, as PHP was initially created as a templating language. However, in 2017, writing a template in plain PHP is both a slog and a footgun. Raw PHP has some notable shortcomings:

• It’s overly verbose and can be hard to read
• It’s insecure by default, meaning you have to go out of your way to write safe code that protects your users and your server
• It encourages -- or at least don’t discourage -- mixing functionality with appearance (cf. the tragedy of functions.php)
• It often forces developers to know things about how the underlying data is structured that are not relevant to how the site should look (e.g. is this value an array? A stdObject? An ArrayObject?). This can increase both the complexity and verbosity of templates.

Luckily, there are projects like Timber that aim to address this issue, but creating an idiomatic WordPress template still means writing it in raw PHP.

Plugin Compatibility

Plugins and themes have virtually unlimited access to the innards of WordPress. When you have a large number of plugins -- which you absolutely will, if you try to do anything complex with WordPress -- it’s likely that you will end up using plugins that are incompatible with each other, and you will spend hours trying to (1) figure out which plugins are breaking your site and (2) how to get them to play nicely with each other.

Plugin compatibility is also a moving target. While WordPress core has a strong focus on backwards compatibility, third party plugins and themes often do not. This means that just because you’ve managed to get all of your current plugins and themes working together now doesn’t mean that a seemingly insignificant update (e.g. 1.0.1 to 1.0.2) won’t completely (and confusingly) break your site in the future.

Plugin Security

Poorly written plugins and themes can expose gaping security holes in your site. When people talk about WordPress being insecure, what they usually mean is ‘because many WordPress plugins are awful, and because you need to install 20+ plugins to accomplish anything remotely complex on WordPress, at some point you will probably end up installing an awful plugin that exposes your entire database to any script kiddie with a copy of WPScan.’

Story time: once upon a time, the Altos dev team was migrating a WordPress site to one of our servers. During a security audit of the site, we noticed that in order to support customizable theme colors, the site’s theme was exposing raw user input to the database. This means that by simply appending some nefarious text to the end of a URL, attackers could possibly have had total access to the site’s database, including user and post data. This wasn’t some backwater theme with only a handful of users, either. It was a well regarded theme with tens of thousands of downloads, and what’s worse, the theme marketed itself towards users who don’t know how to code, and who wouldn’t know to even look for such trivial attack vectors.

Because this site was built like most WordPress sites -- that is, with the theme parasitically bound to the functionality of the site itself -- we could not easily transfer the site to a different, more secure theme. Rather than rebuild the site from the bottom up, we ended up altogether abandoning WordPress for this project, and converted the site to safe, static files.

Maintenance Costs

Many popular WordPress plugins and themes are not free. Some are freemium, some use one-time purchases, and some have annual licensing models that force you to buy the product year after year. Depending on what functionality your site needs, it’s easy to get nickel-and-dimed when building or maintaining a WordPress site. As a rule of thumb, we often assume a basic ecommerce site will need at least $500 of plugins.

It’s also important to keep plugin compatibility in mind, since the overhead of keeping all your plugins in sync can also prove to be a lot more work than expected (or budgeted for).

Drupal: Home of the High Barrier-Of-Entry

While Drupal may often be the ideal choice for complex sites, it’s usually not the simplest. Drupal’s flexibility comes at the expense of complexity, and it has a not undeserved reputation for being difficult to learn. Unless you’re an experienced developer, the complexity of building a Drupal site may not be worth the benefits.

For small budget projects, the difference between getting a Drupal site up and running vs doing something similar with WordPress can be a significant cost difference. While a base install of Drupal can be done almost as quickly as a base install of WordPress, setting everything up afterward -- your custom content types, your themes, your site configuration -- takes time, elbow grease, and know-how.

For large projects, the time and cost of the initial setup are less of an issue, because they are usually insignificant compared to the overall cost of the project, and the time spent bootstrapping a complex Drupal site can often pay dividends later on.

Raw PHP Templates (pre-Drupal 8)

Like WordPress, previous versions of Drupal used a theming system built on raw PHP. In fact, because Drupal’s innards are so complex, writing a theme in Drupal 7 was often more complicated than writing a theme for WordPress.

Luckily, this has changed in Drupal 8, with the adoption of a popular third-party theme engine called Twig. Twig allows developers to write themes in a beautiful, concise syntax, which is then automatically converted into fast and secure PHP.

A Very Particular Set Of Skills

Because it is both highly complex and much less popular than WordPress, there are fewer developers out there that are familiar with Drupal. Even so, the Drupal community still has over 1,000,000 members, though, so it’s not exactly hard to find a Drupal developer.

Starting with Drupal 8, Drupal also now uses a lot of third party code and modern PHP best practices, so it should be much easier to onboard any PHP developer familiar with modern Object Oriented PHP, even if they’ve never had experience with Drupal.

Choose Wisely, Young Grasshopper

So both of the popular CMS systems come with their own flaws and shortcomings - what doesn’t? It’s not about finding the perfect solution that’ll never cause problems; smart developers know that issues are often unavoidable. It’s about what you can do with the tools you’re given that makes the most difference.

At Altos, we like Drupal. It’s robust, customizable, and complex enough to make cool things happen when we want them to. But for a lot of projects, we recognize that the simplicity of WordPress can be a feature, not a hindrance, and we’re happy to recommend it to our clients.

Think, plan, and make your choice based on what exactly it is you need, even if that means anticipating struggles ahead of time. In fact, you might even enjoy the challenge.