PHP Selector in user panel NOT work after latest CWP updates and recompile PhP 8

Hi;

I'm update CWP to latest version (1.21) I use Almalinux 9
I have php 7.4 FPM. and I have before PHP 8.3.31 FPM. I'm delete PHP 8.3.31 FPM and reconpile as PHP 8.3.36 FPM
But now all websites not work (Service Unavailable.The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.)

I try select PHP FPM from user panel but Available Php versions field always empty and loading icon running don't stop

Reboot server: NOT WORK
Recompile php 8.3.36: NOT WORK

I enabled access to the sites by creating new custom configuration files for each one via the "Manage WebServers Configuration" page; however, the PHP selector in the CWP user panel is still not working.

I  can confirm this. It appears to be a bug related to the php version upgrade:

Code: [Select]

2026/10/26 17:37:55 [error] 361408#0: *9 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught TypeError: Unsupported operand types: string / int in /usr/local/cwpsrv/var/services/user_files/modules/phpselector/index.php:0
Stack trace:
#0 /usr/local/cwpsrv/var/services/user_files/modules/phpselector/index.php(0): PHPSelector->changeDomain()
#1 /usr/local/cwpsrv/var/services/user_files/modules/phpselector/index.php(0): PHPSelector->router()
#2 /usr/local/cwpsrv/var/services/user_files/modules/phpselector.php(0): PHPSelector->__construct()
#3 /usr/local/cwpsrv/var/services/users/index.php(0): include('...')
#4 {main}


FIX  Quick and Dirty



# 1. Backup
mysqldump root_cwp packages > /root/packages_backup_$(date +%F_%H%M).sql

# 2. Fix undefined values
mysql -e "use root_cwp; update packages set cgroups='default' where cgroups='undefined';"

# 3. Verify
mysql -t -e "use root_cwp; select id,package_name,cgroups from packages;"

ionCube loader mismatch after a CWP PHP rebuild

After rebuilding the system PHP (/usr/local/bin/php), CWP installs the new engine but regenerates /usr/local/php/php.d/ioncube.ini pointing at the 8.2 loader regardless of the version it just built. On an 8.3 engine the loader refuses to initialize and php -v returns an empty string (while php -n -v prints the version normally).

That empty string breaks the panel: the PHP Version Switcher shows a blank "currently running PHP version" box and the version dropdown falls back to the first catalog entry (5.3.29). The client-area PHP Selector then divides that empty value and dies with Uncaught TypeError: Unsupported operand types: string / int in PHPSelector->changeDomain(), so every save returns HTTP 500 with a 5-byte body — which looks like a hung page, not an error.

Fix — point the loaders at the engine actually installed, and drop extensions that have no build for it:

sed -i 's|ioncube_loader_lin_8.2.so|ioncube_loader_lin_8.3.so|' /usr/local/php/php.d/ioncube.ini
# only if SourceGuardian is declared:
cp -p /usr/local/src/sgloaders/ixed.8.3.lin /usr/local/sourceguardian/
sed -i 's|ixed.8.2.lin|ixed.8.3.lin|' /usr/local/php/php.d/sourceguardian.ini
# extensions with no .so for the new API (oauth) or built against the old one (uploadprogress):
sed -i -E 's/^extension=(imagick|oauth)\.so/;&/' /usr/local/bin/php.ini
mv /usr/local/php/php.d/uploadprogress.ini /usr/local/php/php.d/uploadprogress.ini.disabled

# verify — must print the version and report zero warnings:
php -v | head -1
php -r 'echo 1;' 2>&1 | grep -cE 'Warning|Error|Cannot|requires'   # expect 0

The goal is zero output noise: any warning printed before the version string reproduces the same failure, since the panel parses that output. Reproduced independently on two servers (AlmaLinux 8.10, CWP 1.26, panel on PHP 8.3.36). Note that every future rebuild rewrites those .ini files back to 8.2, so they need rechecking after each one.

ionCube loader mismatch after a CWP PHP rebuild

After rebuilding the system PHP (/usr/local/bin/php), CWP installs the new engine but regenerates /usr/local/php/php.d/ioncube.ini pointing at the 8.2 loader regardless of the version it just built. On an 8.3 engine the loader refuses to initialize and php -v returns an empty string (while php -n -v prints the version normally).

That empty string breaks the panel: the PHP Version Switcher shows a blank "currently running PHP version" box and the version dropdown falls back to the first catalog entry (5.3.29). The client-area PHP Selector then divides that empty value and dies with Uncaught TypeError: Unsupported operand types: string / int in PHPSelector->changeDomain(), so every save returns HTTP 500 with a 5-byte body — which looks like a hung page, not an error.

Fix — point the loaders at the engine actually installed, and drop extensions that have no build for it:

sed -i 's|ioncube_loader_lin_8.2.so|ioncube_loader_lin_8.3.so|' /usr/local/php/php.d/ioncube.ini
# only if SourceGuardian is declared:
cp -p /usr/local/src/sgloaders/ixed.8.3.lin /usr/local/sourceguardian/
sed -i 's|ixed.8.2.lin|ixed.8.3.lin|' /usr/local/php/php.d/sourceguardian.ini
# extensions with no .so for the new API (oauth) or built against the old one (uploadprogress):
sed -i -E 's/^extension=(imagick|oauth)\.so/;&/' /usr/local/bin/php.ini
mv /usr/local/php/php.d/uploadprogress.ini /usr/local/php/php.d/uploadprogress.ini.disabled

# verify — must print the version and report zero warnings:
php -v | head -1
php -r 'echo 1;' 2>&1 | grep -cE 'Warning|Error|Cannot|requires'   # expect 0

The goal is zero output noise: any warning printed before the version string reproduces the same failure, since the panel parses that output. Reproduced independently on two servers (AlmaLinux 8.10, CWP 1.26, panel on PHP 8.3.36). Note that every future rebuild rewrites those .ini files back to 8.2, so they need rechecking after each one.

I am experiencing the same issue as you. I have tried all the methods you attempted, and I encountered the exact same problems.

I am trying to migrate sites from CentOS 7—a transition I have successfully performed in the past—to AlmaLinux 9; however, the process that used to work no longer functions.

Beyond migration, it is also impossible to perform a manual restore using backups. As you noted, email addresses and the emails themselves are not being imported.