WordPress Plugin Requires Newer PHP: What to Do When Hosting Is Outdated

You click “Update” on a plugin and your site rewards you with a white screen, a fatal error, or the classic “This plugin requires PHP 8.1, you’re on 7.4.” The plugin author isn’t being dramatic; they’re doing basic hygiene. Your hosting, however, is living in the past like it has a flip phone and strong opinions about CDs.

This is one of those problems that feels like “WordPress stuff” but is actually systems engineering: runtime compatibility, patching cadence, blast radius, rollback, and what you do when you don’t control the environment. Let’s treat it like production, not like a hobby site.

Fast diagnosis playbook

If you’re on the clock and the site is down (or you’re one click away from it), don’t “poke around.” Do this in order. This finds the bottleneck quickly and avoids self-inflicted downtime.

1) Confirm what PHP is actually running (not what the control panel claims)

• Check in WordPress Admin: Tools → Site Health → Info → Server.
• Or run a CLI check on the host. See the commands section below.

Decision: If PHP is below the plugin’s minimum, stop and plan an upgrade path. Do not force-install the plugin “anyway.” That’s how you learn about fatal errors.

2) Identify where PHP is coming from (Apache mod_php vs PHP-FPM vs handler)

• Shared hosting: often a per-site “PHP selector,” but sometimes it’s a global default.
• VPS: you might have multiple PHP-FPM pools, each on different versions.

Decision: If you can run multiple versions side-by-side, you can upgrade WordPress first without breaking other apps on the box.

3) Determine blast radius: is this a single site or a fleet?

• How many vhosts point to the same PHP runtime?
• Are other sites legacy and pinned to PHP 7.4?

Decision: Fleet-wide upgrades need staging and phased rollout. Single-site upgrades can be faster—but still need rollback.

4) Capture the real error (logs, not vibes)

• WordPress debug log for PHP errors.
• Web server and PHP-FPM logs for startup/config issues.

Decision: If the error is “requires PHP X,” upgrade is mandatory. If the error is “undefined function” or “typed property,” it still usually means version mismatch.

5) Choose the least risky fix that meets the requirement

• Best: upgrade PHP (supported version) with staging and rollback.
• Second-best: isolate the site in a container or separate VM.
• Last resort: pin an old plugin version (short-term), and schedule migration.

What the error really means (and what it doesn’t)

When a plugin says it requires PHP 8.1+ (or 8.0+, etc.), it’s rarely “because the author hates you.” It’s usually one of these:

• Language features: the plugin uses syntax not available in older PHP (union types, attributes, match expressions, enums, readonly properties).
• Core functions and extensions: it depends on newer functions or on modern versions of extensions like cURL, OpenSSL, JSON, mbstring, or intl.
• Security posture: they don’t want to support end-of-life PHP versions with known vulnerabilities.
• Testing matrix reality: maintaining compatibility back to PHP 7.4 (or older) multiplies testing cost. They cut the tail.

What it doesn’t mean: that upgrading PHP will automatically break WordPress. WordPress itself is conservative, but the ecosystem is not. Compatibility breaks usually come from:

• Ancient themes/plugins that relied on deprecated behavior.
• Hard-coded assumptions about string/array conversions.
• Old libraries bundled inside plugins (vendor folders) that collide with modern PHP expectations.

And yes, you can sometimes “make it work” on old PHP by editing a plugin. That’s also how you become the new maintainer of a plugin you didn’t want to maintain. Congratulations, you’ve adopted a small digital pet that bites.

Interesting facts and a little history (so the mess makes sense)

Understanding why you’re stuck on old PHP helps you decide whether to fight your host or leave it.

