WP-CLI targets the wrong WordPress: check the server, directory, and site

Recognize a command succeeding in the wrong place

A WP-CLI command can display a plausible result while having loaded another WordPress. You looked for staging plugins and found the public site’s plugins, or the displayed option belongs to another subsite. Even a success message confirms only execution on the target actually loaded. Before repeating an action that modifies the site, establish which installation responded.

This guide concerns self-hosted WordPress with an already authorized terminal or operations tool. The WordPress account used in the browser does not by itself grant server access. WP-CLI is free software; terminal, container, or remote-service access terms depend on the host. No new WordPress plugin is necessary.

Separate three questions: which machine or container runs the command, which directory supplies WordPress core, and which site it selects if that directory serves a multisite network. An error at any level can create the same impression. The expected result is a reproducible read of the intended installation before any write.

Establish the expected target from an independent source

Start from the hosting panel, approved deployment record, or team documentation. A known reference is needed before comparing terminal output. If you take the address returned by the suspect command as proof, you may confirm the wrong site using its own result.

On an installation with one public directory and another for core, record the path where WordPress is installed. It may differ from the URL’s root folder. A platform may also show a panel path different from the path seen inside the container. Ask for the mapping when unclear. The presence of wp-admin and wp-includes helps identify core, but a backup copy can have the same structure.

1. Record the intended environment, hostname or container name, and operations account.
2. Record the absolute core path and reference public address.
3. In multisite, also record the expected subsite name and ID.
4. Keep the original command with private parameters masked. Record the time if it has already changed anything.

Confirm the directory before loading the site

In the already identified session, start with an absolute path. Replace /srv/sites/preprod/wordpress with the authorized path on this machine; do not reuse an example path or guess one from the public address. This command displays the configuration-file path found by WP-CLI before normal WordPress loading. It does not display passwords contained in that file.

If the result points to another release, another copy, or an unexpected shared configuration, stop and check the architecture. The file may intentionally sit above core; compare with the intended configuration, not a rule demanding one unique location. If a deployment link changes versions, ask which directory it pointed to at incident time.

The resulting path is an initial check, not proof that the database is the expected one. If the command cannot find configuration, first correct the read destination. Do not run an installation or create a file merely to eliminate the message.

wp --path="/srv/sites/preprod/wordpress" config path

Read the selected WordPress installation’s addresses

Once the configuration path matches, query two values without changing them. The home option corresponds to the expected public address, and siteurl to the address where core is accessible. A difference may be intentional, especially if WordPress files are in a subdirectory. Compare each with its reference value instead of making them identical.

In the example, replace the path on both lines. The commands load WordPress; use an already identified environment and do not perform this read on an unknown copy. If a PHP error prevents loading, the check remains incomplete. Do not treat the configuration path as a substitute for the missing result.

For this first read, avoid the original command if it mixes reads and writes. A result consistent with the public address is another clue, but some installations enforce addresses through configuration or change them with a filter. If output is surprising, have these values checked without replacing them to make the test appear successful.

wp --path="/srv/sites/preprod/wordpress" option get home
wp --path="/srv/sites/preprod/wordpress" option get siteurl

Distinguish two copies displaying the same address

Cloned staging may retain the production domain and name. Two identical responses therefore establish neither a directory error nor proof of the correct database. Ask which environment, database resource, and table prefix deployment was meant to associate with this copy. Compare that information in the private panel or with the owner. The same database name or prefix may exist on two servers; check the entire association.

WordPress’s declared environment label can supplement the check if the team maintains it, but production may simply be the default value. Do not repair diagnosis by changing that label. Look for a preexisting difference the team can confirm: the copy’s hosting ID, deployment destination, or known staging content read without modifying it.

If the same database is associated with both copies when they should be isolated, suspend writes. Another directory does not protect production data when commands reach the same tables. Have the expected association restored before resuming.

Choose the intended subsite in a multisite network

A network generally shares one WordPress installation among several sites. The path identifies the network but is insufficient to select the subsite. First list the sites in that network and find the complete URL matching the expected ID. In a subdirectory network, retain the portion after the domain; in a network with custom domains, use the exact hostname intended for that site.

The example uses a fictional installation and store subsite. Replace the path and URL with confirmed values, then read home and the current ID. The final command contains only a read expression; do not insert code from an unknown source. If the site is absent from the list or the returned ID is unexpected, first check the network and context.

The --url option specifies site context. It does not open a session on the URL’s server or automatically narrow the scope of a network or database command. Read the help for the command you intend to use before entrusting it with a write.

wp --path="/srv/sites/reseau" site list --fields=blog_id,url
wp --path="/srv/sites/reseau" --url="https://reseau.example/boutique/" option get home
wp --path="/srv/sites/reseau" --url="https://reseau.example/boutique/" eval 'echo get_current_blog_id(), PHP_EOL;'

Trace the file enforcing the wrong value

If the command works with an explicit path but targets incorrectly without it, examine launcher configuration from the same directory and account as during the incident. Local or project files may be discovered by searching parent directories. An account-specific global file may also supply a value, and its location may be changed through the WP_CLI_CONFIG_PATH variable.

The command line takes precedence over ordinary configuration values. This helps confirm a local target, but does not turn a remote command into a local one if a wrapper or setting still enforces transport. Read only useful entries in already identified files. Do not display their complete contents in a ticket: they may contain internal paths or secret references.

