Use the service account and the correct WordPress directory. If the account hosts several sites, confirm the intended site URL through a separate identity check. A list from the wrong installation can lead support to diagnose a component that is not involved.

On Multisite, review site-specific and network activation context. A theme's installation status does not by itself describe which subsites use it.

wp plugin list --path=/path/to/wordpress --fields=name,status,version,update --format=table
wp theme list --path=/path/to/wordpress --fields=name,status,version,update --format=table

Replace the example path with the verified installation. Record the command time so the inventory can be compared with later updates. If saving the output to a file, keep it outside a public directory and review it before sharing.

1. Identify the component involved in the failing task.
2. Note recent installations, updates or activation changes.
3. Review must-use plugins and drop-ins where relevant, because they can affect behaviour beyond an ordinary active-plugin list.
4. State whether the inventory comes from production or staging.
5. Attach only the relevant sanitised output through the approved support channel.

An update indicator can depend on access to the package source and a valid commercial licence. It is not a guarantee that every installed component is supported or secure. A custom plugin may have its own release process.

If the command fails while loading WordPress, capture the error. Skipping ordinary plugins can help a targeted diagnostic in some cases, but must-use plugins or other bootstrapping code may still load. Do not assume a list command executes no application code at all.

When the ordinary plugin list does not explain a problem, inspect the components that load outside its usual active-plugin controls. These commands list must-use plugins and drop-ins for the explicitly selected WordPress installation.

wp --path='/home/ACCOUNT/sites/example.com' --url='https://example.com' \
  plugin list --status=must-use --fields=name,status,version --format=table
wp --path='/home/ACCOUNT/sites/example.com' --url='https://example.com' \
  plugin list --status=dropin --fields=name,status,version --format=table

A managed integration or object-cache.php can affect requests even when ordinary plugins appear inactive. Record its owner and purpose before proposing changes. Skipping normal plugins during a diagnostic does not automatically skip must-use plugins, so boot failures still need the relevant error evidence.

Expected result: Support receives the important component names and versions without an indiscriminate deactivation. The inventory is compared with the failing workflow and recent changes rather than treating every unfamiliar managed component as unwanted software.

Do not append update-all or deactivate-all commands to the inventory step. First review compatibility, backup and business impact. Once a correction is planned, make it through a controlled workflow and generate a fresh inventory afterward.

A clear before-and-after list helps identify what actually changed and prevents an unresolved incident from becoming a sequence of undocumented plugin experiments.

• Using WP-CLI safely on a hosting account with several sites
• Checking WordPress core file integrity with WP-CLI
• Testing plugin conflicts without disrupting public visitors
• Checking WordPress cron events with WP-CLI

• WordPress: List
• WordPress: List