A WordPress request is four layers deep and each one can override the one
below. Measured on a live install on 2026-09-02: 711 hooks are registered before
a page is built, the_content alone carries fourteen callbacks, and
195 REST routes answer. None of that is configuration; it is what an install
does out of the box.
Which is the shape of the whole platform. Core provides the request, the
database access and the hook system; a theme decides what a page looks like; a
plugin changes behaviour by attaching to hooks; and the content in the database
is the only part the site owner touches. Every question about WordPress is a
question about which of those four a thing belongs in.
The layer rule, and what it prevents
- Presentation belongs in the theme, so the site keeps working if the theme is
swapped. A custom post type registered in a theme disappears with it, and the
content becomes unreachable - Behaviour belongs in a plugin, including post types, taxonomies and
shortcodes, because those are data rather than design - Never edit core, and never edit a parent theme. Both are replaced by
updates, silently and completely - Configuration that differs per environment belongs in
wp-config.php, which is the one file that is not shared between
installs
The first two together are the most useful rule in WordPress and the most
often broken, usually by a theme that registers a portfolio post type. The test
is one question: if the theme were switched tomorrow, should this disappear.
What it is good at, and what it is not
WordPress is unusually good at a site where non technical people publish
regularly, need a real editing interface, and want to change things without a
deployment. The admin, the media library, the revisions and the roles are years
of work you do not do.
It is a poor fit where the content is highly structured and queried in
complex ways, because everything not a post is a meta row and filtering across
several of them is a join per field. It is also a poor fit where the front end
is an application rather than pages, in which case the content model is still
useful and the rendering is not, which is
WordPress as a
backend for something else.
What to run in 2026
WP-CLI is the tool, free and open source, and it changes what maintaining a
site costs: wp plugin update --all, wp search-replace
for a domain change, wp db export, and wp eval to ask
the running install a question directly. It replaced clicking through the admin,
which cannot be scripted and cannot be reviewed.
Query Monitor is the second, free, and it belongs on every development
install. It answers which template rendered, which queries ran and which
callbacks fired, which are the three questions this page's layers raise. It
replaced reading the source to work out what happened.
Where this stalls people
The stall is a site that works and cannot be changed. Custom post types in
the theme, business rules in template files, a hundred plugins with overlapping
jobs, and a database full of settings nobody can trace to a screen. Nothing is
broken and every change is a risk, which is the state most inherited WordPress
sites are in.
The way out is boring and it works: put a functionality plugin of your own
next to the theme, move post types and rules into it, and delete a plugin a
month. Nothing about that requires a rebuild. What each layer contains in detail
is the template
hierarchy, and building one and
hooks, filters and
writing your own, the attacks that arrive at all of it are
the attacks it
actually gets, and the fixes, and the shop built on top is
products, checkout and
the hooks around them. The alternatives are
sites where someone else edits the words.