PHP 8.2 end of life is 31 December 2026, when the PHP project stops its security support for that branch. For a WordPress or WooCommerce store, I would plan a tested move to a supported version before then, with staging, plugin checks, a recoverable backup and a checkout test before production.
Key takeaways:
- PHP 8.2 remains in upstream security support until 31 December 2026. It does not suddenly stop running that night.
- WordPress recommends PHP 8.3 or newer. WooCommerce’s server recommendations page asks for PHP 8.3 or greater and says it is tested up to PHP 8.4.
- A plugin’s WordPress compatibility label does not prove its PHP compatibility.
- Test payments, scheduled jobs and integrations, not just the homepage.
- Keep your rollback plan compatible with orders placed after the upgrade.
When does PHP 8.2 end of life happen, and what does it mean?
PHP 8.2 reaches the end of upstream security support on 31 December 2026, according to the PHP supported versions table. End of life means the PHP project no longer maintains that branch after its support period ends.
PHP is the server-side programming language that runs WordPress and most of its plugin code. Your hosting company chooses the installed PHP build, while your application determines which versions it can use successfully.
The date is a maintenance deadline, not an automatic outage. An unsupported runtime can continue serving pages, which makes it easy to postpone the work until a separate fault forces your hand.
I would not describe every PHP 8.2 store as compromised. Nor would I treat a working checkout as proof that staying on an unsupported version is sensible. Compatibility, security maintenance and current evidence of an incident are different questions.
Some hosts provide extended support or backported patches. If yours does, ask which build they maintain, what their service covers and when it ends. A host’s maintenance contract does not change the PHP project’s upstream calendar.
Before you book the change, confirm the date on the PHP supported versions page and your host’s own policy.
PHP 8.2 end of life: choosing a replacement version
Choose a supported PHP branch that your specific WordPress, WooCommerce and extension stack can pass on staging. The newest number in the hosting selector is a candidate to test, not an instruction to switch immediately.
The WordPress requirements page recommends PHP 8.3 or greater. The WooCommerce server recommendations cover WooCommerce 10.8 and later, ask hosts for PHP 8.3 or greater and say it is tested up to PHP 8.4. Check that page again when you book the change.
That distinction matters if your host offers PHP 8.5. Its availability in a control panel does not establish support for every payment extension, custom snippet or shipping integration in your store.
| PHP branch | Upstream security support ends | Practical decision |
|---|---|---|
| 8.2 | 31 December 2026 | Plan the upgrade before support ends. |
| 8.3 | 31 December 2027 | Consider when your stack supports it; leave room for the next upgrade. |
| 8.4 | 31 December 2028 | A useful staging candidate under the current WooCommerce recommendations. |
| 8.5 | 31 December 2029 | Verify support across your complete stack before selecting it. |
Those dates come from PHP’s support table. They are not performance rankings, and I would not promise a faster checkout simply because a runtime has a longer support window.
Keep the latest patched release within your chosen supported branch. Moving from an old 8.2 build to another old build on a different branch would leave part of the maintenance problem unresolved.
How do you check the runtime and audit plugin compatibility?
Read the active web runtime in WordPress Site Health and confirm it in your hosting panel. If you also use command-line jobs, check their runtime separately because a host can run the website and its command line on different PHP versions.
In WordPress, start with Tools, Site Health, Info, then Server. For WooCommerce, keep a copy of its system status report with the upgrade notes. These details make a support conversation much more useful than saying the site is on “the latest PHP.”
Build an inventory of active plugins, the active theme, must-use plugins, snippets and custom integrations. Include software that performs work after checkout, such as fulfillment exports, subscription renewals or invoice generation.
For every component, record its installed version, vendor support status and documented PHP compatibility. “Requires PHP” describes a minimum. “Tested up to” in the WordPress plugin directory generally refers to WordPress, so do not read it as a PHP certification.
Ask the maintainer when documentation is unclear. If a critical extension is abandoned, investigate a replacement before the deadline; a runtime change will not repair software that nobody maintains.
PHPCompatibilityWP provides a WordPress-specific ruleset for PHP_CodeSniffer. A developer can use it to identify potential compatibility problems in code, but a clean static scan cannot prove a gateway or external API works during checkout.
PHP 8.2 end of life: staging test checklist
Use a recent staging clone with the target PHP version, isolated payments and safe email handling. Staging is a separate test copy of the site; it should resemble production without sending real customer messages or accepting real payments.
First establish that the clone works on the old runtime. Otherwise, a staging configuration fault can look like a PHP regression. Disable indexing, protect access and review whether production webhooks or fulfillment connections were copied across.
Test the upgrade with repeatable customer journeys
Use this numbered checklist and record evidence beside each item:
- Restore the files and database into an isolated environment, then verify the restore actually opens and accepts an administrator login.
- Record the baseline runtime, software versions and enabled PHP extensions. Compare the target environment before changing application code.
- Update components that need compatibility fixes on staging. Test those updates before switching PHP so you can identify which change caused a failure.
- Switch staging to the target patched PHP version. Read the application and PHP error logs before starting customer journeys.
- Open a simple product and a variable product, choose valid options and add both to a cart. Check prices, images and stock messages.
- Complete guest and signed-in checkouts through each gateway’s sandbox. Verify the resulting order status and test payment confirmation.
- Test a coupon, representative shipping zones and the tax configurations your business actually uses. Compare totals with the baseline.
- Check transactional email delivery in the test environment. Confirm that recipients, templates and order details are correct without contacting real customers.
- Open My Account, order history and password reset. Test the administrative workflow for finding and editing an order.
- Run representative scheduled jobs and external API integrations with safe fixtures. Check failed jobs and retries, not only successful requests.
- Test forms and verify browser and server-side tracking in their diagnostic tools. Respect consent settings while checking events.
- Read the logs after every group of tests. Record a pass, a reproducible failure or an unresolved issue before moving on.
Check tracking and classify upgrade errors
For TuckerTub, I built server-side Meta CAPI and TikTok tracking alongside a headless WooCommerce and Next.js setup. That experience is why I include the event path in an upgrade plan: a checkout screen and its downstream tracking are separate pieces of the system.
Keep warnings and fatal errors separate in the report. A deprecation warning needs a maintenance decision; a fatal error in payment confirmation is a release blocker. Hiding warnings from customers does not resolve either cause.
Should you upgrade before Black Friday or wait until December?
My working rule is to finish a routine PHP migration at least a week before a major sale, then freeze discretionary changes. Black Friday falls on 27 November 2026, so the available testing window is already worth protecting.
A code freeze is a planned period when you stop optional production changes. It leaves the team working with a known configuration while marketing campaigns and customer demand increase.
If you can complete the compatibility work and a proper test cycle before the freeze, do that. If the store is stable on a patched PHP 8.2 build and you cannot complete testing safely, an early December maintenance window may be the more practical option, provided it finishes before upstream support ends.
This is a scheduling judgment, not a rule to delay urgent security fixes. Review an actively relevant vulnerability with your host and developer as soon as it is known. A sale date does not make a security problem disappear.
Give the migration a named owner and a booked window. “After Black Friday” is too vague if December arrives with fulfillment pressure, staff leave and an unresolved gateway dependency.
If you need the work owned month to month, my monthly security and maintenance support covers the ongoing maintenance conversation. The runtime deadline should become a planned task rather than a recurring warning nobody closes.
How do you roll out safely and recover without losing orders?
Take a fresh backup, switch during an agreed low-risk window and verify the complete purchase journey immediately afterward. Prepare the rollback steps before the change, including how you will protect new orders if any database restoration becomes necessary.
Confirm that the old runtime can still be selected and that it is patched and supported at the time you need it. A temporary fallback is a recovery option, not a reason to remain on PHP 8.2 after its support window.
A runtime-only rollback and a database rollback are different actions. If the fault comes from PHP compatibility, switching the runtime back may be enough; restoring yesterday’s database could erase today’s orders for no benefit.
Where a database restore is unavoidable, coordinate with the host and whoever owns order operations. Preserve orders and payment records created after the backup, then reconcile them deliberately. Do not copy the staging database over a live store that has continued trading.
After release, watch error logs, payment failures, order flow and the background queue for 48 hours. That is my working observation period.
Check administrative workflows as well as customer pages. A broken export may surface only when a member of staff processes an order the following morning.
For an existing outage, WordPress rescue starts with identifying the failing layer. If the site works but remains slow, WordPress speed optimization is a separate investigation; do not hide performance work inside an unmeasured runtime promise.
Frequently asked questions
When does PHP 8.2 reach end of life?
PHP 8.2 end of life is 31 December 2026, according to the PHP project’s supported versions table. That is the end of upstream security support for the branch. Your website may continue running afterward, but you should arrange a tested upgrade or verify a clearly defined vendor-maintained support arrangement.
Which PHP version should WooCommerce use?
Choose a supported branch that your full application stack passes on staging. WordPress recommends PHP 8.3 or newer, while WooCommerce’s current server recommendations list PHP 8.3 or newer and testing through 8.4. Confirm your installed extensions and custom code before selecting a version in the hosting panel.
Will upgrading PHP break my plugins?
Yes. A plugin, theme or custom integration can depend on behavior that changes between PHP branches. Check vendor compatibility information, scan custom code where appropriate and test real store workflows on staging. A plugin’s WordPress compatibility label alone does not establish that it works on your intended PHP version.
How do I check my PHP version?
In WordPress, open Tools, Site Health, Info and the Server section to find the active web runtime. Confirm the version and patch level with your host. If cron jobs or administrative commands use command-line PHP, check that runtime separately because it may differ from the one serving your website.
What happens if I stay on an unsupported PHP version?
The software may keep running, but the PHP project will no longer provide upstream security maintenance for that branch after 31 December 2026. Some vendors maintain their own builds. Ask your host for written scope and an end date, and keep a supported-version migration on the calendar.
If you are also preparing for the sale, read my WooCommerce Black Friday 2026 checklist first. PHP changes belong before the code freeze, not during it.
If you want the PHP upgrade tested properly before it touches a live store, my $490 WooCommerce technical review flags PHP and plugin compatibility risks, and my monthly maintenance plan can run the upgrade for you.
