PHP 8.2 end of life: what to do with a WordPress site

Your hosting provider sent an email about changing PHP versions, the WordPress admin panel shows a yellow “update PHP” notice, and your contractor says: “everything works, do not touch it.” The cause is the same: PHP 8.1 has been unsupported since January 1, 2026, PHP 8.2 reaches end of life on December 31, 2026, and WordPress and WooCommerce raise their requirements right after the language does. In this article: what this means for your website, how to check your PHP version in two minutes and in what order to move to PHP 8.3 so that the website does not go down.

What “PHP without support” means

PHP is the language WordPress and most other content management systems are written in. The website code is run by the PHP interpreter on the hosting server, and each PHP version has a limited lifespan. For about two years after release, a version is in active support: the developers fix bugs and vulnerabilities and release updates regularly. For another two years, the version receives only security fixes, and only critical ones, as needed. Then comes end of life: there are no more updates, and php.net advises moving to a newer version as soon as possible.

The calendar as of November 8, 2026, according to the official PHP supported versions page:

Regular bugs in PHP 8.2 have not been fixed for almost two years, and starting January 1, 2027, vulnerabilities will no longer be patched either. The 8.1 branch is closed: the last release is 8.1.34, and there will be no new ones. October 2026 shows the difference: PHP released 8.2.35, 8.3.36, 8.4.27 and 8.5.12 with security fixes, while the 8.1 branch got nothing (learn more in the article PHP2Shell: critical PHP vulnerabilities).

According to wordpress.org statistics as of November 8, 2026, about 32% of WordPress installations that send data there run on PHP below 8.2, and almost 23% more run on PHP 8.2. Without an update, by January more than half of these installations will be on unsupported PHP.

Risks of staying on old PHP

On January 1, 2027, a website on PHP 8.2 will not shut down: it will open and accept orders as before. The problems build up gradually.

Vulnerabilities stay open. If a vulnerability is found in PHP 8.2 after December 31, no fix will be released for this branch. The CMS and plugins may be updated to the latest versions, but underneath them will be a language in which no one will patch new vulnerabilities.

CMSs stop updating on old PHP. This is already happening:

• WordPress 7.0 (May 2026) raised the minimum PHP version to 7.4. Websites on PHP 7.2 and 7.3 have stayed on the 6.9 branch and will not get new core versions.
• WooCommerce 11.6, scheduled for February 2027, will require PHP 8.1 or later. The last release for PHP 7.4 and 8.0 is 11.5; only fixes for vulnerabilities rated CVSS 9 and higher will be backported to it.

When CMS and plugin updates stop installing, their security fixes stop too. The risk grows every month, even if no one touches the website.

Old PHP starts to cost money. Hosting providers do not keep outdated versions forever: a version may be removed from the control panel or become a paid option. Since January 1, 2026, GoDaddy has moved PHP 8.1 into a paid “Extended Support” add-on and enables it automatically when the hosting plan is renewed: the owner pays for the website to stay on an outdated version.

How to check your website’s PHP version

You do not need a developer for this check.

WordPress. Open “Tools → Site Health,” the “Info” tab, “Server” section. The “PHP version” row shows the current version; if it says 8.3 or higher, no urgent action is needed. Starting with WooCommerce 11.3, stores on WooCommerce with PHP 7.4 or 8.0 see a separate notice with the PHP version in the admin panel; the version is also shown under “WooCommerce → Status,” in the “Server environment” block.

Any other CMS. cPanel, Plesk, ISPmanager and the control panels of Ukrainian hosting providers have a section for choosing the PHP version. There you can see which version is enabled for each website and which ones are available.

Background tasks (cron), such as product exports, data exchange with the accounting system and email campaigns, sometimes run on a different PHP version than the website: the website is already on 8.3, while the nightly price list import runs on 7.4. If you have such tasks, ask your hosting provider or server administrator to check the version for them as well.

Why not just switch the version in the panel

You can change the PHP version with one click in the hosting control panel. That is where so many “the website stopped working after a PHP update” stories come from: someone switched the version and got a white screen or the message “There has been a critical error on this website.” Between PHP 7.4 and 8.3 the language changed noticeably, and old code breaks on the new version. Examples from the official PHP change lists:

