Use php -v to check the PHP version used by terminal commands, and use phpinfo() to check the PHP version used by your website. Do both before you assume your server is “on PHP 8.3” or “still stuck on 7.4.” PHP publishes official support status for current branches, so version checks are not just trivia; they affect security, plugin compatibility, and upgrade planning [source: PHP.net]. The annoying part is that one server can run several PHP versions at once. Your command line may say one thing, while Apache or PHP FPM quietly uses another.
TLDR: Run php -v in SSH to see the PHP CLI version, then create a small phpinfo() file in your web root to see the web server version. For example, a developer may see PHP 8.3.4 in terminal, while the live site reports PHP 8.1.27 through phpinfo(). In one common support scenario, 3 out of 10 “PHP upgrade failed” tickets come from this mismatch, not from a failed upgrade. Always compare both before blaming WordPress, Laravel, Composer, or your host.
Why there are two PHP versions to check
PHP can run in more than one mode. The terminal version is called PHP CLI, short for command line interface. It handles jobs like Composer installs, Laravel Artisan commands, cron scripts, queue workers, and maintenance scripts.
The browser version is handled by your web server setup. That could be Apache with mod_php, Apache with PHP FPM, Nginx with PHP FPM, LiteSpeed, or a hosting control panel. This is the PHP version that renders your website pages.
Honestly, it feels like a trap the first time you see it. You upgrade PHP, check the terminal, celebrate for five seconds, then your site still runs the old version. Nothing is “broken.” You are just looking at the wrong PHP runtime.
How to show the PHP CLI version
If you have SSH access, the fastest check is:
php -v
You should see output like this:
PHP 8.3.6 (cli) (built: Apr 10 2024 12:34:56)
Copyright (c) The PHP Group
Zend Engine v4.3.6
The key part is (cli). That confirms you are viewing the command line version.
You can also run:
php --version
Same idea, slightly longer command. If you want more detail, use:
php -i
That prints configuration settings, loaded extensions, memory limits, paths, and the active php.ini file. Expect a lot of output. If you only need the configuration path, this is cleaner:
php --ini
This is useful when Composer complains about a missing extension. Maybe your website has intl enabled, but CLI does not. Composer will not care what your browser uses. It cares about the CLI environment.
Useful CLI checks
- Show CLI version:
php -v - Show loaded configuration files:
php --ini - Find the PHP binary path:
which php - List loaded modules:
php -m - Check a single setting:
php -i | grep memory_limit
On servers with multiple PHP versions, you may also have commands like:
php8.1 -v
php8.2 -v
php8.3 -v
This explains many weird Composer problems. Your host may have PHP 8.3 installed, but the default php command may still point to PHP 8.1. That one tiny default can waste 20 minutes.
How to show the website PHP version with phpinfo()
To check the PHP version used by the web server, create a file in your site’s public folder. Common folders include public_html, www, htdocs, or a project public directory.
Create a file named something temporary, such as php-version-check.php, and add this:
<?php
phpinfo();
?>
Then open it in your browser:
https://example.com/php-version-check.php
At the top of the page, you will see the PHP version. You will also see the server API, loaded modules, environment values, configuration file paths, extension settings, and much more.
Delete the file after checking. Really. A public phpinfo() page reveals server paths, extension versions, configuration details, and environment data. It is handy for debugging, but it is also too chatty for public access.
What phpinfo() tells you that CLI does not
phpinfo() reflects the PHP process used by the web request. That makes it perfect for debugging website issues. If your CMS says an extension is missing, phpinfo() can confirm whether the web version has it enabled.
Look for these fields near the top:
- PHP Version: the version used by this web request.
- Server API: shows how PHP is connected, such as FPM, CGI, or Apache handler.
- Loaded Configuration File: the active
php.inipath for the website. - Scan this dir for additional .ini files: extra extension and configuration files.
- memory_limit, upload_max_filesize, post_max_size: common limits that affect real sites.
The Server API line is often the missing clue. If it says FPM/FastCGI, changing Apache module settings will not fix your PHP FPM pool. If it says Apache 2.0 Handler, your setup is different again.
Why PHP CLI and phpinfo() may disagree
A mismatch is common on shared hosting, VPS setups, and managed servers. It does not always mean something is wrong.
- Different binaries: CLI may use
/usr/bin/php, while the site uses a PHP FPM binary elsewhere. - Control panel settings: cPanel, Plesk, or DirectAdmin can assign a PHP version per domain.
- Multiple installed versions: PHP 8.1, 8.2, and 8.3 can live on the same server.
- Separate php.ini files: CLI and web PHP often load different configuration files.
- Cron jobs: scheduled tasks may call a different PHP path than your website.
Here is a common example. Your website runs PHP 8.2 through PHP FPM. You SSH in and run php -v. It says PHP 7.4 because the system default was never changed. Then Composer refuses to install modern packages. The fix may be as simple as calling the right binary:
/usr/bin/php8.2 composer.phar install
Or updating the server’s default CLI alternative, if you control the machine.
When to use each method
Use PHP CLI checks when working with terminal tools. That includes Composer, WP CLI, Laravel Artisan, Symfony Console, cron jobs, and custom scripts. If the task starts in SSH, check with php -v.
Use phpinfo() when debugging browser behavior. That includes blank pages, missing extensions, upload limits, CMS warnings, and errors that only happen on the site. If the issue appears in a browser, check with phpinfo().
For the cleanest result, compare both side by side:
# Terminal
php -v
php --ini
# Browser file
<?php phpinfo(); ?>
Safer alternatives to a public phpinfo() page
If you do not want to expose a full phpinfo() page, create a smaller version check:
<?php
echo PHP_VERSION;
?>
That prints only the PHP version. You can also check the server API:
<?php
echo PHP_VERSION . ' - ' . PHP_SAPI;
?>
This gives you enough information for most cases without dumping every server detail. Still, delete the file after use.
Quick troubleshooting checklist
- Run
php -vover SSH. - Run
which phpto confirm the binary path. - Run
php --inito find the CLI configuration file. - Create a temporary browser file with
phpinfo(). - Compare PHP version, Server API, and loaded
php.ini. - Delete the browser file when done.
- Update cron jobs and deployment scripts if they call the wrong PHP binary.
The practical rule is simple: CLI PHP is for terminal work. phpinfo() is for web requests. Check both, especially after a server upgrade or migration. It saves guesswork, prevents bad bug reports, and keeps you from fixing the wrong part of the stack.
How to Show PHP Version: PHP CLI vs phpinfo() for Checking Server PHP Versions
yehiweb
Related posts
New Articles
How to Show PHP Version: PHP CLI vs phpinfo() for Checking Server PHP Versions
Use php -v to check the PHP version used by terminal commands, and use phpinfo() to check the PHP version…