1. PHP 7.0 (2015) was a huge performance leap compared to PHP 5.x, which is why a lot of hosts “finally upgraded” and then got comfortable again.
2. WordPress historically supported very old PHP to keep the web’s long tail running. That’s noble, but it shifts pressure to plugin authors.
3. PHP 8.0 (2020) introduced JIT (just-in-time compilation). JIT rarely transforms typical WordPress workloads, but it signals that PHP is not “stagnant.”
4. Typed properties and stricter type behavior in PHP 7.4/8.x flushed out sloppy code. Many “it worked for years” plugins died on contact with modern PHP.
5. Some shared hosts pin PHP versions because one outdated control panel module, billing integration, or custom Apache handler depends on it. That’s a business choice, not a technical law.
6. WordPress’s auto-updates changed expectations: core and plugins can move fast now, so runtime lag hurts more than it did a decade ago.
7. Composer (PHP dependency manager) went mainstream, and many plugins now depend on modern libraries that explicitly drop old PHP versions.
8. CloudLinux + CageFS became common on shared hosting to isolate users, and it often ships with “PHP Selector” that can run multiple versions. If your host doesn’t have this, it’s a clue about their maturity.
9. PCI and security audits increasingly flag EOL runtimes regardless of whether you personally “feel fine.” Compliance doesn’t care about vibes.

Decision tree: upgrade, isolate, or migrate

Here’s the blunt truth: if your hosting can’t run supported PHP versions, you’re paying for a time machine. Sometimes that’s okay for an archive site. It’s not okay for anything that takes payments, stores personal data, or needs plugin updates.

Option A (preferred): Upgrade PHP where it is

Do this when:

• You control the server (VPS/dedicated/cloud).
• Your shared host offers a per-site PHP version selector.
• You can stage and roll back.

A good upgrade is boring. Boring is the goal.

Option B: Isolate the site (container/VM) without changing the host

Do this when:

• Your host is outdated but you can’t move immediately (contracts, bureaucracy, or “the person with credentials is on vacation”).
• You can put the site behind a reverse proxy and run modern PHP elsewhere.

It’s extra moving parts, but it can buy time safely.

Option C: Migrate to a host that isn’t stuck in 2019

Do this when:

• The host can’t provide PHP 8.1/8.2/8.3 today.
• You can’t run multiple versions.
• Support tells you to “just use an older plugin version.”

If the platform can’t patch, it can’t be trusted for production. That’s not harsh; that’s operating reality.

Short joke #1: Running end-of-life PHP in production is like storing backups on the same disk—technically it exists, spiritually it doesn’t.

Practical tasks with commands (and how to decide from the output)

Below are concrete tasks you can run on a VPS or any host where you have shell access. Each task includes: command, sample output, what it means, and what decision you make next. If you’re on shared hosting without SSH, you’ll do the equivalent via a control panel or support ticket, but the logic is identical.

Task 1: Check the PHP version used by CLI (baseline sanity)

cr0x@server:~$ php -v
PHP 7.4.33 (cli) (built: Nov 16 2023 12:01:17) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

What it means: Your CLI default is PHP 7.4. This may or may not match what the web server uses.

Decision: If the plugin requires 8.1+, you need a newer PHP installed and configured for the web stack, not just CLI.

Task 2: Check what PHP version the web server is serving (the one that matters)

cr0x@server:~$ curl -sI https://example.com | grep -i x-powered-by
X-Powered-By: PHP/7.4.33

What it means: The HTTP response advertises PHP 7.4. Some sites hide this header, but if it’s present it’s a strong hint.

Decision: If this is old, proceed to identify handler (FPM vs mod_php) and upgrade path.

Task 3: If you have WP-CLI, ask WordPress what it sees

cr0x@server:~$ cd /var/www/example.com/public
cr0x@server:/var/www/example.com/public$ wp --info
OS:     Linux 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64
Shell:  /bin/bash
PHP binary:     /usr/bin/php7.4
PHP version:    7.4.33
wp-cli version: 2.10.0

What it means: WP-CLI is running under PHP 7.4. That’s useful for troubleshooting, but again: web PHP might differ.

Decision: Treat this as confirmation that your system is old. Now check the web server’s PHP handler.

Task 4: Find whether Apache is using mod_php (common legacy trap)

cr0x@server:~$ apache2ctl -M | grep -E 'php|proxy_fcgi'
 php7_module (shared)

What it means: Apache has mod_php loaded (here as php7_module). That usually ties Apache to a single PHP version.

Decision: Consider migrating to PHP-FPM. It’s the clean way to run multiple versions and reduce coupling.

Task 5: Check PHP-FPM services installed (multi-version readiness)

