PHP 8.2 without security fixes from 2027: upgrade WordPress

Security support for PHP 8.2 ends on 31 December 2026: after that date, the PHP project no longer publishes security fixes for this branch (php.net). For WordPress this is not a footnote, because 24.5 percent of WordPress installations reporting to WordPress.org run PHP 8.2 (WordPress.org, retrieved on 27 September 2026). This guide shows how operators of WordPress websites and WordPress shops can plan, test and carry out the move to PHP 8.3 or 8.4 before the end of the year: from the inventory and the test in a staging environment through to the switch at the hosting provider. If you would rather not do this work yourself, it is a fixed part of our WordPress maintenance service.

What ends on 31 December 2026

PHP 8.2 was released on 8 December 2022 (php.net). Active support with regular bug fixes ended on 31 December 2024; since then the branch has only received security fixes (php.net). According to php.net, this phase runs until 31 December 2026. After that the branch reaches its end of life and is no longer supported by the PHP project (php.net). For operators this means: if a security vulnerability in PHP that also affects 8.2 becomes known after the turn of the year, the PHP project will not ship a fix for it.

That PHP branches are maintained for four years is a fairly recent rule. The RFC on the release cycle, accepted in 2024, sets four years: two years of bug fixes followed by two years of security fixes (PHP Wiki). According to the RFC, both phases end on 31 December (PHP Wiki). The changes applied immediately to all branches supported at the time, starting with PHP 8.2 (PHP Wiki); PHP 8.1 received one additional year of security fixes and reached its end of life on 31 December 2025 with version 8.1.34 (PHP Wiki, php.net). PHP 7.4 still ran under the earlier, shorter rule and has been at its end of life since 28 November 2022 (php.net). Similar deadlines apply to the database, as our article on the end of support for MySQL 8.0 shows: runtime and database belong in the same maintenance plan.

After this two year period of active support, each branch is then supported for two additional years for critical security issues only.

The PHP Group, php.net: Supported Versions

Until the end of the year, the PHP project continues to provide security fixes for the 8.2 branch when they become necessary. When retrieved on 27 September 2026, the most recent release was PHP 8.2.34 from 24 September 2026, marked as a security release; the previous one, PHP 8.2.33, came out on 30 July 2026 (php.net). Anyone running 8.2 today should therefore not only plan the switch but also keep applying the current fixes until then. Whether individual hosting providers or Linux distributions will keep supplying 8.2 with their own fixes after the turn of the year cannot be said in general. Only the respective provider can answer that, and such a commitment should be in writing before you rely on it.

How widespread PHP 8.2 is among WordPress sites

WordPress.org publishes which PHP versions the WordPress installations reporting to WordPress.org run on. When retrieved on 27 September 2026, 24.535 percent were on PHP 8.2, rounded 24.5 percent (WordPress.org). The most common branch was PHP 8.3 with 25.748 percent, rounded 25.7 percent (WordPress.org, retrieved on 27 September 2026). PHP 8.2 therefore follows directly behind 8.3 and is no marginal case in the WordPress install base. The totals below are our own additions across the individual fields of the statistics.

Put these figures next to the calendar and the picture is clear: if the distribution stayed as it is, from 1 January 2027 the majority of WordPress installations reporting to WordPress.org would be on branches for which the PHP project no longer publishes security fixes. A combined 62 percent on PHP 8.2 or older compares with 37.8 percent on 8.3 or newer (WordPress.org, as of 27 September 2026; php.net). How far the distribution shifts until then is open. The gap does show, however, how many installations still have the switch ahead of them.

A second count comes from W3Techs. By its own account, its sample covers well over 20 million websites (W3Techs). Among websites using PHP 8, 29.4 percent run PHP 8.2 and 33.2 percent run PHP 8.3; this makes 8.3 the largest subversion of PHP 8 (W3Techs, as of 1 September 2026). Among all websites using PHP, 28.7 percent still run major version 7 (W3Techs, as of 1 September 2026); its last branch 7.4 has not received security fixes since 28 November 2022 (php.net).

What WordPress recommends and what it still allows

WordPress.org recommends PHP 8.3 or newer for running WordPress (WordPress.org). At the same time, according to WordPress.org, WordPress also runs in legacy environments where only older versions are available, with PHP 7.4 or newer and MySQL 5.5.5 or newer (WordPress.org). That is a statement about what still runs, not a recommendation: in the same note, WordPress.org points out that these older versions have reached their official end of life and may expose the site to security vulnerabilities. According to php.net this applies to PHP 7.4 to 8.1 (php.net); PHP 8.2 only reaches that point after 31 December 2026.

