How to Check Your PHP Version and Find php.ini

Knowing your PHP version matters more than it sounds. WordPress, plugins, and themes all have minimum PHP version requirements that change with every major release. A plugin update that requires PHP 8.1 will break on a server running PHP 7.4. A WordPress core update that drops support for an older PHP version will warn you in the dashboard, but only if you check. And when you need to change a PHP setting, you need to know which php.ini file is actually being loaded.

This guide covers every way to check your PHP version, how to find the active php.ini file, WordPress PHP compatibility requirements, and what happens when things do not match.

Check PHP version from the command line#

If you have SSH access to your server:

php -v

Output:

PHP 8.2.18 (cli) (built: Apr 11 2024 16:30:45) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.18, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.18, Copyright (c), by Zend Technologies

The first line tells you the version (8.2.18), the interface (cli), and whether it includes thread safety (NTS = non-thread-safe, which is standard for PHP-FPM).

Important: CLI vs web server PHP version

The php -v command shows the CLI (command line) PHP version. This is not necessarily the same version your web server uses. On many systems, the CLI and PHP-FPM run different PHP versions, especially if multiple versions are installed.

To check specifically which PHP version PHP-FPM is running:

php-fpm8.2 -v

Or check which PHP-FPM process is active:

ps aux | grep php-fpm

The output shows the PHP-FPM binary path, which includes the version number (e.g., /usr/sbin/php-fpm8.2 ).

For the definitive answer on which PHP version serves your website, use phpinfo() as described in the next section.

Check PHP version with phpinfo()#

Create a file called info.php in your web root:

<?php
phpinfo();

Then visit https://example.com/info.php in your browser. The page displays a comprehensive table of PHP configuration. The version number is at the very top.

The phpinfo output also shows:

• The loaded php.ini file path
• All loaded extensions
• Every configuration directive and its current value
• Server API (CGI/FastCGI, Apache module, etc.)
• Thread safety setting
• Loaded Zend extensions (OPcache, etc.)

Delete info.php when you are done

phpinfo() exposes server internals that are useful to attackers: PHP version, loaded extensions, file paths, environment variables, and configuration details. Do not leave this file on a production server. Check it, note what you need, and delete it:

rm /var/www/html/info.php

If you forget and leave it accessible, anyone who finds the URL gets a complete picture of your server configuration.

Check PHP version in WordPress#

From the admin dashboard

Go to Tools > Site Health and click the Info tab. Expand the Server section. The PHP version is listed there along with other server details.

Alternatively, go to Dashboard > At a Glance on some WordPress versions. The PHP version may be shown at the bottom of the widget, depending on your WordPress version and theme.

From the Site Health status page

Tools > Site Health > Status runs automated checks including PHP version compatibility. If your PHP version is outdated or approaching end of life, WordPress shows a recommendation to update.

Find your php.ini location#

From the command line

php --ini

Output:

Configuration File (php.ini) Path: /etc/php/8.2/cli
Loaded Configuration File:         /etc/php/8.2/cli/php.ini
Scan for additional .ini files in: /etc/php/8.2/cli/conf.d
Additional .ini files parsed:      /etc/php/8.2/cli/conf.d/10-opcache.ini,
                                   /etc/php/8.2/cli/conf.d/20-curl.ini,
                                   ...

The key line is Loaded Configuration File. That is the php.ini file that PHP is actually using.

The Additional .ini files section shows supplementary configuration files, typically one per extension. These are loaded after the main php.ini and can override settings.

CLI vs PHP-FPM php.ini

This is the same issue as the version check. The CLI and PHP-FPM typically load different php.ini files:

• CLI:  /etc/php/8.2/cli/php.ini
• PHP-FPM:  /etc/php/8.2/fpm/php.ini

If you change a setting in the CLI php.ini, it does not affect your website. Changes that should affect web requests need to go in the FPM php.ini (or in the pool configuration, or in a conf.d override).

To find the PHP-FPM php.ini specifically, use phpinfo() as described above. The “Loaded Configuration File” in the phpinfo output is always the one serving the web request, which is the PHP-FPM config.

Common php.ini locations on Linux

Replace 8.2 with your actual PHP version.