cr0x@server:~$ systemctl list-units --type=service | grep php | grep fpm
php7.4-fpm.service loaded active running The PHP 7.4 FastCGI Process Manager
php8.2-fpm.service loaded active running The PHP 8.2 FastCGI Process Manager

What it means: You already have PHP 8.2 FPM installed and running. Great—now you just need to point the site at it.

Decision: Prefer switching the vhost to php8.2-fpm for this site. Keep 7.4 temporarily for other sites until migrated.

Task 6: Inspect which FPM socket the site uses (real source of truth)

cr0x@server:~$ grep -R "proxy:unix" -n /etc/apache2/sites-enabled/example.com.conf
42:    SetHandler "proxy:unix:/run/php/php7.4-fpm.sock|fcgi://localhost/"

What it means: This site is pinned to PHP 7.4 FPM.

Decision: Change it to the 8.2 socket (or 8.1/8.3 as required), reload Apache, and test.

Task 7: Verify installed PHP versions and modules (plugins care about extensions)

cr0x@server:~$ php8.2 -m | egrep 'curl|mbstring|intl|openssl|imagick'
curl
intl
mbstring
openssl

What it means: These extensions are available for PHP 8.2. If a plugin needs imagick and it’s missing, you’ll still break after the version upgrade.

Decision: Install missing extensions before switching production traffic, or switch and accept functional degradation until fixed (usually not acceptable for media-heavy sites).

Task 8: Check for end-of-life PHP packages lingering on Debian/Ubuntu

cr0x@server:~$ apt-cache policy php
php:
  Installed: 2:8.2+93
  Candidate: 2:8.2+93
  Version table:
 *** 2:8.2+93 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

What it means: The meta package is aligned with PHP 8.2. That’s good, but doesn’t guarantee your vhost uses it.

Decision: Confirm the FPM pool and web server config. Package state is necessary, not sufficient.

Task 9: Switch an Apache site from PHP 7.4 FPM to PHP 8.2 FPM (surgical change)

cr0x@server:~$ sudo sed -i 's#/run/php/php7.4-fpm.sock#/run/php/php8.2-fpm.sock#g' /etc/apache2/sites-available/example.com.conf
cr0x@server:~$ sudo apache2ctl configtest
Syntax OK
cr0x@server:~$ sudo systemctl reload apache2

What it means: The config is syntactically valid and Apache reloaded without error.

Decision: Immediately run a health check: front page load, wp-admin access, and a PHP info probe (see next tasks). If anything fails, revert quickly.

Task 10: Confirm the site is now served by the new PHP version

cr0x@server:~$ curl -sI https://example.com | grep -i x-powered-by
X-Powered-By: PHP/8.2.15

What it means: Requests now run on PHP 8.2.

Decision: Proceed to functional checks: login, checkout (if ecommerce), cron, and plugin update.

Task 11: Turn on WordPress debugging safely (log, don’t display)

cr0x@server:~$ sudo -u www-data bash -lc "grep -n \"WP_DEBUG\" -n /var/www/example.com/public/wp-config.php | head"
87:// define('WP_DEBUG', false);

What it means: Debug is not explicitly set (or is commented). You can enable logging without exposing errors to visitors.

Decision: Enable WP_DEBUG_LOG and keep WP_DEBUG_DISPLAY off. Then reproduce the failure and read logs.

Task 12: Watch PHP-FPM and web logs during a test request (best signal)

cr0x@server:~$ sudo tail -f /var/log/php8.2-fpm.log /var/log/apache2/error.log
[27-Dec-2025 10:11:07] NOTICE: ready to handle connections
[Sat Dec 27 10:11:14.282910 2025] [proxy_fcgi:error] [pid 21234] [client 203.0.113.10:53122] AH01071: Got error 'PHP message: PHP Fatal error:  Uncaught Error: Call to undefined function mysql_connect() in /var/www/example.com/public/wp-content/plugins/legacy-db/legacy.php:41'

What it means: A legacy plugin uses mysql_connect(), removed long ago. This is not a “PHP 8 bug.” It’s a plugin that should’ve been retired.

Decision: Disable or replace the plugin. If it’s critical, you may need to keep this site on older PHP temporarily—then schedule remediation or migration. Do not keep payments on this setup.

Task 13: Disable a broken plugin without wp-admin (safest emergency lever)