1. From the starting directory, run wp cli info to record configuration paths in your private session.
2. Identify where path, url, or the relevant connection mode is defined.
3. Compare the value with the independent reference, then back up the file before correction.
4. Change only the responsible entry and repeat control reads. Restore the backed-up file if the result regresses.

Check where an alias leads before reusing it

A WP-CLI alias is a shortcut saved in configuration. A name such as @preprod may retain the old server after migration. Its label guarantees no particular property: only the configured and then confirmed destination matters. Shell aliases and intermediate scripts also exist; verify that you are examining the same mechanism used by the command.

The first line reads the definition of an existing WP-CLI alias. Inspect its result privately, since interpolated variables may expose sensitive values. Do not share the entire output. If host, path, and transport have been confirmed and authorized, the second line checks the WordPress configuration found through that alias. Replace @preprod with the actual name. Do not initiate a connection when the definition reveals an unknown destination.

Correct the definition in its source file after backup instead of adding the same alias elsewhere and leaving two competing values. Then check path and addresses with the corrected alias. If a discrepancy remains, restore the backed-up definition and continue with explicit targeting from a known session.

wp cli alias get @preprod
wp @preprod config path

Correct a script starting from another context

When the manual command correctly targets the site but a script’s result differs, compare the two execution modes. A scheduled task or deployment pipeline may start in another directory, use another user, or open a different container. It may also read a distinct global configuration. Correcting your personal profile will not fix a task running under another account.

Review the relevant script definition and latest available trace. Prepare the correction in a copy of its file, fixing the intended host or container and exact path; in multisite, add URL context where the command takes it into account. For a recurring task, ask its owner to validate a read-only operation using the same account and starting directory before resuming writes.

If this test reproduces the error, compare its parameters and loaded configurations, one difference at a time. Keep the old definition to return to a known version. If the old version already sent operations to the wrong site, restoring it must not reactivate the task unchanged. Resume only when target and scope are confirmed.

If a command has already changed the wrong site

Do not rerun the same action on the correct site before understanding its effects on the first. Record the exact command, start and end, target parameters, and displayed messages. Some operations affect files, others the database or entire network. Partial output proves neither complete success nor absence of changes.

With the operator, compare the affected target’s state with a backup or previous record. If only one option changed and its original value is established, targeted repair is generally easier to verify than full restoration. An active database may have received other writes between backup and incident. Restoring every table for one setting can erase recent data.

1. Identify the site actually affected and the write type from traces.
2. Back up its current state before any repair, then compare changes.
3. Have a restoration chosen that is proportionate to the operation.
4. Check the affected site and originally intended target separately. Record effects that cannot be undone locally.

Validate the final command’s own scope

A recognized target does not tell you which data a command processes. An option read may be subsite-specific while a database operation may target shared tables or tables explicitly included by its options. Consult that command’s help to list its scope and any available simulation modes. A --dry-run parameter is not universal; do not assume support.

If a simulation is documented, compare the announced objects with the intended scope. If absent, use an isolated copy to test a risky operation with the same relevant components and settings. A read command can confirm site identity without validating another command’s consequences. Perform these two checks separately.

Validation is satisfactory when session, configuration path, and site reads agree and the action’s scope is known. If any one diverges, return to the corresponding check. For doubts about the terminal’s PHP engine or INI file, examine that separately: changing binaries helps here only if the current one prevents reads from starting correctly.

Make target verification a reusable step

Document read commands for each environment in the team’s private guide. Record who updates the path during migration, which subsites are involved, and where aliases are defined. Temporary access or a moved copy must be removed from documentation as soon as it stops being the reference.

For a team acting frequently, use clear environment labels and associate every alias with verifiable information. A descriptive name remains useful for avoiding typos, but does not replace checking the result. After a server change, verify old shortcuts, including those belonging to the account running recurring tasks.

For an exceptional operation, retain the expected site name, path, and read confirming context alongside the trace. Do not save raw output if it contains private values. If hosting offers no terminal, use its own management features or ask the operator for the targeted record. The desired result remains the same: connect every action to the correct environment and scope before it changes data.

Add a compact read of the loaded context

After confirming machine and path, this WP-CLI expression reads three WordPress reference points. Replace path and URL with the authorized target; the --url option is particularly useful for selecting a subsite. Output remains private because it contains the internal path.

This command does not directly modify data, but loads WordPress and its components; run it only on the already identified installation. racine describes the loaded core, site_id the current site, and environnement a configuration label. A production label may be the default: it does not demonstrate that you are on production. Likewise, two clones may share the same site ID.

Therefore compare these values with independent deployment references, then with the addresses read in the guide. If one value diverges, stop writes and correct the targeting source. Do not change the label to make output match what you hoped for.

For a beginner without a terminal, the hosting panel and environment owner can provide this record; no plugin is required. The read requires no restoration. If you then correct an alias, keep its previous definition and retest the read before resuming the command actually intended to change the site.

wp --path="/srv/sites/preprod/wordpress" --url="https://preprod.example/" eval 'echo wp_json_encode(array("racine" => ABSPATH, "site_id" => get_current_blog_id(), "environnement" => wp_get_environment_type()), JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES), PHP_EOL;'