For WordPress 7.0 and 7.1, the compatibility table lists PHP 7.4 to 8.5 as compatible and PHP 7.3 and older as no longer compatible (WordPress.org). Support for PHP 7.2 and 7.3 was dropped with WordPress 7.0 (WordPress.org). This compatibility refers to WordPress core, not to themes and plugins. Since July 2025, PHP 8.3 has been considered fully compatible with WordPress 6.8 (WordPress.org). If you still run an older WordPress version, update WordPress itself first and only then switch the PHP version.

WordPress takes its PHP notices from the Serve Happy API of WordPress.org. For PHP 8.2 it reports is_supported: false, meaning no longer actively supported, recommends version 8.3 and names 7.4 as the minimum version (WordPress.org). The status "no longer actively supported" describes the current state; the end of security fixes follows at the end of the year. The source code of the wp_check_php_version() function also records that the minimum supported PHP version will be raised to at least 8.0 in the future; the source code gives no date (WordPress.org). Which safeguards matter besides the PHP version is summarized in our article on WordPress security 2026.

Choosing the target version: 8.3, 8.4 or 8.5

Compared with PHP 8.2, PHP 8.3 adds one more year of security support, PHP 8.4 two years and PHP 8.5 three years (php.net). A longer runway means fewer switches in the coming years. A newer version does, however, require that the theme and plugins already handle it, and the younger the version, the more often that sign-off is still missing. All three candidates meet the WordPress.org recommendation of PHP 8.3 or newer (WordPress.org).

• Check vendor information: For plugins and themes, the product page or changelog usually states up to which PHP version they have been tested. If that information is missing, it is a task to check, not a reason to rule the plugin out.
• Shop plugin first: In a WordPress shop, the shop plugin and its payment and shipping modules decide the target version. For shops we usually choose 8.3 or 8.4; PHP 8.5 only becomes an option once every vendor of the extensions in use lists it as tested.
• Hosting offer: Not every plan provides every version. Which versions are available and until when belongs in the same enquiry.
• Your own code: Custom plugins, theme adjustments and snippets in functions.php are tested like third-party plugins. There is no vendor who tests them in advance.
• Maintenance rhythm: If you maintain the site regularly anyway, 8.3 usually works well; the next switch is then due at the end of 2027 (php.net).

Step 1: Inventory

It starts with a plain list: which PHP version is running, which WordPress version, which theme, which plugins in which version, and which of them are active? With WP-CLI this can be collected on the command line in a few commands. Without shell access, the same information is available in the WordPress admin under Tools and Site Health.

• PHP version of the live environment and the staging environment
• WordPress version and state of automatic updates
• Active theme, parent theme and custom adjustments
• All plugins with version, status and date of the last update
• In-house plugins and snippets without an external vendor
• Payment, shipping and integration modules of a shop
• Cron jobs and background processes that call PHP outside WordPress
• Responsibilities: who decides at the hosting provider, who tests, who signs off?

Plugins that have not received an update for a long time deserve particular attention. In our experience they are a frequent source of surprises during a PHP switch. For each of them there are three routes: update, replace or, if it is no longer needed, remove. The decision is easier if the list also records what the plugin is used for and who in the company needs it.

Step 2: Checking compatibility

Testing has two levels. The first is quick and coarse: can all of the PHP code be parsed by the target version at all? A syntax check with the target version's PHP interpreter finds parse errors, meaning code that will not even start on the new version. It does not find deprecated function calls or runtime errors.

# Parse all PHP files in wp-content with PHP 8.4
# (finds parse errors only, no runtime problems)
find wp-content -name '*.php' -print0 \
  | xargs -0 -n1 php8.4 -l \
  | grep -v 'No syntax errors'

The second level takes more effort and tells you more: the website runs in a test environment on the target version, and every PHP notice is written to a log file. Three entries in the wp-config.php of the test environment are enough for this. On the live website, error display stays switched off, because error messages can reveal paths and details.

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

After a pass through the most important pages and processes, wp-content/debug.log shows which plugins use deprecated functions or produce warnings. The entries can usually be traced to a plugin or theme directory, because the file path is part of the message. Three kinds of entries need to be told apart:

• Deprecated: A function or syntax is considered outdated. It still works today but may not in a later PHP version. Not an obstacle to the switch, but an item for the next maintenance round.
• Warning: Something behaves differently than expected, but the page is still delivered. Often a sign of faulty data handling that should be cleared up before the switch.
• Fatal error: Execution stops. Affected pages or functions cannot be used. This is a reason to postpone the switch until the cause has been fixed.

When a plugin does not keep up