On Ubuntu/Debian with the Ondrej PPA (the most common setup for multiple PHP versions), each PHP version has its own directory under /etc/php/ . CLI and FPM each have a separate php.ini within that directory.

Using find to locate php.ini

If the above paths do not match your system:

find /etc -name "php.ini" 2>/dev/null

This searches the /etc directory tree for any file named php.ini. On systems with multiple PHP versions installed, you may see several results. Cross-reference with the phpinfo() output to identify which one is active.

Common php.ini settings you might need to change#

These are the settings people most frequently need to find and modify:

For WordPress, the most common change is increasing upload_max_filesize and post_max_size to allow larger media uploads. See 413 Request Entity Too Large in Nginx for the full picture on upload limits (Nginx has its own limit that also needs to be adjusted).

For error configuration, see How to display PHP errors and enable error reporting.

After changing php.ini, restart PHP-FPM for the changes to take effect:

sudo systemctl restart php8.2-fpm

WordPress PHP compatibility#

Minimum PHP version for WordPress

WordPress 6.x requires PHP 7.2.24 as the absolute minimum, but recommends PHP 7.4 or later. The WordPress project has historically been conservative about raising the minimum PHP version to avoid breaking sites on older hosts.

In practice, you should run PHP 8.1 or later. Older versions are at end of life and no longer receive security patches:

Running an end-of-life PHP version means known security vulnerabilities are not patched. No amount of WordPress security plugins compensates for an unpatched PHP runtime.

Plugin and theme PHP requirements

Plugins and themes set their own minimum PHP version independently of WordPress core. A plugin might require PHP 8.0 while WordPress itself still supports 7.2. When you try to activate a plugin that requires a newer PHP version, WordPress blocks the activation and shows a notice explaining the requirement.

The problem is when a plugin you already have active pushes a requirement change in an update. If the update requires PHP 8.1 and you are running PHP 7.4, updating the plugin can break your site. WordPress added auto-update safety checks for this, but they are not foolproof. Always check the plugin changelog before updating, especially on older PHP versions.

What happens when PHP is too old

Depending on the incompatibility, you may see:

• Fatal error on activation. WordPress catches this and prevents activation. You see a clean error message.
• Fatal error on update. The updated code uses a PHP feature your version does not support. The site (or at least the affected functionality) breaks with a white screen or error message.
• Deprecation warnings. The code works but PHP warns that certain functions will be removed in a future version. These are not immediately harmful but indicate the code is aging. See How to display PHP errors and enable error reporting for how to see these warnings.
• Silent behavior differences. Some PHP functions changed return types between versions. Code that works on PHP 7.4 may return different values on PHP 8.2, causing subtle bugs that are hard to trace.

Upgrading PHP

Before upgrading PHP on a server that runs a live site:

1. Check plugin compatibility. Review each active plugin for the new PHP version. Most major plugins publish compatibility information in their changelogs or readme files.
2. Test on a staging environment. Run your site on the new PHP version in a non-production environment and test critical functionality: checkout flow, forms, admin operations.
3. Check for deprecation warnings. Enable  WP_DEBUG  and  WP_DEBUG_LOG  on staging and review  wp-content/debug.log  for deprecation notices that indicate code that will break in future PHP versions.
4. Upgrade and monitor. After upgrading on production, watch the PHP error log for the first few days.

The PHP version also affects database compatibility. If you are running MariaDB or MySQL, ensure your database version is compatible with the new PHP version. See MySQL vs MariaDB: which should you use for how the two databases differ and how PHP version interacts with database driver support.

PHP version and php.ini on Hostney#

On Hostney, both the PHP version and php.ini settings are managed through the control panel without SSH access.

Check and change PHP version: go to Hosting > PHP Manager. The current PHP version is displayed at the top. You can switch between available versions from a dropdown. The change takes effect immediately.

Change php.ini settings: go to Hosting > PHP Manager > Variables tab. Common directives like memory_limit , upload_max_filesize , post_max_size , max_execution_time , display_errors , and error_reporting are configurable from the interface. Changes take effect immediately without needing to restart PHP manually.

This means you do not need to find or edit php.ini files directly. The control panel writes the correct values to the active PHP-FPM configuration and reloads the service automatically.