cr0x@server:~$ cd /var/www/example.com/public/wp-content
cr0x@server:/var/www/example.com/public/wp-content$ sudo mv plugins/legacy-db plugins/legacy-db.disabled

What it means: WordPress will stop loading that plugin because it’s no longer in the expected directory.

Decision: If the site recovers, you’ve confirmed root cause. Replace the plugin or refactor functionality. If the site doesn’t recover, keep checking logs; multiple failures can stack.

Task 14: Check database connectivity and version quickly (some hosts break this during migrations)

cr0x@server:~$ mysql --version
mysql  Ver 8.0.36 for Linux on x86_64 (MySQL Community Server - GPL)

What it means: You’re on MySQL 8.0, which is generally fine. If you were on very old MySQL, some plugins might also complain.

Decision: If PHP is upgraded but errors persist, confirm database driver extensions (mysqli, pdo_mysql) and credentials.

Task 15: Validate WordPress cron behavior after PHP change (silent failure mode)

cr0x@server:~$ cd /var/www/example.com/public
cr0x@server:/var/www/example.com/public$ wp cron event list --fields=hook,next_run --allow-root | head
action_scheduler_run_queue  2025-12-27 10:15:00
wp_version_check            2025-12-27 12:00:00
wp_update_plugins           2025-12-27 12:00:00

What it means: Cron events exist. That doesn’t prove execution, but it’s the first check.

Decision: If scheduled tasks stop running after an upgrade (common when switching to a different PHP binary), configure a real system cron calling the right PHP/WP-CLI, or fix the web cron endpoint access.

Task 16: Snapshot before major changes (filesystem snapshot on modern storage)

cr0x@server:~$ sudo zfs snapshot tank/www@example.com@pre-php82
cr0x@server:~$ sudo zfs list -t snapshot | grep pre-php82
tank/www@example.com@pre-php82  0B  -  240G  -

What it means: You have an instantaneous snapshot. Rollback is now a command, not a prayer.

Decision: Proceed with the upgrade. If it goes sideways, you can revert fast. If you don’t have snapshots, emulate them with backups and a staging clone.

Short joke #2: If you upgrade PHP on Friday afternoon, the weekend will also be upgraded—into a work weekend.

Upgrade paths by hosting type

Shared hosting (cPanel, Plesk, “custom panel”)

This is the most common “plugin requires newer PHP” battlefield. You often have limited control, but not zero control.

• Look for a PHP selector per domain. If you can choose PHP 8.1/8.2 per site, your problem is solved in 10 minutes. Do it in staging first if the host provides it.
• If the newest available is still old, escalate. Ask support what their timeline is for PHP 8.2/8.3, and whether they can enable it for your account. Their answer tells you whether to migrate.
• Beware “we have PHP 8.x” claims that are CLI-only. Some hosts provide multiple CLIs but lock the web handler to one version.

Opinionated advice: if your host can’t offer a supported PHP version today, start planning a move. Don’t debate it for months while ignoring security updates.

Managed WordPress hosting

Managed platforms typically do staged rollouts and provide a PHP version switcher. Your job is to:

• Use their staging environment, not production, for the first switch.
• Confirm they keep old PHP versions only temporarily; you don’t want a platform that treats runtime EOL as optional.
• Check whether they also control object caching, page caching, and WAF rules—those can change behavior when PHP is upgraded.

VPS / dedicated server (you own the mess, but also the fix)

Good news: you can solve this properly. Bad news: you can solve this improperly, too, and you’ll be the one paged.

• Prefer PHP-FPM over mod_php. It decouples the web server and allows per-site pools.
• Install multiple versions if you host multiple sites, then migrate site-by-site.
• Pin configuration changes to a single vhost first. Don’t “apt upgrade everything” and hope.

Containerized / Kubernetes setups

If you already deploy WordPress in containers, the runtime is just an image tag. That sounds easy—and is—until persistent storage and plugin update workflows get involved.

• Build or pull an image with the required PHP version.
• Roll out to staging with the same database dump and uploads snapshot.
• Ensure your persistent volume supports atomic snapshots (or consistent backups). Otherwise, rollback is messy.

Three corporate-world mini-stories

