How to check your PHP version and update it safely

PHP tends to get updated rarely and reluctantly: the site works, so why touch it. But every PHP branch receives security fixes for a limited time only, and critical vulnerabilities such as PHP2Shell in October 2026 show that sometimes the update has to happen the same day. Here is a step-by-step guide to finding out which PHP version actually serves your site and moving to a new one without breaking anything.

Which PHP versions are supported now

Each PHP branch gets two years of active support followed by two years of security fixes only. According to php.net, as of October 2026:

• PHP 8.5: active support until December 31, 2027, security fixes until December 31, 2029.
• PHP 8.4: active support until December 31, 2026, security fixes until December 31, 2028.
• PHP 8.3: security fixes only, until December 31, 2027.
• PHP 8.2: security fixes only, until December 31, 2026. In two months the branch stops receiving fixes.
• PHP 8.1 and older: end of life (8.1 on December 31, 2025). The PHP project no longer ships fixes for them.

If you are on 8.2 or older, start planning the upgrade now. For new projects, 8.4 or 8.5 is the sensible choice, as long as your platform supports it.

Step 1. Check the version the right way

The most common mistake is running php -v in a terminal and assuming the site runs on that version. A server can have several PHP versions installed at once, and the command-line PHP (CLI) often differs from the one handling web requests (PHP-FPM or the Apache module). Check both.

• Command line: php -v shows the CLI version. That is what runs cron jobs, queues, composer, bin/magento and artisan.
• Web server: temporarily put a file containing <?php phpinfo(); with a random name in the site root, open it in a browser and look at PHP Version and Server API. Delete the file right after: phpinfo exposes paths, modules and server settings.
• Installed versions on Debian and Ubuntu: ls /etc/php/; running FPM pools: systemctl list-units 'php*-fpm*'.

Without server access, the platform itself can tell you:

• WordPress: Tools → Site Health → Info → Server.
• Laravel: php artisan about prints the PHP version and environment.
• Magento: bin/magento --version shows the Magento version; for the web server's PHP version use phpinfo or your hosting panel.
• cPanel and Plesk: the PHP version is set per site, in MultiPHP Manager (cPanel) or in the domain's PHP settings (Plesk).

Step 2. Find out how PHP is wired in

The Server API line in phpinfo shows the mode: FPM/FastCGI means a separate PHP-FPM service that nginx or Apache talks to; Apache 2.0 Handler means mod_php, with PHP running inside Apache processes. The mode determines what you switch and what you restart. mod_php is a legacy setup, so moving to a new version is a good moment to switch to PHP-FPM as well.

Step 3. Check compatibility

The new PHP version has to suit your platform and every module:

• Magento: according to Adobe's requirements, 2.4.9 runs on PHP 8.5, 2.4.8 on 8.4 and 8.3, 2.4.7 on 8.3 and 8.2. Sometimes you need to upgrade Magento first and PHP second.
• WordPress recommends PHP 8.3 or newer. Check your theme and plugins separately: problems usually come from them, not from core.
• Laravel 12 supports PHP 8.2–8.5; Laravel 11 goes up to 8.4 and has received no security fixes since March 2026.
• Composer dependencies: composer why-not php 8.4 lists the packages that block the new version.
• PHP extensions: save the output of php -m, because the new version needs the same modules (intl, gd, soap, bcmath, redis, imagick and so on).

Step 4. Prepare

1. Back up the files and the database.
2. Save the current settings: php.ini, FPM pools (on Debian and Ubuntu, /etc/php/8.2/fpm/pool.d/) and the web server configuration.
3. Run the upgrade on a staging copy of the site first: catalog, cart, checkout, admin login, outgoing email, imports and cron.
4. Turn on logging of errors and deprecation warnings: they tell you what to fix in the code.

Step 5. Upgrade

The easiest approach is to install the new version alongside the old one, so switching and rolling back take minutes.

• Ubuntu: current PHP builds come from Ondřej Surý's repository: sudo add-apt-repository ppa:ondrej/php, then sudo apt install php8.4-fpm php8.4-cli plus the extensions you need, for example php8.4-mysql php8.4-intl php8.4-gd php8.4-xml php8.4-mbstring php8.4-curl php8.4-zip. For Debian, the same maintainer runs packages.sury.org.
• RHEL, AlmaLinux, Rocky: the Remi repository. Install remi-release for your OS version, then dnf module reset php and dnf module enable php:remi-8.4, followed by dnf update. To keep two versions side by side, Remi also ships separate packages such as php84.
• Docker: change the base image, for example FROM php:8.2-fpm to FROM php:8.4-fpm, and rebuild the extensions. Even when the version stays the same, rebuild with --pull: tags like 8.4-fpm move with every patch release, and that is the only way to pick up security fixes.
• Hosting panels: in cPanel and Plesk you choose the version per site in the PHP settings. Switch a staging subdomain first.

Step 6. Switch the site over

1. Carry your values over from the old php.ini and FPM pool to the new ones: memory_limit, max_execution_time, upload_max_filesize, OPcache settings and the pool user.
2. nginx: change the socket in fastcgi_pass, for example to unix:/run/php/php8.4-fpm.sock, check the configuration with nginx -t and reload nginx.
3. Apache with FPM: a2disconf php8.2-fpm, a2enconf php8.4-fpm, then systemctl reload apache2. If you were on mod_php, a2dismod php8.2 and a2enmod php8.4, though this is a good moment to move to FPM.
4. CLI: on Debian and Ubuntu, update-alternatives --set php /usr/bin/php8.4. Don't forget cron, queues and supervisor, which often hard-code the full path to the old binary.
5. Restart every PHP process: systemctl restart php8.4-fpm, queue workers (php artisan queue:restart, Magento consumers), and clear the application caches.

Step 7. Verify

• Open a temporary phpinfo again (and delete it): the version and Server API should be the new ones.
• Walk through the key flows: home page, search, product page, cart, payment, customer account, admin.
• Watch the PHP-FPM, web server and application logs for the first few hours: fatal errors and deprecation warnings on rarely visited pages don't show up right away.
• Check that cron and queues have run on the new version.

If something goes wrong

As long as the old version is still installed alongside, rolling back is simple: restore the old socket in nginx or the Apache configuration, switch update-alternatives back and restart the services. With Docker, redeploy the previous image. Changing the PHP version does not touch the database by itself, so a rollback usually takes minutes. Remove the old version only after a few quiet days, and keep in mind that leaving it around for long is a security risk.

When to update

Patch releases within a branch (say 8.4.26 to 8.4.27) carry bug and security fixes and should go in right away. Moving to a new branch (8.2 to 8.4) is worth planning ahead, before support ends. And when a critical fix lands, as with PHP2Shell, updating the same day beats any plan.

We have been working with PHP, Magento, Laravel and WordPress for more than ten years. We will check which PHP version runs on your servers and how, update it on a staging copy, roll it out to production with a rollback plan, and move older projects to a supported version.

Sources: PHP supported versions, unsupported PHP branches, Adobe Commerce system requirements, WordPress requirements, Laravel support policy, ondrej/php PPA, Sury repository for Debian, Remi repository, official PHP image on Docker Hub.