Coexistence and Switching of Multiple PHP Versions: Panel vs. CLI Are Separate

It is common to have multiple PHP versions installed on a server: older sites may require 7.4, while new ones need 8.2. However, the PHP version shown in the control panel and the PHP version in the command line are two different things—this is the most confusing aspect for many users.

Typical confusion: The panel shows that the site is using PHP 8.1, but running php -v in the command line returns 7.4. Dependencies installed via Composer are incorrect, and script execution behaves differently than expected.

The Two PHP Environments Are Independent

Switching the site version in the panel only affects web access, not the command line. The reverse is also true.

First, Check How Many Versions You Have Installed

# Check which version is currently used in the command line
php -v
which php

# List installed versions (Baota environment)
ls /www/server/php/

# Check if FPM processes for each version are running
ps aux | grep '[p]hp-fpm' | awk '{print $11}' | sort -u

# Check system-level symbolic links
ls -l /usr/bin/php

Switching via Command Line (System-Level)

# View registered candidate versions
update-alternatives --display php

# Interactive switching
update-alternatives --config php

# Or set directly (more explicit for scripts)
update-alternatives --set php /usr/bin/php8.2

# Verify
php -v

If a version is not registered in alternatives, you can add it manually:

update-alternatives --install /usr/bin/php php /www/server/php/82/bin/php 82
update-alternatives --install /usr/bin/php php /www/server/php/74/bin/php 74
update-alternatives --config php

Recommended: Don’t Change Global Settings; Use Specific Versions When Needed

A better practice is to leave global settings alone and use absolute paths in specific commands—this avoids affecting other system components that rely on the default PHP.

# Call directly using absolute paths
/www/server/php/82/bin/php -v
/www/server/php/74/bin/php /path/to/script.php

# Use a specific version for Composer
/www/server/php/82/bin/php /usr/bin/composer install

# Check extensions for a specific version
/www/server/php/82/bin/php -m

Cron Jobs Are the Most Error-Prone Area

# Dangerous: Which 'php' version is used depends on the environment; crontab PATH is often minimal
0 3 * * * php /var/www/artisan schedule:run

# Correct: Write the absolute path
0 3 * * * /www/server/php/82/bin/php /var/www/artisan schedule:run

The execution environment of crontab is different from your logged-in shell, and the PATH is usually more restricted. The php command might resolve to an unexpected version or not be found at all. Always use absolute paths in cron jobs.

# Check the actual execution environment of crontab
crontab -l
cat /etc/crontab | grep -i path

Confirm Which Version Your Website Is Actually Using

# Method 1: Create a temporary probe file (remember to delete it after use)
echo '<?php phpinfo();' > /var/www/html/phpinfo.php
curl -s https://example.com/phpinfo.php | grep -iE 'PHP Version|Loaded Config'

# Method 2: Command-line probe (cleaner)
php -r 'echo PHP_VERSION, PHP_EOL, php_ini_loaded_file(), PHP_EOL;'

# Method 3: Check which FPM the site configuration points to
grep -E 'fastcgi_pass' /etc/nginx/conf.d/example.conf

# Check listening addresses for each FPM version, matching them with fastcgi_pass in config
ss -lntp | grep php
ss -lx | grep php

Make sure to delete phpinfo.php after testing—it exposes significant environmental information.

Decision Tree

PHP version does not match expectations
├─ Web display version is incorrect
│  ├─ Version switch in panel did not take effect → Restart the corresponding php-fpm
│  └─ fastcgi_pass points to an old version → Update the address in the configuration
├─ Command line version is incorrect
│  ├─ update-alternatives → Use --config php to switch
│  └─ Do not want to change globally → Use absolute path calls
├─ Composer-installed dependencies have wrong version
│  └─ Composer used an old PHP → Explicitly specify the php path when calling composer
└─ Cron job behavior is abnormal
   └─ 'php' in crontab resolves to an unexpected version → Use absolute paths

Scenario Walkthrough: Backend Shows Version A, But Command Line Shows Version B

Phenomenon: You switched the site’s runtime environment to a newer version in the management panel and confirmed it took effect,
but when executing scripts via the command line, the reported version is still the old one, causing inconsistent behavior in some features.

1. First, confirm this is not just a display refresh issue → Take version outputs from both locations to confirm they are indeed different results,
   rather than an illusion caused by caching.
2. Understand what each mechanism controls → The panel controls the version called by the Web service,
   while the command line calls another version under the system default path. These are two independent sets.
3. Identify which executable the command line is using → Check the actual path being called,
   and find that it points to the old version.
4. Confirm that the panel side is indeed effective → Output version information via Web again to verify,
   proving that the two paths do not affect each other.
5. Unify the versions on both ends → Adjust the default pointer on the command line side, or explicitly specify the full path when calling.
6. Also verify scheduled tasks → Scheduled executions follow the command line side;
   if not handled, you will encounter “manual execution works, automatic execution fails” issues.

# Which version is actually used in the command line?
which php
php -v | head -1
ls -l $(which php)

# List installed versions one by one
ls /usr/bin/php* /usr/local/bin/php* 2>/dev/null
update-alternatives --display php 2>/dev/null

# Actual version on the Web side (compare with command line)
echo ' /website_dir/ver.php
curl -s https://example.com/ver.php; echo   # Delete after use

# Explicitly specify the path in scheduled tasks to avoid inheriting the wrong version
# 0 3 * * * /full/path/to/php /path/to/script.php

Root Cause: The panel and the command line use different executable file paths.
Changing one does not affect the other. Scheduled tasks inherit the command line side.

Two Key Points to Remember:

• After switching versions, verify both the “Web side” and the “Command line side” separately.
  Testing only one side will result in discrepancies between backend display and actual execution.
• For scheduled tasks and scripted executions, it is recommended to explicitly write the full path.
  Relying on default pointers can lead to hard-to-debug differences like “manual runs fine, automated runs fail”.

8 Common Pitfalls

1. Assuming panel switches affect the command line: They are independent.
2. Assuming command line switches affect the website: They do not.
3. Using relative commands in crontab: Minimal PATH may resolve to the wrong version.
4. Changing global symlinks affects other services: System scripts may depend on the default version.
5. Installing extensions into the wrong version: Use the path of the target version to install.
6. Leaving phpinfo.php in place: Information leakage; must be deleted after use.
7. Not restarting fpm after switching: The web page still uses the old version.
8. Multi-version fpm port conflicts: Two versions configured with the same listening address.

Real Customer Feedback (From Cloud Market Reviews and Inquiries for Similar Products)

The following excerpts are taken from real buyer reviews and inquiries for similar operations and maintenance services on Alibaba Cloud, Tencent Cloud, and Huawei Cloud cloud markets (service providers include our store and peers, provided here for reference only, not fictional tickets from our site):

z****j Rating: 5.0 Aug 04, 2026 14:44 z****j Rating: 5.0 Aug 08, 2025 10:52 z****j Rating: 5.0 Aug 08, 2024 15:08

1****n Rating: 5.0 Jan 04, 2018 18:04

d****9 Rating: 5.0 Feb 15, 2023 09:11 a****7 Rating: 5.0 Feb 15, 2023 09:10 d****8 Rating: 5.0 Feb 14, 2023 10:48 d****8 Rating: 5.0 Feb 14, 2023 10:43 a****3 Rating: 5.0 Jan 17, 2023 17:20