# MultiPHP Manager Bulk PHP Version Changes (cPanel 136+)

Source: https://srvscripts.com/guides/multiphp-manager-bulk-php-version/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

MultiPHP Manager has always let an administrator change the PHP version for one domain at a time, which is fine for a handful of sites and painful for a server with eight hundred. cPanel & WHM 136, released in April 2026, introduced bulk PHP version management: filter domains by their current version, select them all, and move them together. Combined with the consolidated PHP error logs that arrived in the same release, this makes version retirements a task of minutes rather than an afternoon. This guide covers the workflow in WHM and the equivalent on the command line.

In short: In WHM → Software → MultiPHP Manager on cPanel 136 or later, filter the domain list by the current PHP version, tick select-all, choose the target version from “Apply PHP Version” and confirm; every selected domain moves in one operation…

**Short answer:** In WHM → Software → MultiPHP Manager on cPanel 136 or later, filter the domain list by the current PHP version, tick select-all, choose the target version from “Apply PHP Version” and confirm; every selected domain moves in one operation with a single Apache and PHP-FPM restart. The scripted equivalent is `whmapi1 php_set_vhost_versions version=ea-php84 vhost=... vhost=...`, with the vhost list generated from `php_get_vhost_versions`.

## Audit before you move anything

Start with a picture of what runs where. In WHM → Software → MultiPHP Manager, the domain list has a filter by PHP version and a column showing whether each domain inherits the system default or has an explicit setting. Sort by version to see how many domains sit on each. The same data from the shell, summarised:

```
whmapi1 php_get_vhost_versions --output=json \
  | python3 -c 'import sys,json,collections; d=json.load(sys.stdin)["data"]["versions"]; print(collections.Counter(v["version"] for v in d))'
```

Note the distinction between domains that inherit and domains that are pinned. A domain that inherits will move automatically when you change the system default, whereas a pinned domain stays where it is. Bulk tools act on pinned settings; if most of your fleet inherits, the simpler move is to change the default.

Also check the PHP-FPM state and the handler for each version with `whmapi1 php_get_handlers`, because a bulk move to a version that has no FPM package installed will silently fall back to the non-FPM handler.

## Use the bulk tool in WHM

In MultiPHP Manager on 136 and later, filter the domain list to the source version, for example PHP 8.1. Tick the select-all checkbox at the top of the list, or select the specific domains you want. From the “Apply PHP Version” control above the list, choose the target version and confirm. The change applies to every selected domain, rewrites the Apache virtual host includes, and restarts Apache and PHP-FPM once at the end rather than once per domain.

A few practical notes. Filter first, then select all, so you do not accidentally include domains that were already on the target version. If a domain is set to inherit and you select it, the tool pins it to the target version, which changes its future behaviour; decide whether you want that. And the bulk operation does not check application compatibility, so the audit stage below matters.

The same release also lets you toggle PHP-FPM for multiple domains at once from the same list, and consolidates PHP error logs so that a failing site after the move is easy to find at `/var/log/apache2/` under the new unified log naming, or from WHM → Software → MultiPHP Manager → “View PHP error logs” on 138.

## Do the same from the shell

The `php_set_vhost_versions` function accepts multiple `vhost` parameters in a single call, which is the scripted equivalent of the bulk tool:

```
whmapi1 php_set_vhost_versions version=ea-php84 \
  vhost=one.example.com vhost=two.example.com vhost=three.example.com
```

To move every domain currently on 8.1 to 8.4, generate the list and pass it in:

```
VHOSTS=$(whmapi1 php_get_vhost_versions --output=json \
  | python3 -c 'import sys,json; d=json.load(sys.stdin)["data"]["versions"]; print(" ".join("vhost="+v["vhost"] for v in d if v["version"]=="ea-php81"))')
whmapi1 php_set_vhost_versions version=ea-php84 $VHOSTS
```

Run the first line on its own and inspect `$VHOSTS` before executing the second. For very large servers, split the list into batches of a hundred so a single Apache restart failure does not leave you unsure of what changed. To pin all inheriting domains to their current effective version before changing the default, loop over the list and set each explicitly first; this is the safe way to change the system default without moving sites that are not ready.

Switch PHP-FPM on for the target version at the same time:

```
whmapi1 php_set_default_accounts_to_fpm value=1
whmapi1 convert_all_domains_to_fpm
```

The second command queues a background job; check progress with `whmapi1 is_conversion_in_progress`.

## Test before and after

For a version retirement, pick a sample of sites on the source version and test them on the target with a temporary switch, then move them back. WordPress and most modern frameworks move from 8.1 to 8.4 without incident; older custom code trips on deprecations that became errors, dynamic property creation and changed function signatures being the usual culprits. Ask customers to check their own sites where you can, and tell them the date you will move everyone.

After the bulk change, tail the consolidated PHP error log for fatal errors:

```
grep -h 'PHP Fatal' /var/log/apache2/*php*log* 2>/dev/null | tail -n 40
```

Anything listed there needs the customer’s attention or a temporary move back to the previous version for that one domain.

## Verify

Confirm no domain is left on the source version and that Apache is serving cleanly:

```
whmapi1 php_get_vhost_versions | grep -c 'ea-php81'
/scripts/restartsrv_httpd --status
/scripts/restartsrv_apache_php_fpm --status
```

Load a handful of moved sites in a browser, and check that a `phpinfo()` page on one of them reports the expected version and the FPM server API.

## Common pitfall

The most common mistake is bulk-moving domains to a version that lacks an extension they use, usually ionCube Loader or Imagick, which is not yet available for `ea-php85` in every repository. Compare `php -m` output for the source and target versions before the move and install the missing packages from EasyApache 4 first; see [Installing and switching PHP versions in EasyApache 4](/guides/easyapache-4-php-versions-8-2-8-5/). The second mistake is changing the system default with hundreds of inheriting domains and no prior testing, which is a bulk move without the audit.

## MultiPHP Manager bulk PHP version at a glance

**Official documentation:** [cPanel & WHM documentation](https://docs.cpanel.net/), [Linux man pages](https://man7.org/linux/man-pages/).

**Related guides:** [What changed in cPanel 138: Meridian, Ask AI, Nova, MCP and domain rename](https://srvscripts.com/guides/what-changed-in-cpanel-138/) · [Install ImageMagick and PHP Imagick for EA-PHP on AlmaLinux 8/9/10 (and CloudLinux CageFS)](https://srvscripts.com/guides/install-imagick-ea-php-almalinux/) · [Managing web log retention and Apache log cleanup on cPanel (v136+)](https://srvscripts.com/guides/cpanel-apache-log-retention/).

## Frequently asked questions

### Does the bulk PHP version tool exist in cPanel versions before 136?

No. Earlier releases only change one domain at a time in MultiPHP Manager, although `whmapi1 php_set_vhost_versions` has accepted multiple `vhost` parameters for years, so the scripted approach works on older builds too.

### How long does a bulk PHP version change take on a large cPanel server?

The rewrite of virtual host includes is quick, and the tool restarts Apache and PHP-FPM once at the end, so a few hundred domains typically finish within a couple of minutes. Splitting the change into batches of about a hundred keeps a failed restart easy to trace.

### Can I move domains back to the old PHP version if a site breaks?

Yes. Select the affected domain in MultiPHP Manager, or run `whmapi1 php_set_vhost_versions version=ea-php81 vhost=site.example`, and it returns to the previous version immediately, provided that version is still installed in EasyApache 4.