Back to blog

How to change the PHP version in cPanel: move to PHP 8.3, 8.4 or 8.5 without breaking your site

Published on October 19, 2026 by Admin
Code PHP d'un fichier de configuration affiché dans un éditeur sur fond sombre

PHP 8.1 has not received a single security fix since January 1, 2026, and PHP 8.2 follows on December 31, 2026. If your site still runs on either of them, it is time to change the PHP version in cPanel. This guide helps you choose between PHP 8.3, 8.4 and 8.5, test the new version on a copy of your site, and then switch the live site with a one-click rollback available.

Why upgrade PHP now

PHP follows a fixed lifecycle: each branch gets two years of bug fixes (active support), then two years of security fixes only. After that, newly discovered vulnerabilities are no longer patched. A WordPress or PrestaShop site left on an end-of-life version is exposed to known, publicly documented flaws.

There is a practical side too. Recent plugins and themes gradually drop old PHP versions, and each new branch brings performance gains. Staying behind eventually blocks updates to your CMS itself.

The official PHP release calendar

These dates come from the PHP project on php.net ("Supported Versions" and "Unsupported Branches" pages), checked in October 2026:

VersionReleasedActive support endsSecurity support endsStatus in October 2026
PHP 8.1November 2021November 25, 2023December 31, 2025End of life (last release: 8.1.34)
PHP 8.2December 8, 2022December 31, 2024December 31, 2026Security only, a few weeks left
PHP 8.3November 23, 2023December 31, 2025December 31, 2027Security only
PHP 8.4November 21, 2024December 31, 2026December 31, 2028Active support
PHP 8.5November 20, 2025December 31, 2027December 31, 2029Active support

In practice, PHP 8.4 is the best trade-off today: it is covered until the end of 2028 and widely supported by CMSs and plugins. PHP 8.5 buys you one more year, as long as your whole stack supports it. PHP 8.3 is an acceptable stepping stone if one plugin holds you back, but it reaches end of life at the end of 2027.

Which version to pick for your CMS

WordPress

According to the official WordPress handbook ("PHP Compatibility and WordPress Versions"), WordPress 6.9 and later support PHP 8.5, and PHP 8.4 has been supported since WordPress 6.7. The "beta support" label WordPress used for these versions was retired in May 2026. Since WordPress 7.0, the minimum required PHP version is 7.4.

WordPress core is only half the story, though: plugins and themes are what usually break during a PHP upgrade. Check the "Requires PHP" field and the last-updated date of every plugin. A plugin that has not been updated in two years is a risk.

PrestaShop

The official PrestaShop documentation publishes a precise compatibility chart:

PrestaShopPHP 8.1PHP 8.2PHP 8.3PHP 8.4PHP 8.5
8.0 to 8.2RecommendedNot supportedNot supportedNot supportedNot supported
9.0YesYesYesRecommendedNot supported
9.1YesYesYesYesRecommended

The key takeaway: a PrestaShop 8 store is stuck on PHP 8.1, which no longer receives fixes. The way out is to migrate the store to PrestaShop 9 first, then change the PHP version. Doing it the other way round (PHP 8.3 on PrestaShop 8) almost always ends in errors. PrestaShop 9 also needs several PHP extensions (intl, gd, zip, curl, mbstring, fileinfo and others) and recommends a memory_limit of at least 512M.

What can break when moving to PHP 8.4 or 8.5

Changes between PHP 8 minor versions are mostly deprecations: the code still runs but writes warnings to the logs. Real outages usually come from old modules or missing PHP extensions. These are the deprecations that most often hit WordPress plugins and PrestaShop modules:

  • PHP 8.4: implicitly nullable parameters (function f(Type $a = null) must become ?Type $a = null), using E_USER_ERROR with trigger_error(), the E_STRICT constant, and calling fgetcsv() or fputcsv() without passing the escape parameter.
  • PHP 8.5: non-canonical casts such as (integer) or (boolean), the backtick operator that runs a shell command, using null as an array key, the $http_response_header variable, and some MySQL-specific PDO constants in favour of their Pdo\Mysql equivalents.

Yet the most common cause of a blank page or a 500 error right after a switch is a missing PHP extension in the new version: each PHP version installed on the server has its own set of extensions. If intl or imagick is enabled for PHP 8.2 but not for PHP 8.4, your CMS will fail on 8.4.

Step 1: take stock before touching anything

  1. Write down the current PHP version of each domain. It is shown in cPanel's MultiPHP Manager (Software section).
  2. Update your CMS, theme and every plugin or module before changing the PHP version. Updates often fix the incompatibilities.
  3. Take a full backup of files and database. cPanel's Backup tool (or Backup Wizard) lets you download an archive of your home directory and an export of each MySQL database.
  4. Spot abandoned plugins and look for maintained alternatives.

