What breaks in WordPress, and what it really costs

The cost of owning a CMS is everything a site costs after installation: hosting, paid themes and plugins, updates, backups, protection from attacks and repairs.

The cost of owning: more than the price of installing

A site on a CMS seems free: the software is open source, and themes and plugins can be downloaded. But the cost has several parts, and the biggest isn’t money but time:

• hosting and a domain: paid every year (unless you use a hosted service such as WordPress.com, which bundles hosting and does much of the upkeep for a monthly fee);
• paid themes and plugins: the good ones are often sold by subscription;
• updates: the core, the theme, the plugins, and the version of PHP on the host;
• backups, and checking that they work;
• protection: a site on the most popular CMS is the most common target of attacking robots;
• repairs: after a failed update or a conflict between plugins.

Move the “A year in the life of a WordPress site” diagram below: it shows seven events that happen to almost every site, and what they cost under different settings.

This is a model with invented hours. It shows the shape of the costs, not an exact price.

Automatic updates are on There are backups away from the server Plugins: 8 Events shown: 7 of 7

1. January
   A minor security release of the core comes out
   You logged in to the admin area and pressed “Update”. Until you did, the site ran with a known hole.
   0.3 h
2. March
   A vulnerability is found in the form plugin, and the fix comes out the next day
   Until you noticed the email, the form people write to you through stayed vulnerable. This is the most common window for a break-in.
   0.5 h
3. May
   A major release of the core
   You need to check that your 8 plugins and the theme work with it. The more plugins, the longer the check and the likelier a conflict.
   2.3 h
4. July
   The cache plugin asks you to update its settings
   With a small set of plugins, conflicts are rare.
   0.3 h
5. September
   The plugin’s author stops releasing updates
   The plugin still works, but nobody will close the holes in it any more. It has to be replaced.
   3.0 h
6. November
   The host retires an old version of PHP
   The theme and the plugins must work on the new version. The older they are, the more work it is.
   2.4 h
7. December
   A wave of spam through the inquiry form
   You need protection from robots (a captcha or a hidden field). That takes time too.
   1.0 h

In all, about 12 h (with the monthly check). Automatic updates are off: you spend more time and live longer with known holes.

Text alternative: in a year a WordPress site gets core updates, vulnerabilities in plugins, conflicts, abandoned plugins and a retired version of PHP. Automatic updates and backups cut the time and the damage, and every extra plugin adds risk and work.

What needs updating, and how

WordPress is updated often. The core ships minor releases with security fixes (they install themselves, as they have since 2013) and major versions a few times a year (it’s better to test these before installing). Themes and plugins are updated separately, on their own schedules. Automatic updates for them arrived in version 5.5 (2020) and are optional. One more thing that needs “updating” is the PHP version on the host: old versions are retired in time, and your theme and plugins must work on the new one.

Two rules. Updates are installed on a plan, not when the site has already broken. And there is a fresh backup before any major update.

Security

Most WordPress break-ins don’t happen through the core but through plugins and themes. Thousands of different authors write them, holes in them appear more often, and not everyone closes them, or closes them quickly. A typical scenario: a vulnerability is found in a forms plugin, the author ships a fix the next day, and on your site the plugin is updated a month later. In that month the robots have scanned the internet and found your site.

What helps, and none of it is exotic:

• keep the core, themes and plugins up to date;
• install as few plugins as possible, and delete the unused ones along with unused themes instead of just switching them off;
• don’t use “nulled” paid plugins from dubious sources: malicious code is often hidden in them;
• use two-factor login for the admin area and strong passwords, and limit login attempts;
• give people different permissions: an editor doesn’t need administrator rights;
• keep backups away from this server (more on backups and monitoring in part 9).

There’s a general checklist in WordPress’s own hardening guide (see the sources).

Backups: a hope, not a backup

A backup is the files and the database of the site, kept separately from the site itself. If the copy lies on the same server, it’s lost along with the server when the server fails or is hacked. There’s an old “3-2-1” rule: three copies, on two different kinds of storage, one of them in another place. And the key point: a backup is tested by restoring it. A copy that has never been unpacked may turn out empty or incomplete, and you’ll find that out on the worst day.

Check yourself: why does restoring a site after a plugin conflict take longer without a backup?

Without a copy the site has to be built again: install the CMS, the theme and the plugins, and move the content and settings over. A backup brings everything back in half an hour.

Drupal and Joomla: who they are today

In the 2000s three systems fought to be the main CMS, and when you choose WordPress it helps to know the other two.

Drupal appeared in 2001 (Dries Buytaert started it as a small message board for his friends). It’s strongest where the content is complicated: many types of entries and relations, fine-grained roles and permissions, many languages, big portals and organizations’ sites. In return it needs an experienced developer and work on configuration, so a beginner finds it hard. Many universities’ and government organizations’ sites run on it.

Joomla (2005) came out of a fork of a system called Mambo. It’s often called the golden mean: simpler than Drupal, more powerful than the old blogging systems. Today its share is shrinking: according to the Web Almanac, both Drupal and Joomla have lost share over the years, while WordPress and hosted builders such as Wix and Squarespace have grown.

What to take from this. A small service site doesn’t need Drupal’s complexity: you’d pay for it with features you’ll never use. Joomla is hardly better than WordPress for you, and there are fewer people who know it. So on our list, for a small project, WordPress still wins, if a CMS is needed at all. And whether one is needed is decided not by taste but by two questions from lesson 1: who edits, and how often.

Practice

You’re in the era of 2010, and the site is working. Now write what is rarely written in time: an upkeep plan. Who updates, how often, what is copied and how much time it all takes. Name the risks of the plugin that takes your project’s inquiries or bookings. In the table, compare WordPress with Drupal and Joomla for your case, and give a verdict.

What was wrong with 2010

Sites of 2010 were often installed and forgotten. There were no automatic updates (minor core security updates began installing themselves only in 2013), dozens of plugins were installed, and backups lay in the same folder as the site. The result was thousands of hacked sites that sent out spam and viruses. Today the tools are better, but the habit of “install and forget” is still with us, and it’s still the most expensive one.