Mini-story #1: The incident caused by a wrong assumption

A mid-sized company had a WordPress site that looked simple from the outside: a marketing site with a blog, a few landing pages, and a form integration. It was hosted on a VPS that “nobody touched,” which is corporate shorthand for “nobody owns it.”

A developer updated a forms plugin to fix a security advisory. The plugin started requiring PHP 8.1. The server was on PHP 7.4. The assumption was: “The host OS is updated, so PHP must be updated.” The OS was updated. PHP wasn’t. Apache was still tied to the old FPM socket, and the new packages were installed but unused.

The site went into a fatal error loop, but only on certain pages—specifically the ones that loaded the plugin’s new code path. That delayed diagnosis because the homepage still worked and everyone argued about “it’s intermittent.”

The SRE on call did the one thing that saved time: stopped debating and tailed the logs while reproducing the request. The error message was embarrassingly explicit: the plugin refused to run on PHP 7.4.

The fix was not heroic: switch the vhost to PHP 8.2 FPM, disable one ancient plugin that used removed mysql functions, then re-enable features one by one. The postmortem was about ownership: runtime version is a dependency, and dependencies need an owner. “Nobody touched it” is not a strategy.

Mini-story #2: The optimization that backfired

A different organization wanted fewer moving parts. They had Apache with mod_php because “it’s faster” and “we don’t need extra daemons.” Someone read an old benchmark and decided PHP-FPM was needless complexity. They also consolidated several WordPress sites onto one box to save costs.

Then one site needed a modern WooCommerce extension that required PHP 8.2. Another site had a legacy theme that broke on PHP 8.x due to strict typing warnings turned into exceptions by custom error handling.

With mod_php, they had exactly one PHP version for everyone. Their “optimization” removed the ability to migrate incrementally. They were forced into a big-bang upgrade: flip PHP for all sites at once or keep everything old. They chose flip.

Half the sites broke in subtle ways: contact forms stopped sending, image processing failed because the Imagick extension wasn’t compiled for the new PHP, and scheduled jobs silently died. Support tickets piled up, and the team spent a week doing emergency triage instead of planned migration.

They eventually moved to PHP-FPM, per-site pools, and a basic canary rollout. The lesson wasn’t “never optimize.” It was “don’t optimize away isolation.” In production, isolation is performance. It’s performance of humans under pressure.

Mini-story #3: The boring but correct practice that saved the day

A regulated business ran WordPress for a documentation portal. Not glamorous, but it was customer-facing and audited. Their infra team had a boring policy: every change goes through staging, and staging mirrors production as closely as possible. Same PHP version, same web server config, same caching rules. They also took snapshots of the filesystem and database before runtime changes.

When a plugin update started requiring PHP 8.1, they didn’t panic. They cloned production to staging from last night’s snapshot, switched staging to PHP 8.2, and ran a scripted test plan: login, search, page render, file upload, and plugin-specific workflows.

They found one issue: a custom mu-plugin used deprecated functions that were now warnings. In production, warnings were promoted to errors by a strict error handler. That would have caused a hard outage if discovered live.

They fixed the mu-plugin, reran the tests, and scheduled the production switch. During the actual cutover, they watched logs and metrics, and had a rollback plan that involved reverting to snapshots and switching FPM sockets back. They never used the rollback, which is the point.

What saved them wasn’t genius. It was boredom: a repeatable workflow, snapshots, and refusing to treat production like a sandbox. If you want fewer incidents, you need more boring.

Common mistakes: symptom → root cause → fix

This is where most teams waste time. The symptoms look like WordPress drama, but the root causes are nearly always predictable.

1) Symptom: “Plugin requires PHP 8.1” message in wp-admin

• Root cause: The site runtime is older than the plugin’s minimum version.
• Fix: Upgrade the PHP runtime used by the web server. Confirm by checking headers/logs. Don’t just update CLI PHP.

2) Symptom: White screen or “There has been a critical error” after plugin update

• Root cause: Fatal error due to incompatible PHP version or missing extension.
• Fix: Check web and PHP-FPM logs. Disable the plugin by renaming its directory, then upgrade PHP or install the missing extension.

3) Symptom: Site works for visitors but wp-admin is broken (or vice versa)

