PHP 8.1 has been released, and I am treating it the same way I treated PHP 8.0 last year: interesting, useful, but not something to switch on blindly for every WordPress site.
That is not because I am cautious for the sake of it. WordPress websites are rarely just WordPress core. They are themes, plugins, custom fields, payment integrations, form handlers, cron jobs and hosting-specific details. A PHP version change touches all of that. If something relies on deprecated behaviour or makes assumptions that newer PHP versions no longer accept, the problem may only appear in a specific part of the site.
I wanted a repeatable testing process before production was touched. The update may be a server-level change, but the risk shows up in the website experience. That means the test needs to follow how the site is actually used.
Starting In A Local Or Staging Environment
The first rule for me is simple. Do not start on production. I want a local or staging copy where errors can appear without affecting visitors or editors. That environment should be close enough to production that the test means something, especially around PHP extensions, caching and plugin versions.
Once the environment is ready, I update PHP and turn on the kind of error logging that gives useful information without exposing errors on the front end. White screens and obvious failures are easy to spot. Warnings and deprecations need logs, because they may not break the page immediately but can still point to future problems.
{
"config": {
"platform": {
"php": "8.1.0"
}
}
}For projects using Composer, setting the platform version can help catch dependency issues earlier. It is not the whole test, but it gives the dependency layer a chance to complain before the website is even loaded in the browser.
Testing The Parts People Actually Use
After the technical checks, I move through the site like an editor and a visitor. I log in, edit content, submit forms, check search, test checkout if the site has one and review any custom functionality. The goal is not to click randomly. The goal is to test the routes that matter to the business.
Plugins need particular attention. A plugin can appear fine until a specific settings page, shortcode or scheduled task runs. That is why I check logs after using the site rather than only checking before. The errors often appear after a feature is used, not when the dashboard first loads.
Custom theme code also deserves a review. Older PHP habits can sit inside templates for years without causing visible issues. A version change is a good moment to clean those up, but I would rather do that deliberately than discover them through a broken page after the host changes PHP globally.
Deciding When To Move
If the test environment behaves properly, I still plan the production change carefully. I want a backup, a rollback route and a quiet time to make the switch. That may sound excessive for a version change, but it is much easier to be boring before the change than urgent after it.
I also make notes about what was tested. Six months later, nobody wants to rely on memory when another update is needed. A short record of the PHP version, plugins checked and issues fixed makes future maintenance much easier.
What I Took From It
PHP 8.1 is a good reminder that infrastructure changes are still website changes. The visitor does not care whether a problem came from a plugin, a template or the server. They only see the site failing to do what it should.
My approach is to treat the version change as a controlled project, even if it is a small one. Test away from production, use logs, follow real user journeys and keep a record of what changed. That gives the site the benefit of newer PHP without turning the update into a gamble.