• PHP 8.0 removed the create_function() and each() functions, which are common in themes and plugins from ten years ago. On PHP 8, calling such a function causes a fatal error, and the page does not open.
• PHP 8.0 prohibits calling a regular class method statically. This is one of the most common errors after an upgrade: the log shows “Non-static method … cannot be called statically.”
• PHP 8.2 deprecated creating dynamic object properties. The website works, but the log fills up with Deprecated notices. In future PHP versions such code may stop working, so it is better to fix it in advance.

The WordPress developers test the core on new PHP versions themselves. What usually breaks is what has been added on top of the core:

1. A custom theme or template written many years ago and not updated since.
2. Abandoned plugins and modules, including “nulled” (cracked) copies of paid plugins: they never get updates at all.
3. Custom code: edits to theme files, integrations with the accounting system and delivery services, import scripts.

Why putting off updates is riskier

The reason owners put off updates for years is understandable: once, after an update, a form or banner broke, and since then the contractor has kept the website “frozen,” with automatic updates disabled.

We consider this a losing strategy. A frozen website does not become more stable; it falls further behind: in two years you will have to update not one plugin but the core, twenty plugins, the theme and PHP all at once, and more breaks that way than with small regular updates. What keeps the website from breaking is a staging copy of the website and a ready rollback plan.

How to safely move to PHP 8.3

This sequence works for any website on PHP; the specifics of WordPress and WooCommerce are in the next section.

Which PHP version you need. WordPress recommends PHP 8.3 or higher. We recommend 8.3 at a minimum, and 8.4 if all the website’s plugins or modules officially support it: security fixes for 8.4 will be released until the end of 2028, for 8.3 until the end of 2027. Moving to 8.2 now makes no sense: in two months the work would have to be repeated. One thing to note about 8.4: the IMAP extension (the website uses it to fetch email from a mailbox) has been removed from the standard PHP distribution, and your hosting provider may not have it.

1. Take inventory. CMS version, plugins or modules, theme or template, licenses for paid extensions, integrations and background tasks. This step often reveals that some plugins have not been updated for years. In the PHP version section of the hosting control panel, compare the PHP extensions: which ones are enabled now and whether the new version has them. If the new version lacks, for example, soap or gd, data exchange with an external service or image processing will stop working even though the website code itself is fine.
2. Make a backup of the files and the database and check that the website can be restored from it. Sometimes the archive is missing the database or is corrupted, and this comes to light on the day of an outage.
3. Deploy a staging copy on a separate domain (for example, test.yoursite.com) with the same PHP, database and web server versions as on the production server. Password-protect the copy to keep out visitors and search engine bots, and disable real payments, emails to customers and data exchange with the accounting system on it, or test orders will reach your accountant.
4. Update the CMS, plugins and modules while still on the old PHP version. Many errors that appear after the switch are already fixed in fresh versions of plugins and the core.
5. Switch PHP on the staging copy and enable the error log. Go through the website as a customer and as an employee: home page, catalog, filter, product page, cart, checkout, payment in test mode, forms, customer account, search, admin panel. Separately, run the import, exports and other background tasks.
6. Fix what you find. An incompatible plugin is updated or replaced with an alternative, and old theme code is rewritten. If there is no replacement for a plugin and its author does not respond, you need a developer.
7. Switch the live website during off-peak hours, right after a fresh backup. Clear the CMS cache and the caching plugin cache, or you and your visitors will see pages generated by the old PHP version, and the check will give a false picture. Then go through the same scenarios as on the staging copy.
8. Monitor for a few days. Some errors only show up on rare actions: an order return, a nightly cron job, a once-a-day export to a marketplace. Review the error log daily.

Rollback plan

The rollback is planned before the switch. Changing the PHP version does not change the website’s files or database, so if problems arise, the first step is to switch back to the previous version in the hosting control panel. If nothing else was changed on the live website along with PHP, the website will return to its previous state.

Restoring the database from a backup is a last resort: everything that happened after the backup was made (orders, registrations, inquiries) will be lost. For an online store, these are lost orders, so they are exported in advance, or the website is switched during a window when there are almost no orders.

Notes for WordPress and WooCommerce

