WP-CLI fails with a different PHP: correct the terminal context

Understand why the website and WP-CLI differ

The site displays normally, but a WP-CLI command reports an outdated PHP, missing module, or syntax error incompatible with the version shown by hosting. Both observations may be accurate: the web server and terminal do not have to use the same PHP executable or configuration.

WP-CLI is a command-line maintenance tool. Its launcher must first find a PHP engine, which then loads its configuration and the components needed for the operation. Changing a domain’s PHP version in a panel does not necessarily change the program invoked by your SSH session or a scheduler.

The goal is to give the terminal an identified, compatible environment without degrading the working website’s environment. We will compare contexts, choose the correct executable for a limited test, then check INI files and modules. A general system update, WordPress reinstallation, or mass plugin deactivation is not the appropriate first check for this symptom.

Confirm the account, server, and installation

This procedure assumes authorized hosting terminal access and WP-CLI already available. The launch examples are for a Unix-like shell, often used over SSH on Linux. Do not paste them unchanged into PowerShell or a PHP code field. If the host provides a specific launcher, retain its intended process and have its parameters confirmed.

Before testing, note the host, technical account, and installation path. A terminal opened on a copy does not automatically describe production. In multisite, choosing the subsite is another separate context; changing PHP selects neither the correct database nor the correct subsite.

On WordPress.com or managed hosting, check that your site actually has the platform’s intended terminal access. If that access or binary selection is unavailable, ask for the supported CLI context; do not change web PHP to compensate for a terminal you cannot access.

1. Keep the failing command’s exact message and execution time.
2. Verify the server and affected file path using your hosting procedure.
3. Identify the WP-CLI installation method: Phar, Composer, repository, or managed launcher.
4. Limit initial tests to context information. Do not immediately rerun an update, restore, or process that may already have had an effect.

Read the PHP actually used by WP-CLI

Start with wp --info, which provides information before normal WordPress loading. Record the PHP binary path, version, memory limit, INI file used, and WP-CLI configuration paths. This record is more useful than a simple version number displayed in the domain panel.

The command describes the context of the launcher invoked at that moment. It does not test every site function or guarantee a business operation will succeed. In a custom environment, the launcher’s configuration and components must remain known and trusted. Keep the record private because it exposes internal paths.

If even this display fails with an interpreter error, retain the message and move to launcher identification. If information appears and indicates PHP different from the web version, the difference is confirmed; do not yet change global configuration. The expected result of this first step is knowing which program and INI file are actually involved before deciding how to correct them.

wp --info

Compare domain PHP with session PHP

In WordPress, if you have the required permissions, open Tools > Site Health > Info > Server. Record the PHP version and information available for the domain. Supplement it with the host’s private setting when the execution mode or active configuration needs confirmation.

In the terminal, the commands below describe PHP found under the name php in this session: version, INI files, and loaded modules. Run them separately. Results may still differ from wp --info if the WP-CLI launcher explicitly selects another executable. This difference is diagnostic information, not an inconsistency to hide.

Compare full versions and paths. The same major version may use different modules or settings depending on context. Do not display all configuration or environment variables in a public ticket. Relevant paths and modules are enough to request a compatible CLI executable from the provider.

php --version
php --ini
php -m

Identify the launcher before choosing the corrective command

The name wp may refer to a Phar file, launcher script, link, or host-provided tool. The shell may also use an alias. Identify what is actually called before passing that path to PHP. A shell script does not become a PHP program merely because it is named wp.

In the relevant Unix-like shell, the commands below show what the names resolve to in this session. Keep results private and have the launcher checked if its content or origin is unknown. Do not recursively search every server file to guess another installation.

A Phar file is an archive executable by PHP; the path to this trusted file can be used directly with the correct binary. For a Composer or repository installation, the official launcher may handle PHP selection differently. A proprietary launcher may impose a container or additional parameters. In that case, use its procedure instead of bypassing its environment by pointing to a randomly found file.

command -v wp
command -v php

Run a known Phar with an explicitly selected PHP

This approach suits cases where you know the installed, trusted wp-cli.phar file and the path to a compatible PHP CLI executable provided by hosting. The paths below are examples to replace; do not download a new archive to solve simple executable selection.

Start with the chosen binary’s version and INI. Then call the same binary with the Phar and --info. Quotes preserve any spaces in each path. This invocation changes neither the account’s global PHP nor the domain’s PHP; it selects the program for this specific call.

1. Have the intended PHP CLI path and necessary modules confirmed for this installation.
2. Check its version, then configuration files, using the first two lines.
3. Replace the Phar path with that of the trusted file already identified.
4. Run the third line and compare its result with the initial record.
5. If this PHP cannot start or loads incompatible modules, keep the error and return to the initial context without changing the site.

'/chemin/vers/php' --version
'/chemin/vers/php' --ini
'/chemin/vers/php' '/chemin/vers/wp-cli.phar' --info

Choose PHP for a compatible non-Phar invocation

For a non-Phar installation using the compatible official launcher, the WP_CLI_PHP variable selects the desired binary. It is not a universal solution for every file named wp, and the documentation does not present it as interpreter selection for a directly executed Phar.

The example below sets this variable for one invocation in a Unix-like shell. Replace the PHP and launcher paths with confirmed paths. It does not permanently change your session profile or other users’ profiles. The expected result is that --info reports the intended binary and configuration.

If the launcher ignores this choice or produces an error, do not repeat the definition in several files. Return to its installation method and documentation. A host-managed tool may require another command. Also preserve existing PHP arguments necessary for intended operation; do not add arguments to disable protection or hide a missing module. A lasting fix can be prepared after this limited test with a clear rollback.

WP_CLI_PHP='/chemin/vers/php' '/chemin/installation/wp-cli/bin/wp' --info

