WordPress and PHP 8 — A Safe Upgrade Step by Step [2026]

Upgrading PHP on a WordPress site is one of the safest and most profitable changes you can make — newer PHP is faster, more secure and required by more and more plugins. The risk is not in WordPress itself, which has supported PHP 8.x since version 6.x, but in the plugins, the theme and custom modifications. This guide shows how to run the upgrade without a white screen, how to prepare a backup, what to check before the switch and what to do when something goes wrong.

Key takeaway: A safe PHP upgrade on WordPress has five steps: backup with a restore test → update WordPress, plugins and theme on the current PHP → a test environment on the target version → critical-path verification → production with monitoring. Never raise PHP with outdated plugins — it is the most common cause of failure.

Why upgrading PHP on a WordPress site pays off

Three arguments that convince even the most cautious.

Security. WordPress is the most attacked CMS in the world — not because it is leaky, but because it is popular. Vulnerabilities in WordPress itself get patched quickly, but they require a supported PHP version. On a version past EOL (e.g. 7.4) new interpreter vulnerabilities stay unpatched — and those are the most dangerous, because they work "below" the CMS.

Performance. PHP 8.x is significantly faster than 7.x — engine optimizations and JIT can cut page generation time by tens of percent with no code changes. For a site with traffic that means real differences in Core Web Vitals and conversion.

Compatibility. More and more plugins raise their minimum PHP version — some already require 8.0+ and stop receiving updates on older versions. Staying on 7.4, you lose not only new features but also plugin security fixes.

Before you start — a backup with a restore test

Every PHP upgrade starts with a backup that actually works. A backup "somewhere on the server" that nobody has ever restored is not a backup.

Protect three layers

• files — the entire WordPress directory (or at least wp-content: plugins, themes, uploads),

• database — a full dump via wp db export, phpMyAdmin or your host's tool,

• configuration — wp-config.php and .htaccess files.

• The restore test: restore the backup on a test environment and confirm the site opens and login and forms work. It takes 15 minutes and saves the day when something goes wrong — and with a PHP upgrade, "something" can go wrong.

Tip: If you have no test environment, build one on a subdomain (e.g. test.yourdomain.com) with a noindex block and a database copy. Most hosts let you set a different PHP version per directory — that is all you need to test the new version without risking production.

Step 1 — update WordPress, plugins and theme (on the current PHP)

Before changing the PHP version, bring the environment up to date — but on the current PHP version, where everything works.

1. Make a backup (as above) — the starting point.
2. Update WordPress core to the latest version.
3. Update all plugins and the theme — including the ones that "have worked for years". A plugin unmaintained for two years is the prime candidate for trouble on new PHP.
4. Remove unused plugins — less code, less risk; an inactive plugin can still be an attack vector.
5. Check plugin compatibility — WordPress shows the required and recommended PHP version under Tools → Site Health → Info. Plugins declare support in their repository listing ("Tested up to" and "Requires PHP").

Only once everything is up to date and the site runs stably on the current PHP — move on to testing the new version.

Step 2 — a test environment on the target PHP

On the test environment (subdomain or local copy) switch PHP to the target version — 8.3 or 8.4. If the host does not allow per-directory versions, temporarily switch the whole domain at night or over a low-traffic weekend — but always after a backup.

Walk this verification list on the test environment.

• Home page, pages, posts, archives — do they render.
• Admin login and content editing.
• Contact forms and newsletter sign-ups — do they send.
• Store (if any): add to cart, checkout, test payment.
• Critical plugins: SEO, cache, security, backups, e-commerce.
• PHP error logs — any fatal errors or deprecations.

If something fails, diagnosis is simple: deactivate plugins one by one until you find the culprit. The most common causes are outdated plugins, an old theme with custom code, and modifications in functions.php (or a child theme).

What usually breaks after a PHP upgrade

Experience from hundreds of WordPress sites shows the same patterns.

• Old plugins — code written for PHP 5.6/7.x uses removed functions (create_function(), each(), mysql_*). If a plugin has no update — replace it with an actively maintained alternative.
• An old theme with modifications — the parent theme's functions.php gets overwritten on update, and a child theme with errors lands on the new PHP. Check your custom snippets.
• Deprecations in the logs — code works but the logs fill up (dynamic properties, null in parameters). That is a fix list, not a failure — but it clutters monitoring.
• Fatal errors with "Call to undefined function" — almost always an old plugin or snippet. Diagnosis: wp-content/debug.log after enabling WP_DEBUG.
• Payment and integration problems — the most expensive type of failure. That is why you run a test transaction on staging, always.

