Changed PHP in cPanel but the Old Version Still Runs?

You changed PHP in cPanel, but a check still shows the old version. Or the website changed successfully while php -v over SSH did not. Often, those checks are looking at different execution paths: web requests, the interactive shell and scheduled tasks.

Start by identifying which path disagrees. CLI means PHP invoked from the command line; cron is the system running scheduled commands. A different terminal version does not prove the domain setting failed, and a panel label does not prove the application is using the expected executable.

Inspect the web request itself

In an authorized, access-controlled test directory, create this small diagnostic file:

<?php
header('Content-Type: text/plain; charset=utf-8');
echo 'version=', PHP_VERSION, PHP_EOL;
echo 'sapi=', PHP_SAPI, PHP_EOL;
echo 'ini=', php_ini_loaded_file() ?: '(none)', PHP_EOL;
echo 'script=', __FILE__, PHP_EOL;

Request it through the intended domain and protocol. The script path helps detect a different document root or an old application copy. Exclude the test URL from caching so an old HTML response does not masquerade as a current runtime measurement.

The loaded INI path helps identify configuration. SAPI identifies the execution interface; its name alone does not prove which hosting control manages the version.

Distinguish MultiPHP Manager from PHP Selector

MultiPHP Manager manages PHP choices for domains or virtual hosts. Check the selected domain and whether its setting is inherited. A subdomain does not necessarily share the primary domain's choice.

A CloudLinux host may also expose PHP Selector. Native PHP, Alt-PHP, handlers and the provider's integration determine which control applies. Selecting a number in both screens is not a reliable substitute for understanding that arrangement.

A root administrator can inspect the document root, meaning the directory served for the site, and the handler, meaning the setting that routes PHP files to their executable. An account user should ask the provider to check them. Do not blindly delete managed handler lines from .htaccess; establish their scope and take a backup before changing configuration.

See what the shell resolves

command -v php
readlink -f "$(command -v php)"
php -v
php --ini

This describes the current SSH account. Root and the application account can have different PATH values. The website may already use 8.5 while the shell still resolves a system-wide executable from another branch.

On an EasyApache installation with the relevant branch installed, an explicit executable path removes that ambiguity:

/opt/cpanel/ea-php85/root/usr/bin/php -v
/opt/cpanel/ea-php85/root/usr/bin/php --ini

Those are EasyApache example paths, not universal Alt-PHP or hosting paths. Avoid manually replacing the system-wide PHP symlink just to alter one application's CLI. Other applications may depend on it.

Read the scheduled command too

A cron command using only php depends on the scheduler's environment. One using an absolute path might deliberately or accidentally be pinned to an older branch. The structure below chooses the interpreter explicitly; substitute your actual account and project path:

/opt/cpanel/ea-php85/root/usr/bin/php /home/ACCOUNT/project/bin/task.php

Before testing a real job, understand its effects. Correcting an interpreter does not make duplicate execution harmless. Long-running queue workers can also continue as existing processes until they are replaced through the application's supported procedure.

Compare all three results

You should now know the web version, the application account's shell version and the executable specified by cron. A deliberate difference may be valid. An accidental difference needs a targeted correction, not a global version switch. Once the paths are correct, verify required extensions and application workflows using the upgrade checklist.

Note: The diagnostic file exposes server paths. Restrict access during the check and remove it afterward.