There is an official wordpress.org guide to updating PHP on WordPress. It advises updating the core, themes and plugins and checking compatibility with the PHP Compatibility Checker plugin. We disagree with the last piece of advice. The plugin warns on its own page in the plugin directory that it is no longer maintained, that there will be no new versions, including security fixes, and that it checks compatibility only up to PHP 8.0. For a move to 8.3, its results are almost useless; a check on a staging copy with the error log enabled is more reliable.

If the theme and plugins contain a lot of custom code, a developer can also run it through the PHPCompatibilityWP ruleset for PHP_CodeSniffer (a program that analyzes code without running the website), with 8.3 as the target version. This check finds removed and deprecated functions, but it will not show how the website behaves with real data, so it does not replace a staging copy.

In WordPress, the error log is enabled in the wp-config.php file on the staging copy:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Errors are written to the wp-content/debug.log file, and visitors do not see them. Debug mode is not kept on the live website: the WordPress documentation describes these tools as meant for local and staging environments, so turn it off after the check.

What else to check on WordPress:

• Page builders and their add-ons (Elementor and widget packs). The builder itself is updated regularly; third-party widget packs fall behind more often.
• Paid themes bought many years ago. Updates for such themes are usually tied to an active license with the seller, and without it you cannot download a new version. Also check whether the theme files were edited directly: an update will wipe out those edits, so they are first moved to a child theme.
• WooCommerce and its plugins: payment, shipping, product exports. They must be compatible both with the new PHP version and with the current WooCommerce version.

If, after the switch, you see the message “There has been a critical error on this website” instead of the website, the steps to take are described in the article WordPress critical error after an update.

Frequently asked questions

Can I stay on PHP 8.2 after December 31, 2026?

The website will keep opening, but new vulnerabilities in PHP 8.2 will not be patched, and your hosting provider may remove 8.2 from the control panel or make it a paid option. WordPress recommends PHP 8.3 or higher; it is better to plan the move yourself rather than wait for an email from your hosting provider.

Should I go straight to PHP 8.5?

PHP 8.5 is the newest released version: active support until the end of 2027, security fixes until the end of 2029. The rule is the same as for 8.4: move to it only if the CMS, the theme and all plugins or modules officially support this version. If even one important plugin does not support it, stop at 8.3 or 8.4.

Old website and no contractor: where to start?

This is the hardest case: the website was built about seven years ago, the studio has closed or the freelancer does not respond, and no one knows what is inside. Updating such a website blindly is not an option, and leaving it on PHP 7.4 is dangerous. Start with what you can do yourself:

• Collect the access credentials. Hosting control panel, FTP or SSH, database, website admin panel, domain registrar. For paid WordPress plugins, the accounts they were purchased with.
• Make sure the hosting and domain are registered to you, not to the former contractor. If they are registered to the contractor, transfer them before work begins: how to do this is described in the article the developer disappeared: how to take back your website.
• Make a backup through the hosting control panel and download it to your own computer.
• Write down what must work on the website: forms, orders, integrations, exports. The new contractor will use this list to check the website after the move.

From here, you need a specialist. A new team starts with an audit: which versions are installed, which plugins are abandoned, whether there are edits to the core and traces of hacking. After the audit, it becomes clear whether updating plugins and fixing the theme will be enough or whether it is easier to rewrite part of the code. Before that point, a contractor cannot name the scope of work.

If your current hosting provider does not offer PHP 8.3 or runs an old MySQL version, the website will have to be migrated. Move it to a server or hosting plan registered to you, so that access no longer depends on a contractor.

How RIVERIT helps you move to a new PHP

We offer technical support for your website: it includes CMS and plugin updates (usually monthly), backups and website and domain monitoring. We carry out the move to a new PHP version in the order described in this article: staging copy, testing, code fixes, the switch and monitoring after it; we work with websites on WordPress and WooCommerce, as well as on Laravel and Django. If the website runs on a VPS or dedicated server, we take on server administration (the server is rented under your account), including changing the PHP version. If your current hosting provider does not support PHP 8.3, we will migrate the website to our hosting: servers in Europe, daily backups to separate storage, and migration from another hosting provider is included in technical support. We respond to clients on support within one hour during business hours, and if the website goes down, we fix it outside business hours too, if your plan includes this.