Step 2: test the new version on a copy of the site

This is the step most tutorials skip. MultiPHP Manager sets the PHP version per domain and per subdomain, so you can run a copy of your site on PHP 8.4 while the main site stays on its current version.

  1. Create a test subdomain such as test.yoursite.com from cPanel's Domains interface, with its own document root.
  2. Copy the site: for WordPress, Softaculous's staging feature does it in a few clicks if your host offers it. Otherwise, copy the files with File Manager (compress, move, extract) and duplicate the database with phpMyAdmin (export, then import into a new database).
  3. Adjust the copy's configuration: database name in wp-config.php (WordPress) or app/config/parameters.php (PrestaShop), then the site address (siteurl and home options in WordPress, shop URL in the ps_shop_url table in PrestaShop).
  4. Protect the copy with cPanel's Directory Privacy tool (password) so it is neither indexed nor public.
  5. Switch only the test subdomain to the new PHP version in MultiPHP Manager.

Then turn on error logging on the copy. For WordPress, in wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );     // writes to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // shows nothing to visitors

For PrestaShop, enable debug mode under Advanced Parameters > Performance. Then walk through the key pages: home, product page, cart, checkout in test mode, contact form, admin login, sending an email. Read debug.log, the error_log files in the site folders and cPanel's Errors tool. A "Deprecated" line is not a blocker; a "Fatal error" line is.

Step 3: change the PHP version in cPanel

Once the copy checks out, switching the live site takes less than a minute:

  1. Log in to cPanel and open MultiPHP Manager in the Software section.
  2. Tick the checkbox of the domain you want to change (you can tick several).
  3. Pick the version from the PHP Version menu at the top right. Versions are listed as PHP 8.4 (ea-php84); those labelled "Recommended" are suggested by the server administrator.
  4. Click Apply. The domain's version column updates immediately.

Under the hood, cPanel adds a block to the .htaccess file at the domain's root. Do not edit it by hand, cPanel rewrites it:

# php -- BEGIN cPanel-generated handler, do not edit
# Set the "ea-php84" package as the default "PHP" programming language.
<IfModule mime_module>
  AddHandler application/x-httpd-ea-php84 .php .php8 .phtml
</IfModule>
# php -- END cPanel-generated handler, do not edit

If a domain shows "Inherited", it uses the server's default version, chosen by your host, which can change without any action on your part. It is safer to set each site's version explicitly.

To confirm the version actually in use, drop a temporary file with a hard-to-guess name in the site root, open it in your browser, then delete it:

<?php echo PHP_VERSION;

If the version you want is not listed

A version missing from the menu is either not installed on the server or not available to your account. It is installed server-side through EasyApache 4, so you cannot add it yourself from cPanel: contact your host's support. Some hosts also offer a "Select PHP Version" tool, which lets you switch versions and turn PHP extensions on or off yourself.

Step 4: check your PHP settings after the switch

Each PHP version has its own default configuration. After the change, open MultiPHP INI Editor (right next to MultiPHP Manager), select your domain and check at least:

  • memory_limit: 256M for WordPress with a page builder, at least 512M for PrestaShop 9;
  • upload_max_filesize and post_max_size: adjust to the size of your media;
  • max_execution_time: raise it if product imports or backups time out;
  • display_errors: off in production.

Finally, clear every cache: your WordPress caching plugin, PrestaShop's Smarty and Symfony cache (Advanced Parameters > Performance > Clear cache), and your CDN cache if you use one.

Rolling back if something goes wrong

Changing the PHP version does not touch your files or your database. If a problem shows up, go back to MultiPHP Manager, tick the domain, select the previous version and click Apply: the site is back to its earlier state within seconds. Keep one deadline in mind, though: rolling back to PHP 8.2 only gives you until December 31, 2026 to fix the issue.

FAQ

Can changing the PHP version delete my site?

No. MultiPHP Manager only changes the interpreter that runs your files. Content, files and database stay intact, and rolling back is instant.

Can each site use a different PHP version?

Yes. MultiPHP Manager works domain by domain: a WordPress blog can run PHP 8.5 and a PrestaShop 9.0 store PHP 8.4 on the same cPanel account. Parked domains (aliases) follow their main domain.

My site shows a 500 error after the switch. What now?

First roll back to the previous version to restore the site. Then check cPanel's Errors tool or the error_log file: the cause is almost always a PHP extension missing from the new version or an incompatible module. Fix it on the test copy before trying again.

PHP 8.5 or PHP 8.4?

If your site runs an up-to-date WordPress or PrestaShop 9.1 and all your plugins support it, PHP 8.5 gives you the most headroom (security fixes until the end of 2029). For PrestaShop 9.0, or if an important plugin does not yet state compatibility, choose PHP 8.4.