PHP Versions in cPanel: How to Choose and Switch

Choosing a PHP version is critical for CMS compatibility and performance. Different projects need different versions: what is optimal for a brand-new Laravel application can completely break a five-year-old site built on a custom engine.

How to choose a PHP version for a project

"Minimum version" is the threshold below which the framework or CMS formally will not run or will refuse installation. "Recommended" is the version with the best balance of speed and plugin compatibility at the time of writing; for a specific site, check the requirements of the plugins you actually use separately. If the server's PHP version is below the minimum, a modern Laravel project will not even start installing dependencies — Composer stops immediately with a clear message:

Problem 1
  - Root composer.json requires php ^8.2 but your php version (7.4.33) does not
    satisfy that requirement.

This is not a project configuration mistake but a direct framework requirement — the only fix is switching the server's PHP version, not editing composer.json to bypass the check.

Switching the PHP version in cPanel

1. cPanel → Software → Select PHP Version
2. Pick a version (we recommend PHP 8.2)
3. Click Set as current
4. Check plugin/theme compatibility

Different PHP versions for different domains

cPanel lets you assign a separate PHP version to each domain or folder:

1. cPanel → MultiPHP Manager
2. Select the domain → specify the version

Typical error when moving to a newer version

Starting with PHP 8.1, passing null into a function parameter that is not declared nullable began issuing a deprecation warning, and in many built-in functions on PHP 8.2+ it now raises a fatal error:

Fatal error: Uncaught TypeError: trim(): Argument #1 ($string) must be of type
string, null given, called in /home/user/public_html/wp-content/plugins/old/init.php
on line 34

This is one of the most common reasons old WordPress plugins break specifically on PHP 8.2 and not earlier: the code had spent years passing the result of a database lookup that could occasionally be null into trim(), strlen(), or htmlspecialchars(), and PHP used to silently coerce it into an empty string. The fix is to update the plugin to a version where the author added an explicit null check before calling the function.

Configuring PHP extensions

cPanel → Select PHP Version → Extensions:

• For WordPress: mysqli, gd, curl, mbstring, xml, zip
• For Laravel: pdo_mysql, bcmath, tokenizer, fileinfo
• For online stores (WooCommerce, PrestaShop): also intl and soap for shipping services and currency handling
• For API integrations: curl and openssl are mandatory for HTTPS requests to external services

Configuring php.ini through cPanel

# cPanel → PHP Settings (or create .htaccess):
php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value memory_limit 256M

Changes made through the PHP Settings panel in cPanel apply instantly, but when using a .user.ini file as an alternative, remember the caching delay — new directive values are not picked up right away, but with a delay of up to five minutes controlled by the user_ini.cache_ttl setting.

When not to jump to the newest version right away

• The site uses plugins that have not been updated in over two years — the risk of fatal errors is high, and the author may no longer maintain the code
• There is no test copy of the site — switching the version of a live store or high-traffic site without a staging check is risky
• Custom code makes direct calls to removed functions (each(), create_function(), ${} inside strings) — these are physically removed in PHP 8.x, and no version setting will fix that, only a refactor will
• The hosting provider has not yet updated server modules (for example, the ionCube Loader) for the new PHP version — then licensed, encoded scripts will simply stop running

Checking the current version

# Over SSH:
php -v

# Or create phpinfo.php:
<?php phpinfo(); ?>
# Delete the file after checking!

PHP 7.4 has received no security updates since December 2022 — known vulnerabilities on that version will never be patched, and the hosting provider bears no responsibility for the consequences. Even if a site on PHP 7.4 currently runs without visible problems, that is not a sign of safety — it is a sign that a vulnerability has not yet been found and exploited against that particular server. More on errors after a version change and working with error_log is in the article reading error logs in cPanel, and on the PHP Selector mechanism itself in cPanel PHP Selector.