Changing the PHP Version in cPanel: MultiPHP Manager

ZevsHost hosting offers PHP 7.4, 8.0, 8.1, 8.2, and 8.3. You can pick a version for each domain independently through MultiPHP Manager, and then configure specific php.ini directives in three different ways — and which way you pick determines whether the setting takes effect at all.

Changing the PHP version

cPanel → Software → MultiPHP Manager. Check the box next to the domain → pick a PHP version → Apply. WordPress 6.x requires PHP 7.4+ and recommends 8.1 or 8.2 for better performance.

Configuring php.ini via MultiPHP INI Editor

cPanel → Software → MultiPHP INI Editor → select the domain.

Which method takes priority

Most modern cPanel servers use PHP-FPM by default rather than mod_php — this means php_value directives in .htaccess are simply and silently ignored when the server runs FPM, and editing .htaccess has no effect at all, without any explicit error. MultiPHP INI Editor always works because it edits the actual php.ini file for the selected handler instead of trying to override it from above.

Common error: the setting had no effect

If, after a PHP version change, an old .htaccess still references a handler that no longer exists, Apache returns a 500 with this error_log entry:

[php:error] [pid 4521] AH01071: Got error 'Primary script unknown'
while reading response header from upstream, referer: https://example.com/

This means a line like AddHandler application/x-httpd-php82 .php points to a handler that does not exist under that name on the server — for example, if the version is actually named ea-php82 rather than plain php82. The fix is to remove the outdated AddHandler directive from .htaccess and manage the version only through MultiPHP Manager.

The second common trap is trying to change a PHP_INI_SYSTEM-level directive (for example, disable_functions or open_basedir) through .htaccess or .user.ini. Directives at that level can only be changed in the server's main php.ini or through MultiPHP INI Editor — trying through .htaccess does not cause a 500 error, the value simply stays unchanged with no warning at all. Debugging cases like this takes the most time precisely because there is no error message — the only way to confirm the directive's real value is to open phpinfo() again and check the Local Value line for that setting.

Configuring via .htaccess (alternative)

# Set the PHP version for a folder
<IfModule mime_module>
    AddHandler application/x-httpd-php82 .php
</IfModule>

# Or via php_value
php_value memory_limit 256M
php_value max_execution_time 60
php_value upload_max_filesize 64M

Configuring via .user.ini

# Create a .user.ini file in the site's root
memory_limit = 256M
max_execution_time = 60
upload_max_filesize = 64M
post_max_size = 64M
max_input_vars = 3000

When MultiPHP Manager does not fit

• You need a different PHP version for two subdirectories of the same domain rather than for the whole domain — MultiPHP Manager switches the version at the domain level, fine-grained control needs .user.ini in the specific folder
• The command-line PHP version (SSH, cron) differs from the site's version — MultiPHP Manager only manages the web PHP-FPM handler, and php -v in the terminal can show the system's default version unless a path like /usr/local/bin/ea-php82 is given explicitly
• You need to change a PHP_INI_SYSTEM-level directive (disable_functions, open_basedir) for a single site — only the server administrator can do that in the main php.ini, a cPanel account has no such access
• You need a PHP version that is not in the MultiPHP Manager list — the list of versions is built by the server administrator through WHM EasyApache, you cannot add your own version from cPanel

Checking the current PHP version

<?php phpinfo(); ?>
// Save as info.php, open it, delete it after checking!

# Over SSH, the CLI version can differ from the site's version:
php -v

If the version shown in the browser (via phpinfo) and the version in the terminal (via php -v) do not match, that is normal for cPanel: the web version is managed by MultiPHP Manager separately from the system's default PHP CLI version. For running cron scripts, use the full path to the specific PHP binary rather than just the php command. More on diagnosing issues after a version change is in the article reading error logs in cPanel, and on the PHP Selector mechanism itself in cPanel PHP Selector.