PHP 8.2 reaches end of life on 31 December 2026, which means it stops receiving security fixes from that date. If your WordPress or WooCommerce site still runs on PHP 8.2, plan a move to PHP 8.4 (security support until 31 December 2028), test it on a staging copy first, and schedule the switch so it does not land in the middle of Black Friday or Christmas trading.
PHP 8.2 end of life: WordPress sites keep running, unpatched
Your site will not stop working on 1 January 2027. PHP 8.2 will keep running exactly as it does today. What changes is that the PHP project will no longer publish fixes for security problems found in it, so any new vulnerability in PHP 8.2 stays open on your server.
For a WooCommerce store that takes payments and holds customer data, close that risk on purpose, with a plan. Some hosts move sites off unsupported versions on their own schedule or offer paid extended support, so check your host’s notices.
The official dates are on the PHP supported versions page. As of 26 October 2026 they are:
- PHP 8.2: security support ends 31 December 2026.
- PHP 8.3: security fixes only, until 31 December 2027.
- PHP 8.4: active support until 31 December 2026, then security fixes until 31 December 2028.
- PHP 8.5: active support until 31 December 2027, then security fixes until 31 December 2029.
How to check which PHP version your site uses
In wp-admin Site Health
Go to Tools > Site Health > Info and open the Server section. The PHP version line shows what your site is actually running.
In your hosting panel
On cPanel hosting the setting is usually under MultiPHP Manager or Select PHP Version, depending on your host. Managed WordPress hosts tend to have a PHP setting in the site dashboard. If you cannot find it, ask support where it lives on your plan.
On the command line
The PHP version on the command line can differ from the one serving your website. wp --info shows the version WP-CLI uses, which your server cron jobs may also use.
Which PHP version to move to
For most WordPress and WooCommerce sites I would move to PHP 8.4. Security support runs to the end of 2028, so you will not repeat this exercise for two years.
- PHP 8.3 is a stepping stone if a plugin you depend on does not yet work on 8.4. It buys one year only.
- PHP 8.5 has the longest support window but is the newest, so confirm WordPress, WooCommerce and every key plugin list it as compatible first.
Check the release notes of your theme and key plugins (payment gateway, shipping, subscriptions, page builder) for the version you pick. If a vendor does not mention it at all, test that plugin with extra care.
How to test the upgrade on staging
Never change the PHP version on a live store first. My usual order is:
- Take a full backup of files and database, and confirm you can restore it.
- Create a staging copy of the site, blocked from search engines.
- Update core, WooCommerce, the theme and all plugins on staging. Outdated plugins are the usual reason a PHP upgrade fails.
- Switch staging to the new PHP version.
- Turn on error logging so you can see problems without showing them to visitors.
- Run real tasks: add to cart, apply a coupon, check out with a test payment, log in as a customer, send the contact form, run your imports and exports.
- Read the error log, fix or replace anything that fails, and repeat until the log is clean of fatal errors.
To log errors to a file on staging, add this to wp-config.php above the line that says to stop editing:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Errors are then written to wp-content/debug.log. Remove these lines, or set WP_DEBUG back to false, before you copy any configuration to the live site.
Common breakages, in general terms
- Abandoned plugins using code newer PHP versions no longer accept, usually showing as a fatal error or white screen.
- Custom theme or child theme code written years ago that nobody has checked since.
- Deprecation notices in the log: not failures today, but a list of what breaks on a later version.
- Encoded commercial plugins that need a loader built for your exact PHP version. Ask the vendor.
- Payment and shipping integrations that work on the front end but fail quietly on webhooks, so test an order through to “processing”.
Rollback plan
In most hosting panels the PHP version is a dropdown, so rolling back takes a minute, as long as you did not change plugins or the database at the same moment. Keep the PHP change separate:
- Update plugins on live first, on the current PHP version, and let that settle.
- Switch PHP on a quiet day and time for your audience.
- Keep a fresh backup from just before the switch.
- Watch the error log, test an order, and check uptime for the next few hours.
- If checkout or a key feature fails and you cannot fix it quickly, switch back to 8.2 and fix it on staging.
When to do it: a timeline around peak season
The deadline sits right after peak season. Black Friday is 27 November 2026, Cyber Monday 30 November, then Christmas and Boxing Day. For stores serving India, Dhanteras is 6 November and Diwali 8 November. Do not change PHP on a live store inside those windows.
- This week (from 26 October): check your PHP version in Site Health, list your plugins, and set up staging.
- Early November: test on staging. If everything passes and you are not in a Diwali sale, switch live before mid-November so you have a couple of weeks of normal trading to catch issues before Black Friday.
- From about a week before 27 November to the end of Cyber Monday (30 November): no PHP change on live. Keep the store stable.
- December: if you did not switch in November, finish testing now and pick a quiet day before Christmas, or the days after Boxing Day.
- Before 31 December 2026: live site on PHP 8.4 (or 8.3 as a short stop), staging cleaned up, debug settings removed.
If testing finds a problem that cannot be fixed before your peak, stay on 8.2 through the sales and upgrade in the last week of December.
The same checklist fits sites like the Nneihaa Vvikas WordPress site development and maintenance project and stores like the Isabel Hospice WooCommerce website, where checkout matters most. If your audit turns up custom code or an abandoned plugin that needs rewriting, you can hire a PHP developer for the upgrade and code fixes rather than replacing half your plugins. For broader site work, see WordPress development and maintenance.
Frequently asked questions
Will my WordPress site stop working when PHP 8.2 reaches end of life?
No. It keeps running on 1 January 2027 but receives no PHP security fixes, and your host may change the version for you. Upgrade on a day you choose.
Can I jump straight from PHP 8.2 to PHP 8.4?
Yes. You do not need to go through 8.3 first. Test 8.4 on staging; if one plugin fails, 8.3 can be a short-term fallback while you replace or fix it.
Is it safe to upgrade PHP right before Black Friday?
Only if you have tested on staging and switched live early enough to see a couple of weeks of normal orders. Avoid changing PHP in the week before 27 November and during the sale itself.
How do I know if a plugin is compatible with the new PHP version?
Check its changelog for the PHP version and recent updates, then test on staging with error logging on. A clean log after real use is the best evidence.
If you want someone to check your plugin list and staging results before you switch, send me your site URL and current PHP version and I will tell you what I would look at first.