If you see a white screen after the upgrade: enable debug mode in wp-config.php, check debug.log, deactivate plugins by renaming the wp-content/plugins directory, restore access and diagnose one by one. The full procedure is in the article on WordPress repair (WordPress care guides), and the causes of white screens are described in the PrestaShop white screen guide (the error mechanics are analogous).

Step 3 — production with monitoring

After green tests on staging, switch PHP in production — outside peak traffic, in a window where you can react.

Right after the switch check: the home page, login, the contact form and the admin panel. For the first few days watch error logs and response times — monitoring tools or your host's error panel are enough. The old PHP version stays available on the server, so rolling back is one change in the panel.

Once stable (a few days without errors), return to two clean-ups: clear the caches (cache plugin, OPcache, CDN — all layers) and check the PageSpeed Insights result — you should see improved timings.

Which PHP version to choose for WordPress

Target 8.3 or 8.4 — both are supported by WordPress and the plugin ecosystem. 8.4 has full support until the end of 2028, so it is the "longer" choice. If one of your critical plugins does not yet declare 8.4 compatibility, choose 8.3 and revisit the topic in a few months.

• Avoid two extremes: versions past EOL (7.4, 8.0, 8.1, and soon 8.2) — no security patches — and the newest version right after release (8.5+) on production sites with a rich plugin ecosystem. The sweet spot is the newest version all critical plugins support.

How long it takes and what it costs

For a typical WordPress business site the PHP upgrade is a few hours of work: backup, updates, staging, tests, production. If everything works, the cost is time, not budget.

Situations that get more expensive: unmaintained plugins requiring replacement (2–8 hours), an old theme with modifications (4–16 hours), a WooCommerce store with payments requiring transaction tests (1–3 days). The full range of help with such upgrades runs under WordPress care and the WordPress service.

The broader context — support dates for all PHP versions and platform recommendations — is in the article on PHP versions and support dates. If your site runs on 8.2, check the deadline in the PHP 8.2 end of life article.

Frequently asked questions

Will a PHP upgrade break my WordPress site?

The PHP upgrade itself changes neither content nor settings — it changes the runtime environment. The risk lies in code: old plugins, the theme and custom modifications. That is why the upgrade follows an order: update plugins on the old PHP first, then test on staging, and only then go to production. With that process the risk of failure is minimal, and the backup gives you a full rollback.

Which PHP version should I choose for WordPress in 2026?

PHP 8.3 or 8.4. Both are fully supported by WordPress and popular plugins. 8.4 has support until the end of 2028 — the long-term choice. Versions 7.4, 8.0 and 8.1 are past EOL and should not be used in production; 8.2 reaches end of support on 31 December 2026.

What should I do when a white screen appears after the PHP upgrade?

Enable WP_DEBUG in wp-config.php and check wp-content/debug.log — you will find the file and line of the error. The culprit is usually an old plugin or a theme snippet. Temporarily deactivate plugins (rename the wp-content/plugins directory), restore admin access, then activate plugins one by one. If the error is critical — restore the backup, switch PHP back, and diagnose on staging.

Do I need to update plugins before changing PHP?

Yes — that is the most important step. A current plugin version usually declares PHP 8.x compatibility; a two-year-old plugin does not. The order is deliberate: updates on the old PHP (where you can diagnose any problems), then the version switch. The reverse order combines two risk sources into one moment.

Will a PHP upgrade speed up my WordPress site?

Usually yes — newer PHP versions are faster, and WordPress sites with a rich plugin ecosystem benefit especially from engine optimizations. The real gain depends on hosting, cache and plugins. After the upgrade, clear every cache layer (plugin, OPcache, CDN) and measure in PageSpeed Insights — a before/after comparison gives you concrete numbers.

Can I roll back the PHP upgrade if something goes wrong?

Yes — rolling back is switching the PHP version back in the hosting panel, usually within a minute. That is why the old version stays on the server until stability is confirmed. If problems appear in code (not the environment), you also roll back plugins to previous versions — which is why it is worth noting their versions before updating (or keeping a full backup).

Sources

• WordPress — requirements and supported PHP versions
• WordPress — updating PHP (official guide)
• PHP.net — supported versions
• WordPress — Site Health (server information)

📖 See also: WordPress staging — testing updates safely.