Even in the fast-changing world of web technology, WordPress stands out. Sixteen years ago, it was a humble blogging platform. Today, it powers nearly a third of all the public websites on the internet. And all this happened without the backing of a technology behemoth like Microsoft, Apple, or even Red Hat.
The WordPress story isn’t without a big, fat asterisk. The same features that make WordPress websites so easy to build can send developers sailing into dark waters. If you’ve ever lived with a WordPress website over the long term, you’ve probably experienced security shortcomings, plugin conflicts, brittle templates, and other headaches.
That’s not to say that WordPress is a bad choice for website development. But embarking on a large-scale WordPress project without understanding the limitations and complications of the platform is most definitely a bad idea. In this article, I outline four of the most serious pain points with WordPress, along with some advice for how you can deal with them before they blow up into bigger problems.
1. Plugin Hell
There is no way to build a practical, modern WordPress website without using plugins — and lots of them.
Even seemingly simple tasks need plugins. For example, imagine you build the plainest possible website, with static content. Do you want WordPress to run PHP on the web server every time someone visits a page? Of course not. But unless you install a caching plugin, that’s the situation you’re in.
You face the same reality if you want to add search engine tags, make differential backups, add comment forms, or take basic security measures against denial of service attacks.
Again and again, essential features are handled by separate plugins that you need to find, vet, and install.
The benefit of this design is that it keeps the core WordPress engine clean and comparatively lightweight. The disadvantage is that there are only so many times you can patch new features into the same extensibility points before you risk a conflict. And plugin conflicts can be ugly.
In the worst case scenario, you can end up with one plugin that breaks another. Or, a combination of plugins that break your site. Or, more commonly, a family of plugins that seem to work happily together, but break your site after a routine WordPress update. The only solution is the famously primitive approach, “disable every plugin, and re-enable them one at a time.” If you need a reminder of what DLL Hell was like back in the era of Windows development with COM, this is the closest equivalent you’ll find.
How to cope
You can’t avoid Plugin Hell, but you can contain the damage. Here are some good practices:
- Use the smallest possible set of plugins. Don’t install anything you don’t absolutely need.
- Seek out the most popular plugins from the biggest and most reputable publishers — they are more likely to be updated regularly, tested in a variety of configurations, and have their problems identified quickly.
- Be especially careful to avoid plugins that have overlapping responsibilities, because two plugins that try to do the same thing are likely to collide. (Remember, one SEO plugin is good. Two are not better.)
2. The expanded attack surface
The WordPress plugin system introduces another headache. As you add features with plugins, you also add potential security vulnerabilities.
This won’t surprise any web developer, but the risk is more insidious than you might think. After all, the core WordPress engine is a massive open source project. During the development cycle, its code is put in front of hundreds of working programmers. By comparison, many plugins have just a single developer — one who may be busy juggling other projects and responsibilities. Old plugins are a particular problem. If a developer abandons your favorite plugin, the old version lingers on, putting your site in harm’s way.
Every plugin is a potential vector for attacks, even if the plugin is disabled on your WordPress site.
How to cope
Unless you’re willing to do what some large companies do — develop your own in-house WordPress plugins—you’ll need to accept that every plugin brings an unquantifiable security risk. But there are some common sense ways to defend yourself:
- Always practice good plugin hygiene. Don’t install plugins from creators that don’t have an established reputation. (Even if the code is safe today, a future update might not be as reliable.) When a new version is available, update your plugin at the soonest opportunity. And uninstall any plugins you don’t use to cut down on the attack surface you’re presenting to the hackers and script kiddies of the world.
- Regularly review WordPress vulnerability lists, like WPScan, to see if someone’s discovered a problem in one of your plugins. The world is full of vulnerable WordPress websites, so you can often avoid attention just by keeping your site more up-to-date than the rest of the pack.
3. Live changes and no safety net
Here’s a sensible three-step plan for updating a website: Make your changes, test them, and upload the finished product. And here’s the way things work in WordPress: You make your changes on the fly and watch them take effect immediately.
The sad reality is that WordPress has no built-in way to manage site changes. It has solid tools to manage content changes — for example, you can schedule future posts, keep content private while you test it out, and use basic version tracking if you need to roll back to an older version of a post. But if you want to change something as simple as a menu, you need to make live changes with no way to revert back to your previous configuration. That’s a problem.
In a large, established website, the “cowboy” model of head-first updates is an unjustifiable risk.
How to cope
There’s no getting around it — if you’re creating anything more than a small WordPress site, you need to develop your own internal staging process.
Here’s the basic idea. First, you build an internal website that duplicates the public website. You need an exact copy of the WordPress application folder, and a recent copy of the content (the data from the MySQL database). You can use this environment to test out your changes before you push them to the live web server.
Unfortunately, WordPress doesn’t have any built-in tools to help you manage this process. But help is available:
- You can use a plugin like Duplicator to download a copy of your public website. (Uninstall it when you’re finished.)
- If you just want to try out possible changes, you may not need a full web server. There are a number of tools that let you run lightweight local copies of the WordPress environment, like InstantWP. Use it for quick experiments and tests.
- If you’re really lucky, your web host may offer its own staging feature, which definitely cuts down on the work of managing the update process.
4. Themes: The golden handcuffs
The single most important decision you make for any WordPress site is choosing its theme. Not only does a theme set the visual style of your site, it also defines the homepage layout and determines how key bits of functionality (like the menu system) work across your site.
The theming system gets you started quickly, but it also ties your hands in some uncomfortable ways. Despite what you might assume, themes are not modular. There’s no way to combine parts from different themes. Details like transition animations and mobile support are fused together with all the other details about fonts and colors. The bottom line is that when you pick a theme, you’re locked into a number of design decisions until you’re ready for a complete redesign. And don’t ask what happens if the theme designer stops updating the theme you’ve invested in for your site.
WordPress has two mechanisms for theme customization, but both fall somewhere between awkward and broken.
To change the inner workings of a theme, you can create a child theme that replaces one or more of the theme templates. This replacement works in an all-or-nothing fashion on a file-by-file basis. As a result, it’s almost never possible to change a basic part of a theme — like its navigation system — without rewriting the whole thing.
The second mechanism for theme customization is using an additional CSS file to override theme styles. Once again, it’s difficult to isolate just the part you want you want to tweak. Many themes rely on third-party CSS libraries like Bootstrap, so even trying to change a small detail can pull you into a mess of overlapping style definitions. An even more difficult task is trying to copy the styles from your WordPress site so you can create matching non-WordPress pages elsewhere on your site. Before you know it, you’ll end up with a maze of duplicate style definitions, multiple versions of Bootstrap or jQuery, and a kind of Theme Hell that rivals the Plugin Hell you learned about earlier.
How to cope
Once again, if you’re a big company you can solve this problem by going deep and creating your own custom theme. Unfortunately, building a theme is a task that’s far more complicated than building a WordPress site. You need a detailed understanding of the WordPress pipeline, a solid familiarity with PHP, and the front-end expertise to deal with everything from cross-browser compatibility to mobile support.
The simpler alternative is to purchase a theme framework. A theme framework is — at its core — a standardization system for themes. It adds some useful benefits:
- You can switch painlessly between different themes that use the same theme framework. (Without a theme framework it’s possible to switch themes, but you’ll leave important details and customizations behind when you do.)
- Theme frameworks lay out a valuable future path. You can start with a prebuilt theme that uses the theme framework you want. Then, in the future, you can switch to a theme you’ve created that uses the same theme framework.
- Even if you don’t use any of these features, theme frameworks are the most popular and professional offerings from the companies that develop themes for WordPress. Which is just a fancy way to say that the theme you buy through a theme framework is more likely to be one that sticks around, rather than becoming another piece of abandonware in a couple of years.