A single hosting account often holds several websites: the main company site, an old promo page, a blog and a staging copy. They were built in different years by different developers, and each has its own PHP requirements. If the whole account is forced onto one PHP version, keeping the old site alive means holding the new one back too. Choosing the PHP version per site solves exactly that.
Why sites need different PHP versions
PHP ships a new major release every year, removing some old functions and adding new syntax. A custom CMS written a few years ago may run fine on PHP 7.4 but crash on 8.x because it calls removed functions. A new Laravel project or recent WordPress plugins, on the other hand, may require PHP 8.2 or later. Forcing both onto one version breaks one of them.
Security and speed matter too. Newer PHP versions are usually faster and still receive security fixes, so with a single shared version the oldest site drags the whole account behind. Per-site versions let you move new sites to modern PHP while the old one stays on its version until it is upgraded.
Where to choose the version in ISPmanager
sayt.uz hosting uses the ISPmanager panel, which you open directly from the hosting page of your sayt.uz cabinet. Open the site in the WWW-domains list for editing, and the PHP section shows the handler mode and version. Once you pick a version and save, only that site is affected. Menu names can vary slightly by panel version and plan; if the version you need is missing or the field is greyed out, open a support ticket from the cabinet to check what is available.
The handler mode matters as well. Typical options are Apache module, CGI and FastCGI (PHP-FPM). Alternative versions are usually offered only in CGI or FastCGI mode, because the Apache module can run a single version per server. PHP-FPM gives each site its own process pool and is usually the most stable choice.
Example: three sites of one Tashkent company
Imagine a building-materials store in Tashkent with three sites on one account. The main site example.uz was custom-coded in 2019 and currently runs reliably only on PHP 7.4. The new online store shop.example.uz is built on WooCommerce and needs PHP 8.3. The blog blog.example.uz is plain WordPress and is happy on 8.2 or 8.3. The right move is 7.4 for the main site for now and 8.3 for the other two, plus a concrete plan to upgrade the main site, since 7.4 no longer receives security fixes. A per-site version buys time; it is not a permanent fix.
Checking the version, cron and the command line
After switching, confirm which version the site actually runs with a temporary file, and delete it right after checking because it exposes server details.
<?php
echo PHP_VERSION;Keep in mind that the version selected in the panel applies to web requests only. Running php over SSH or from a cron job may use the server default, so the site runs on 8.3 while the cron script runs on something else and fails. Always call the full path of the intended binary.
# Default version
php -v
# Alternative version by full path (path depends on the server)
/opt/php83/bin/php -v
# Cron example: run a script with PHP 8.3 every 15 minutes
*/15 * * * * /opt/php83/bin/php /var/www/user/data/www/shop.example.uz/cron.phpOn ISPmanager servers alternative versions usually live in paths like /opt/php83/bin/php, but check with ls /opt or ask support if unsure. The same applies to Composer: run it with the same PHP version the site uses.
Before switching, and how to roll back
- Back up the site files and the database.
- Check that your CMS, theme and plugins support the target version.
- Test on a staging copy first if you can.
- Switch during low traffic and then test key pages, forms, the cart and the admin area.
Extensions are configured per version, so intl, imagick or ionCube enabled on the old version may be missing on the new one; settings such as memory_limit may also need to be set again. If the site shows a blank page or a 500 error after the switch, simply select the previous version and save, and it usually recovers within seconds. Then read the error log in the panel or in your account's logs folder: Fatal error lines name the exact file and function. If you get stuck, send that error text to support.