PHP, WordPress core, plugins, themes — who updates what? Splitting “the host’s job” from “the site owner’s job” on shared hosting
A follow-up to A critical flaw in PHP itself. How each hosting provider handles updates differs by provider and changes over time, so this article does not claim anything about any specific provider. It covers how to think about the split and how to check it against your own contract.
“Somebody is handling it” is the riskiest assumption
When security updates come up, two beliefs often coexist: “the hosting company surely patches that” and “updating my site is my job.” Each is half right.
A WordPress site runs on a stack of layers.
| Layer | Examples | Who usually updates it (general tendency) |
|---|---|---|
| Hardware, OS, web server | Linux, Apache / nginx | The host |
| PHP (the runtime) | 8.3 branch, etc. | Depends on the contract — sometimes the host, sometimes you choose |
| Database | MySQL / MariaDB | The host |
| WordPress core | Core | You (depending on auto-update settings) |
| Plugins | Various | You (depending on auto-update settings) |
| Themes | Various | You (depending on auto-update settings) |
The important point: only the PHP row says “depends on the contract.” That is where things stay vague, and when a PHP-level flaw like the last one appears, you can end up thinking the host raised the version when it was actually a setting you were meant to change.
Each layer is checked in a different place
PHP
Shared hosting commonly looks like one of these. Which one applies depends on provider and plan, so confirm it for your own contract.
- A control panel where you pick the PHP version per domain. Patch updates within the chosen branch are often applied by the host, but not always
- The host raises the version for everyone, announced in a notice
- Old branches that stay selectable after their support ends. Being selectable is not the same as being safe
Two starting points: the host’s announcements / status page (PHP updates and end-of-support dates are usually posted there), and the version shown in the control panel. The version actually serving your site is visible in WordPress under Tools → Site Health → Info → Server. php -v over SSH reports the command-line PHP, which can differ from the web one.
WordPress core
Minor releases (e.g. 6.8.1 → 6.8.2) are auto-updated in the background by default; major releases (6.8 → 6.9) are not. We covered this in what WordPress automatic background updates cover. What you should verify is whether anyone has changed that setting.
Plugins and themes
Not auto-updated by default; you decide per plugin. This is entirely the site owner’s job, not the host’s. An update notice that nobody acts on does nothing.
You can list pending updates with WP-CLI:
wp plugin list --update=available
wp theme list --update=available
wp core check-update
Even where the host does the work, checking is yours
- Make sure you can receive the host’s notices: outdated contact addresses and spam-filtered mail are common
- Track announced deadlines: when an old PHP branch stops being available, put the date on a calendar
- Verify the site after the change: if a host raises PHP, an old plugin may stop working — that consequence lands on your site
Even when the host does the work, checking what happened to your site is the owner’s job.
If you manage several sites, keep a table
Contracts, servers and PHP versions drift across sites. As the last article noted, working out what’s affected after an advisory arrives costs time. Prepare a table during calm periods.
| Site | Server (contract) | PHP version / checked on | PHP updated by | Where host notices go |
|---|---|---|---|---|
| example-a | Host X | 8.3.36 (Oct 29) | You choose | Admin mailbox |
| example-b | Host Y | 8.2.35 (Oct 29) | Host, for everyone | Shared address |
The last two columns — who updates and where notices go — are the ones that tend to stay blank, and they make the difference in the first hour of an incident.
The shared-responsibility idea
Cloud providers talk about a “shared responsibility model”: the provider secures the foundation, and the customer configures and operates what runs on it. Shared hosting follows the same shape, and where the line sits differs slightly per contract.
If you don’t know where the line is, a layer can fall into the gap between “the host must be doing it” and “I must be doing it.” Part of maintenance is confirming the line, writing it down, and revisiting it regularly.
Summary
- The updater differs by layer. PHP depends on the contract, so check it specifically
- WordPress core depends on settings; plugins and themes are mostly the owner’s job
- Even for the host’s layers, receiving notices and verifying the site afterwards are yours
- For several sites, keep a table that includes “who updates” and “where notices go”
Check once, today, who updates PHP under your own contract. That one answer changes how fast you can move in the next emergency.