• Root cause: Different code paths, different plugin loading, or caching hiding failures.
• Fix: Bypass cache and reproduce while tailing logs. Test both front end and admin after changing PHP.

4) Symptom: After upgrading PHP, media uploads fail or thumbnails stop generating

• Root cause: Missing image libraries (GD/Imagick) for the new PHP version, or file permissions issues in uploads.
• Fix: Install the extension for the new PHP and restart FPM. Verify with php -m under the correct version.

5) Symptom: Random 502/504 errors after switching to PHP-FPM

• Root cause: FPM pool misconfiguration, socket permissions, too-low pm.max_children, or timeouts.
• Fix: Check error logs for “connect() to unix socket failed” vs “upstream timed out.” Fix permissions or tune pool limits based on actual traffic.

6) Symptom: “Call to undefined function” after upgrade

• Root cause: Plugin/theme using removed/deprecated functions; or the required PHP extension isn’t enabled.
• Fix: Identify the function: if it’s an extension function, install/enable the extension. If it’s removed core behavior, replace the plugin/theme.

7) Symptom: wp-cron stops, scheduled posts don’t publish, ecommerce jobs stall

• Root cause: Cron relies on web requests; after changes, loopback requests fail, or server-level cron calls wrong PHP binary.
• Fix: Configure a system cron calling WP-CLI with the correct PHP version; check loopback connectivity and firewall rules.

8) Symptom: You upgraded PHP but the plugin still claims it’s old

• Root cause: You upgraded one PHP (CLI) but the web handler still points to the old one; or multiple PHP runtimes exist and the site is pinned.
• Fix: Locate the handler (FPM socket, Apache module, Nginx fastcgi_pass) and switch it. Confirm with headers and phpinfo.

Checklists / step-by-step plan

This is the plan I’d run as an SRE supporting WordPress: minimal drama, maximum reversibility.

Checklist A: Before you touch production

1. Read the plugin requirement. Minimum PHP version, required extensions, and any notes about WordPress version.
2. Inventory your runtime. What PHP version is web using? What’s CLI using? Are they different?
3. List critical flows. Login, checkout, contact forms, media upload, admin edit, cache purge, cron tasks.
4. Make rollback real. Snapshot filesystem + database, or at least a backup you’ve tested restoring.
5. Build a staging clone. Same PHP handler style, same caching layer, same config approach.

Checklist B: Staging upgrade flow (recommended even for “small” sites)

1. Clone production to staging (files + DB).
2. Switch staging to the target PHP version (8.1/8.2/8.3).
3. Install required PHP extensions on staging.
4. Run the plugin update in staging first.
5. Exercise the critical flows and tail logs.
6. Fix or replace any incompatible plugin/theme.
7. Write down the exact changes made (config diffs, packages installed).

Checklist C: Production cutover with minimal downtime

1. Choose a quiet window. Even “no-downtime” changes have risk, and risk is lower when traffic is lower.
2. Apply the same runtime changes as staging. Don’t improvise.
3. Reload, don’t restart, where possible. Reloading web server config reduces disruption.
4. Run health checks immediately. Front page, wp-admin, and one plugin-specific workflow.
5. Watch logs for 15–30 minutes. Many failures appear only after background jobs run.
6. Only then update the plugin in production (if you didn’t already and if policy allows).

Checklist D: If you cannot upgrade PHP on the host

1. Stop the plugin update. Keep the current version running if it’s not vulnerable.
2. Evaluate risk: if the plugin update was for a security fix, assume you’re now on the clock.
3. Pick a containment strategy:
   • Move the site to a new host that supports modern PHP.
   • Stand up a new VPS and migrate DNS.
   • Put a reverse proxy in front and run WordPress elsewhere.
4. Make the migration boring. Files, database, configs, and a cutover plan with rollback (DNS TTL, snapshot, maintenance mode).

How to think about safety: compatibility, security, and rollback

The worst mindset is “upgrading PHP is scary.” The second-worst is “upgrading PHP is nothing.” Treat it like any runtime upgrade: it changes behavior, error handling, performance characteristics, and occasionally library availability.

Here’s the operational framing that works:

