Nobody wakes up excited to check their PHP version. Then a host sends a warning that 8.1 is past end of life, or a plugin update refuses to install, or a security scan flags "unsupported runtime." Suddenly that number in the control panel matters.
PHP end of life (EOL) means the version no longer gets security fixes. Your site might still load. It is just running on software nobody is patching when the next vulnerability shows up.
What EOL actually means for your site
When a PHP branch hits EOL:
- No more security updates from the PHP project for that version
- Hosts may force an upgrade on a deadline or move you to a newer default
- Plugin and theme authors drop support for old versions over time
- Compliance scans (PCI, insurance questionnaires) start flagging it
The site does not explode on EOL day. Risk accumulates quietly. Old PHP is how WordPress installs become compromise targets long after the core team shipped a fix you cannot run because your runtime is too old.
How to see what you are running
Quick checks:
- cPanel or Plesk: PHP version selector or MultiPHP screen
- WordPress: Site Health under Tools (shows PHP version if your install is current enough)
- A simple
phpinfo()file on staging (delete it after) - Ask your host if you are on managed hosting and do not have panel access
Write down the version and the EOL date from php.net supported versions. If you are one major version behind, plan an upgrade window. If you are two behind, treat it as urgent.
WordPress and the plugin pile
WordPress core usually supports several PHP versions at once, but your stack is core plus themes plus plugins. That is where upgrades get stuck.
Before you bump PHP on production:
- Update WordPress core, themes, and plugins on staging first
- Switch PHP version on staging and click through checkout, forms, admin, cron-heavy plugins
- Check error logs for deprecation notices (PHP 8.x is stricter than 7.x was)
- Identify plugins that have not been updated in years. They are often the blocker.
Custom code in your theme's functions.php may need small fixes for PHP 8 compatibility. Deprecation warnings today become hard failures on the next PHP minor.
Common upgrade paths we see
- 7.4 to 8.1+. The big jump. Many sites need plugin replacements and theme updates. Budget time, not an afternoon.
- 8.1 to 8.2 or 8.3. Usually smoother if plugins are maintained. Still test WooCommerce and membership plugins carefully.
- Staying put. Some hosts let you run EOL PHP on legacy plans. You are accepting unpatched security exposure. We do not recommend it for anything public-facing.
Managed WordPress hosting should include a tested upgrade path. If your host says "just change the dropdown," without offering rollback or logs review, be cautious on a store or membership site.
What your host should do
On a managed environment, you should expect:
- Notice before default PHP changes on the server
- Per-site or per-account PHP version control
- Backup before upgrade
- Help reading error logs if white screen after bump
- A documented rollback if the new version breaks a critical plugin
Swift Host tracks PHP versions per environment and schedules upgrades with clients who run WooCommerce, membership sites, or custom plugins. Our WordPress hosting page covers how we handle updates and compatibility testing on Canadian infrastructure.
Do not ignore deprecation notices
Yellow warnings in Site Health or deprecation lines in logs are not decoration. They tell you what will break on the next version bump. Fix or replace the plugin causing them before EOL forces your hand during a busy week.
Bottom line
PHP EOL is a deadline for security, not a suggestion. Check your version, test on staging, upgrade while you choose the timing, and replace abandoned plugins that anchor you to the past.
Not sure if your WordPress stack is ready for PHP 8.3? Talk with Swift Host. We will check your versions, flag risky plugins, and plan an upgrade without taking the store offline at the wrong moment.