• Wait for an update: If the vendor has announced an adapted version and the plugin is not business-critical, the switch can be timed accordingly. This includes a date by which a decision will be made at the latest.
• Replace: Maintained alternatives exist for many tasks. A replacement needs its own test, because data and settings have to be carried over.
• Adapt: For your own code or abandoned plugins of manageable size, adapting them to the target version is often the shorter route.
• Remove: Plugins whose function no longer matters to the business are sensibly removed altogether. Every plugin removed is one test fewer, including in future switches.

Step 3: Testing in the staging environment

The test environment is a copy of the live website with identical code and data that is as current as possible, but with its own address and the target PHP version. The prerequisite is a fresh, verified backup, not only for the copy but also as the way back for the live switch. How to set up backup and restore reliably is described in our article on backup and disaster recovery for online shops.

1. Back up the files and database of the live website and run a trial restore.
2. Create the staging copy, block it for search engines with noindex and protect access with a password.
3. Switch the PHP version of the staging environment to the target version and enable the debug log.
4. Bring the theme and plugins to the versions their vendors have released for the target version.
5. Click through the core journeys: home page, search, forms, login, cart, checkout, customer account.
6. Check background tasks: cron jobs, imports, exports, newsletter and integration syncs.
7. Evaluate the debug log, trace every finding to a plugin or piece of code, and fix or replace it.
8. Document the result: what was tested, what stood out, what was changed, who signed off?

Specifics of WordPress shops

A shop built on WordPress has more moving parts in a PHP switch than a company website: the shop plugin itself, payment providers, shipping modules, invoicing and accounting connections, often an inventory management system as well. Each of these modules is maintained by a different vendor and has its own release rhythm. An error in the invoicing module does not show up when clicking through the home page, but it does with the first real purchase after the switch. The test therefore also covers:

• Payment modules: run through the checkout completely in test mode, including cancellation and refund.
• Shipping: check label creation and shipment tracking with test data.
• Invoices: verify generation, number range and dispatch of invoice documents.
• Integrations: test the sync with inventory management, marketplaces or accounting in both directions.
• Scheduled tasks: stock syncs, price imports and product feeds often run at night; read their logs after the first run.

Step 4: Switching at the hosting provider or on your own server

With many hosting plans, the PHP version is a setting per website or per directory. The switch itself is then done quickly; the work lies before and after it. What matters is that the switch happens at a quiet time, that someone checks the website right afterwards and that the way back to 8.2 remains open until the end of the year in case something was overlooked. With our hosting with server maintenance, we agree the time of the switch with you in advance. On your own server, several PHP versions usually run side by side, each with its own FPM pool. The website is then not rebuilt; its web server entry simply points to the pool of the new version. The old pool stays installed but unused until the end of the year. That way the route back is a single configuration change.

• Check the PHP version in WordPress Site Health
• Open the home page, checkout, forms and login
• Watch the server PHP error log during the first hours
• Check cron jobs and scheduled tasks the next day
• Document the way back: which setting restores 8.2, and who is allowed to trigger it?

Timeline to the end of the year

Between early October and 31 December there are just under three months, and in retail they are not the quietest. Anyone running a shop will be reluctant to swap the runtime between mid-November and Christmas. How to absorb traffic peaks during this period is described in our article on the virtual waiting room for Black Friday. For the PHP switch this means the change should be done before the busy phase.

1. October, inventory and target version: record versions, flag outdated plugins, set the target version, clarify what the hosting provider offers.
2. October to early November, staging test: set up the test environment, evaluate the debug log, update or replace plugins, fix findings.
3. Early to mid-November, live switch: maintenance window outside peak hours, switch, checks immediately afterwards and the following day.
4. Mid-November to end of December, observation: keep an eye on the error log and processes, no major changes during the Christmas business, keep the way back to 8.2 available until the turn of the year.
5. From January 2027, clean-up: remove PHP 8.2 from the plan or server, complete the documentation, note the next switch. PHP 8.3 receives security fixes until the end of 2027, PHP 8.4 until the end of 2028 (php.net).

The plan does not only fit WordPress. If you run a shop on another platform alongside a WordPress website, you can bundle maintenance windows and plan tests together. How such an upgrade is prepared for a Shopware shop is shown in our article on preparing the Shopware 6.8 upgrade.

How we support the switch

We handle the PHP switch as part of our WordPress maintenance: we test updates to core, theme and plugins in a staging environment, apply security patches, back up daily and monitor availability. If a conflict appears after an update, we roll back to the previous state.

Which option fits depends on how much you want to look after yourself and how your website is hosted today. In a short conversation we clarify the current state and the timeline to the end of the year; write to us using the contact form for an initial assessment.