• Compatibility risk is mainly about old plugins/themes. Inventory and retire them. If something hasn’t been updated in years, it’s not “stable,” it’s abandoned.
• Security risk increases over time. An old PHP version isn’t just slower or uglier; it’s a liability. Hosts sometimes “backport patches,” but you should demand clarity: what’s patched, and how quickly?
• Rollback must be mechanical. If rollback is “we’ll try to undo it,” that’s not rollback. That’s improvisation.

Paraphrased idea from Werner Vogels (Amazon CTO): you build reliable systems by expecting failure and designing for recovery, not by hoping nothing breaks.

What to avoid (strong opinions, earned the hard way)

• Don’t edit vendor/plugin code to “make it compatible.” You will forget, auto-updates will overwrite it, and the next incident will be your fault.
• Don’t run production changes without logs. If you can’t see PHP-FPM and web server errors, you’re debugging blindfolded.
• Don’t keep ecommerce on an EOL runtime. If money changes hands, patch cadence is part of the product.
• Don’t assume “the host will handle it.” Some will. Many won’t. Verify.
• Don’t conflate “WordPress supports it” with “plugins support it.” Your real platform is the ecosystem you installed.

FAQ

1) Can I just install an older version of the plugin?

You can, sometimes. It’s a short-term workaround, not a fix. If the plugin dropped old PHP because of security or dependency updates, pinning old versions can leave you exposed. Use this only to buy time while you upgrade PHP or migrate.

2) If I upgrade PHP, will WordPress core break?

Modern WordPress generally runs fine on PHP 8.1/8.2/8.3. Breakage usually comes from old themes/plugins or custom code. That’s why staging matters: it tells you which dependency is the problem before users do.

3) My host says they “support PHP 8,” but the plugin still complains. Why?

Because “support” may mean “available for some accounts,” “available for CLI,” or “available if you switch a per-site selector.” Confirm the runtime used by the web server, not just what’s installed.

4) What PHP version should I target right now?

Target a currently supported PHP version offered by your distro/host—typically PHP 8.2 or 8.3. If the plugin requires 8.1, don’t stop at 8.1 unless you have a reason; you’ll just repeat the exercise sooner.

5) How do I upgrade PHP without downtime?

Run multiple PHP-FPM versions, switch the site’s upstream socket, and reload the web server. That’s usually a near-instant change. The real downtime risk comes from application incompatibility, which staging and snapshots mitigate.

6) What if another site on the same server needs old PHP?

Then you want PHP-FPM with multiple pools/versions and per-vhost configuration. If you’re stuck on mod_php, you’ve boxed yourself in. Migrate legacy sites or isolate them onto a separate VM/container.

7) Is upgrading PHP enough, or do I need to upgrade MySQL/MariaDB too?

Usually PHP is the blocker for the plugin error. But while you’re here, check database versions and extensions. Some modern plugins assume newer MySQL/MariaDB behavior, especially around character sets and strict SQL modes.

8) The site works after PHP upgrade, but performance got worse. What happened?

Common causes: OPcache not enabled/configured for the new PHP, FPM pool limits too low, or caching layers behaving differently. Confirm OPcache status and tune FPM rather than blaming the PHP version blindly.

9) I have no SSH access. What can I do?

Use your hosting control panel to switch PHP versions if available, and use WordPress Site Health to confirm the change. If the host can’t offer a modern PHP runtime, migrate. Lack of SSH isn’t fatal; lack of supported runtimes is.

Next steps you can take today

Here’s a practical sequence that works in the real world:

1. Confirm the actual PHP version used by the web server. Don’t trust the marketing dashboard; trust headers and logs.
2. Pick the cleanest path: upgrade in place if you can, isolate if you must, migrate if you should.
3. Stage it. Clone, switch PHP, update the plugin, test the money paths and admin flows.
4. Make rollback mechanical. Snapshots or tested backups. Not “we’ll remember what we changed.”
5. Cut over and watch. Logs, cron, and error rates for at least 15–30 minutes.
6. Then clean up. Remove abandoned plugins, document the PHP handler, and schedule periodic runtime reviews so this doesn’t ambush you again.

If your host can’t provide supported PHP versions, don’t negotiate with physics. Move. Production systems don’t get better with wishful thinking; they get better with ownership and repeatable change.