Correct only the affected CLI configuration

If the correct executable is used but the defect persists, compare its INI files. With the selected PHP’s absolute path, --ini shows the loaded file and additional parsed files. A correct version with incomplete CLI configuration may lack a module or use a limit different from the web environment.

A web directory’s .user.ini configuration does not apply the same way to PHP CLI: it concerns CGI and FastCGI modes supporting it. Editing this file to fix a terminal command may therefore change nothing. Conversely, blindly copying PHP-FPM’s INI file to the terminal may introduce unsuitable paths or modules.

Keep a private copy of the CLI file before an authorized fix. Have the directive or module needed for the exact binary identified, then change only its configuration through the host’s mechanism. A new PHP invocation normally reloads its startup context; the web server does not need restarting for every CLI read. Check information again and keep the previous state for rollback if another tool on the same account is affected.

From this step onward, replace the short name php in previous checks with the validated absolute path. Otherwise, you might inspect the old engine found in the session again and change the wrong INI. Do the same for -m when comparing the selected PHP’s modules.

Handle a missing module and a different limit separately

If the error names a missing MySQL function, disabled PHP extension, or incompatible library, compare the selected binary’s modules. A PHP extension is an engine component; installing a WordPress plugin does not automatically provide that module to the terminal.

Have the compatible module enabled in the intended PHP CLI configuration, or use the complete executable provided for that purpose. Do not copy a library from another PHP version or load every available module to find one that makes the message disappear. Diagnosis must connect the missing function to its module and version.

A memory error also requires separate investigation. A different CLI limit may explain the difference from the web, but an unbounded increase does not fix a process growing abnormally. First check the command’s need and scope, then use an appropriate documented setting if necessary. After the fix, reread the current message: removing a version rejection may reveal another failure that is not solved by selecting yet another executable.

Reproduce a scheduled task’s context

A command may work in your interactive session and fail in a scheduler. The account, working directory, program paths, and loaded profile files may differ. Manual success therefore does not automatically validate the existing task’s environment.

In the scheduler actually used, record the command, account, and working directory without publishing secrets. Have a check version prepared that displays only context information using the confirmed absolute paths. Do not immediately replace a payment, import, or sending task with several concurrent tests.

If explicit PHP and launcher selection resolves the issue, apply that correction only to the affected job through its management procedure. Keep the previous definition and verify the next controlled run. An alias added to your personal terminal may not be known to the scheduler. For a task capable of creating or modifying data, also check the state left by the previous failure before resuming its business execution. The evidence sought remains the same PHP context, not merely the absence of a message in your session.

Validate progressively without rerunning the sensitive command

After selecting the correct environment, start by comparing --info. Then check a simple read of the WordPress files through the core version on the confirmed path. The example below uses the Phar approach; if you use another method, retain its validated launcher instead of mixing both forms.

This version read does not load every WordPress function or prove the original command will succeed. It does verify that the program can read the correct installation’s files with the selected PHP. If the displayed version does not match the expected site, stop and correct the target.

1. Confirm the binary, version, and INI reported in the corrected context.
2. Replace the example WordPress path with the authorized copy or site’s path.
3. Read the version and compare it with the expected release.
4. Then prepare a read or dry run actually offered by the original command, on the copy if loading has external effects.
5. Resume the business operation only after checking its state, backup, and scope.

'/chemin/vers/php' '/chemin/vers/wp-cli.phar' core version --path='/chemin/vers/wordpress'

Change direction if the environments match

If PHP, configuration, and modules are consistent, the defect may arise at the next stage: wrong path, database access, loaded code, or a launcher component. Keep the first significant message instead of continuing to change the engine after the initial discrepancy has been corrected.

An error in a must-use plugin may still occur even when invocation requests skipping ordinary plugins. Loading options have limits; they do not make every environment equivalent or remove every startup file. Have the named file and its owner identified before moving or editing it.

No new WordPress plugin is required to choose WP-CLI’s PHP. A plugin installed in the dashboard does not replace the terminal executable. Use launcher information and native PHP tools, then the procedure for the new failure if evidence requires it. If hosting imposes its CLI environment, send the recorded differences and request the intended compatible launcher without changing system links or every account’s profiles.

Undo the test and retain a documented launcher

An explicit invocation or a variable limited to one call does not permanently change the system: to return to the initial context, stop using that form and keep the comparison record. If an INI file, profile, or task was subsequently changed, restore only its previous setting, accounting for other intervening changes.

Check that web functions working before the intervention still work. Do not globally replace the php binary or a system link to fix one site without assessing other users. A correction local to the launcher or job is easier to verify and undo when it addresses the confirmed need.

Document the PHP and WP-CLI paths, installation method, CLI configuration, and checking procedure. Add who maintains these components and how they will evolve with the site. For a remaining defect, provide the redacted message, full versions, and differences between web, session, and scheduler. This record lets the actual context be corrected without once again requesting a change to the domain’s already-working PHP version.

Build a readable comparison of the three PHP contexts

In your record, create three rows: domain web, interactive terminal, and scheduled task. For each, record the full version, binary path where accessible, loaded INI, and module named by the error. An unknown cell remains “to confirm”; do not copy another context’s value to fill the sheet.

Fictional example: the web uses PHP 8.3 with mysqli, the session finds an old binary without that module, and the scheduled task uses yet a third path. Correcting the terminal does not establish that the task changed. First have --info report the correct context, then read core, before resuming an operation that may write.

The validated absolute path must appear in the task’s durable definition, not merely in a session alias. After the fix, keep the job’s previous version and observe its next scheduled run. If the task then fails on a file permission, record that new stage instead of changing PHP again. Native PHP and WP-CLI commands suffice for this comparison; a WordPress plugin does not select the program executed by the scheduler.