The code you did not write

A plugin is a piece of software somebody else wrote, which you add to your website with one click to make it do something it could not do before. There are about sixty thousand of them. This website uses none.

October 2026

Plugins can now hook into nearly every action WordPress does.

WordPress 1.2 “Mingus”, release announcement, 22 May 2004

That last sentence usually gets one of two responses. Either “how is that possible”, or “why would you make life hard for yourself”. Both are fair, and the answer to both is the same: for a small site with a stable purpose, a plugin is almost always more machinery than the job needs, and all of that machinery is machinery you do not control.

This is not a complaint about plugins. I have been using WordPress since its first versions, and I would not have had a career in it without them. It is an argument about where the line sits, and about what you are actually agreeing to when you press Install.

May 2004, and the sentence that built an industry

WordPress 1.2 was released on 22 May 2004 under the name “Mingus”. The announcement contained one line that mattered more than the rest of the release put together: plugins could now hook into nearly every action WordPress does.

That is a remarkable promise, and it was kept. It meant that anybody could change anything about how WordPress behaved without touching WordPress itself — and crucially, that their change would survive the next update. Hooks are a genuinely elegant piece of engineering, and they are the reason an ecosystem grew up around this software rather than around any of its competitors.

The timing was extraordinary. That same month, the makers of Movable Type — then the serious choice for anybody who wrote on the web — announced a new licence with limits and prices that their users had not expected. A great many of them went looking for somewhere else to go, and found a free, open, newly extensible alternative waiting. I was one of them.

So when somebody tells you plugins are a liability, remember that they are also the reason the thing exists at all. The question was never whether to extend WordPress. It is who writes the extension, and what else comes along with it.

What you are actually installing

Here is the part that is rarely said plainly, because once you have said it the Install button looks different.

A plugin is PHP that runs inside your website with exactly the same rights as WordPress itself. There is no sandbox, no permission screen, no list of what it may and may not touch. It can read and write every row of your database, create tables of its own, schedule jobs that run when nobody is looking, load scripts and stylesheets on every page, read and write files, and make requests to any server on the internet. It does not ask you first, because there is no mechanism by which it could.

Compare that with your phone, where an app has to ask before it reads your contacts. WordPress has no equivalent. A plugin that counts page views and a plugin that handles payments have precisely the same powers, which are all of them.

And it keeps those powers afterwards. An update arrives from a server you do not control, written by somebody you have never met, and installs itself — often automatically, which is the setting everybody is told to use, for good reasons.

October 2024, when that stopped being theoretical

Advanced Custom Fields was one of the most widely used plugins in the WordPress world, on millions of sites, made by a company called WP Engine. In October 2024, in the middle of a public dispute between WP Engine and Automattic, WordPress.org took the plugin over, renamed it Secure Custom Fields, and published it from the official directory as the continuation of the same listing.

Site owners found out the way you would expect. On sites with automatic updates, the plugin simply changed. Administrators who update by hand saw an ordinary update notice, applied it, and ended up with software from a different publisher under a different name. Nobody was asked.

Set aside who was right — the dispute is genuinely complicated and both sides had arguments. What matters here is the mechanism, and the mechanism worked exactly as designed. The update channel is a pipe from somebody else’s decisions into your website, and when the people at the other end change their minds, your site changes with them. That is not a bug in the system. That is the system.

The numbers, which are not subtle

Patchstack publish a yearly report on security in the WordPress ecosystem, counting every vulnerability disclosed. In 2025 they recorded 11,334 new ones, a rise of about forty per cent on the year before.

Of those, roughly nine in ten were in plugins. Themes accounted for most of the rest. WordPress core itself — the software everybody blames — accounted for six. Not six per cent. Six.

That ratio has been roughly stable for years, and it is the single most useful fact in this entire essay. “WordPress is insecure” is, almost always, a sentence about something somebody installed.

What I do instead, concretely

None of this would mean much without examples, so here are mine. Every one of these replaced a plugin that exists and is popular.

• The email address on this page is produced by a shortcode of about eight lines, which hands the address to WordPress’s own antispambot() function so that harvesters see encoded nonsense and people see an address. The alternative was a contact form plugin, which brings a database table, a settings screen, a spam service and somewhere between four and fifteen requests per page view.
• The retreat listings on a client’s site are two shortcodes and a custom field. The alternative was an events plugin with a calendar, a ticketing module and a mailing-list integration, for a page that lists six dates a year.
• The privacy, accessibility and colophon pages are created as drafts by thirty lines in the theme when it is activated, so that every site I build starts with them already there.
• There is no cookie banner on this site, and that is not a legal position — it is an arithmetic one. Nothing here loads from anywhere else, so there is nothing to ask permission for. Almost every banner you meet exists because somebody installed something.

Together those are a few hundred lines of code that I wrote, that I can read, that sit in version control, and that will still do exactly what they do now in ten years, because nothing about them depends on anybody staying in business.

Where a plugin is the right answer

I would be arguing in bad faith if I stopped there, because the honest position is not “never”.

Taking payments. Serious search. Multilingual publishing. Memberships and access control. Anything involving money, personal data at scale, or a specification that keeps changing underneath you — there you want software that a team maintains full time and that a great many people are testing against the real world. Writing your own payment handling to avoid a dependency is not independence, it is a liability with your name on it.

The question is not how many plugins you have. It is whether each one is doing work you genuinely could not do yourself, and whether you would know what to do on the day it is abandoned.

Which gives you the test, for the next time you are standing in front of that Install button:

Small, understandable, portable

What I am after is a site that can be rebuilt from a theme in version control, a database, a folder of images and a page of instructions — by somebody who is not me, years from now, without needing anybody’s permission or anybody’s licence key.

That is a quieter goal than it sounds, and it has one practical consequence worth stating: the less there is, the less there is to go wrong, and the more of what remains is yours.

Read the originals

The first one settles the argument with numbers. The second is where all of this started, and is three paragraphs long.

• State of WordPress Security — Patchstack, published yearly. Every disclosed vulnerability, counted and split between core, themes and plugins. Read one table and you will never argue about this again.
• Here’s the beef — the WordPress 1.2 “Mingus” release announcement, 22 May 2004, where the plugin architecture is introduced in a single sentence.
• Tim Nash, Advisory: Advanced Custom Fields changes — 2024. What administrators actually saw, written for administrators rather than for commentators.
• WordPress takes control of the ACF plugin — TechCrunch, 12 October 2024, for the background to the dispute.
• Plugin Handbook — WordPress developer documentation. Worth reading even if you never write one: it shows you precisely how much a plugin is allowed to do, which is the whole point above.