Read WordPress diagnostic reports before changing a site

Read a WordPress diagnostic report before changing a site. Our disposable WordPress fixture exposed misleading autoload totals and default-path assumptions, then checked a revised helper against the same synthetic data. These are native helper observations, not an AI-agent evaluation or a page-speed benchmark.

Choose the target and the question

Start with the installation you intend to inspect and the decision you need to make. WordPress WP-CLI Operations includes an inspector for the command-line environment, installed core, single-site or network status, and configured URLs. WordPress Performance Investigation supplies a different report: diagnostic command availability, autoload value bytes and file-presence signals. Neither report automatically identifies the cause of a slow page.

We ran the original helpers and a BB Skills performance adaptation on WordPress 7.1.2, PHP 8.3.35, MariaDB 11.4.13, WP-CLI 2.12.0 and Node.js 22.23.3. A temporary internal Docker network contained the installation and database. There were no published ports, production mounts, real user accounts or external AI calls. The runner used fresh synthetic data and recorded 30 named observations.

The operations inspector correctly reported a single-site install, its core version and the synthetic site URL. We did not execute domain migration, database restore, cache flush, cron jobs, plugin updates or multisite writes. Read those workflow references as plans that still need target-specific review.

Check readiness inside the JSON

A process that exits successfully can still report that a prerequisite is missing. Both original helpers exited with status 0 when WP-CLI was absent from PATH. The JSON field wpCli.available was false. With WP-CLI available but an invalid WordPress root, the installation field was false. An automation that checks only the process exit code could wrongly continue to a later operation.

Inspect the exact target, wpCli.available, the installation field, notes, null measurements and failed subcommands. The two reports use different object names for installation state: wp.isInstalled in the performance report and wordpress.isInstalled in the operations report. Define a readiness gate for the report you actually consume.

Our temporary environment did not have WP-CLI doctor or profile packages. The performance report marked both unavailable. This means those diagnostics were not run; it does not mean that a doctor check passed or a profile found no bottlenecks. The helper does not automatically install its suggested packages. Review the executable and supply an external execution limit, because the source helpers have no built-in subprocess timeout.

Cross-check which options are counted

The original performance helper invoked wp option list --autoload=on --format=total_bytes. In our pinned WP-CLI 2.12.0 environment, that filter selected the legacy yes and explicit on values. WordPress core also loaded auto-on and auto. We checked the active set through the core function and independently summed the matching database values.

Synthetic autoload value	Value bytes	Loaded by core in this fixture	Selected by the recorded CLI filter
yes	10	Yes	Yes
on	20	Yes	Yes
auto-on	30	Yes	No
auto	40	Yes	No
no	50	No	No
off	60	No	No
auto-off	70	No	No

The four active synthetic values totaled 100 bytes, while the CLI filter returned 30. For the complete options table, including the freshly installed core's own values, the independent active sum was 30,136 bytes. The original helper reported 28,558 bytes, a difference of 1,578. The difference included 70 synthetic bytes plus core values; assuming that the complete discrepancy must equal only our added rows would have been wrong.

The BB Skills revision counts the values returned by wp_load_alloptions() instead. It reported 30,136 bytes in the same synthetic environment, agreeing with the independent SQL check. This is a sum of loaded value lengths, not database allocation, PHP heap usage, query duration or HTTP response time. WordPress filters and persistent caches may change the relationship between loaded values and the database in another installation.

Consult the core autoload-value reference and WP-CLI option-list reference, then verify your installed command version. This result describes the recorded combination of versions; it is not a claim that every current CLI release has the same behavior. Do not toggle autoload settings merely to match a smaller number.

Resolve configured content directories

The original helper looked for cache and plugin files below the supplied root's wp-content directory. WordPress supports a configured content location. In our custom-directory case, core reported WP_CONTENT_DIR=/tmp/custom-wp-content, and the synthetic cache and plugin files existed there. The original helper returned false for all four presence flags because it inspected the default path.

The adapted helper resolves WP_CONTENT_DIR and WP_PLUGIN_DIR through the targeted WordPress installation before examining files. All four custom-directory presence flags then became true. After removing the default-directory markers, its default-path run correctly reported four false flags. The original helper is retained unchanged under upstream-original/scripts/perf_inspect.mjs so readers can inspect the difference.

These observations concern configured content and plugin roots. They do not cover arbitrary plugin folder renaming, remote filesystems, every drop-in type or a complete compatibility matrix. Read the WordPress configuration handbook before changing paths in an existing installation.

Separate file presence from working features

We used harmless PHP files as presence markers. The flags became true when those files were at the expected paths, even though the plugin activation list was empty and the cache markers contained no persistent-cache implementation. A detected file is therefore a prompt for a more specific check, not proof of a functioning cache or active profiler.

For a real installation, inspect plugin activation, the selected cache backend and the behavior you need. For example, a cross-request cache check needs two independent requests and backend evidence; a PHP file's existence cannot supply that result. Our fixture did not perform that test. Avoid describing a cache as healthy or promising a faster site on the strength of these flags.

Turn signals into a measurement plan

After checking readiness and report scope, choose a concrete symptom: a particular REST route, administrative action or public request. Record the method, environment, relevant input and acceptance criteria before a change. If you want to investigate a suspected query bottleneck, obtain query or profiling evidence; an autoload byte count alone cannot identify the cause.

This experiment changed diagnostic logic, not a real site's performance configuration. It measured no page-speed improvement, Core Web Vitals, production traffic or concurrent workload. The REST roles and real-HTTP guide shows a separate functional test matrix. A functional success and a performance claim need different evidence.

Use WordPress Project Triage when you first need to determine the project layout and available tooling. Keep package source review, native helper observations and an AI client's full workflow evaluation separate. The catalog's full-skill review field remains runtime_tested: false.

Reproduce and inspect the package

The two packages include examples/native-cli-evidence.json, original and adapted helper sources, setup, runner and a README. The evidence records all 30 observations, raw diagnostic reports, source hashes, image identities and versions. The runner refuses existing fixture names, uses temporary data and removes the containers and network that it created.

The example does not redistribute WP-CLI or Node binaries. Obtain the official runtime artifacts named in the evidence, verify the WP-CLI checksum against its pinned official Dockerfile source, and review the runner before executing it on a disposable Linux Docker host. Runtime image tags can change; compare identities and versions before calling a later run equivalent. The example writes synthetic setup data and must not be redirected toward a real database.

Both skill packages use GPL-2.0-or-later, preserve the upstream grant and full license text, and identify BB Skills changes. The operations helper is unchanged; the performance adaptation changes the autoload calculation and configured-directory lookup. Other upstream sources retain their original bytes. This is an independent BB Skills adaptation, not an upstream endorsement.

Evidence and authoring method

BB Skills used AI assistance to write and review the guide, fixture and adaptation, then checked them against actual native outputs and package-bound source hashes. No AI client executed the complete upstream skills. The experiment used free source artifacts and local synthetic data, with no paid model calls, external account credentials or commercial profiler purchase.

The guide's totals and path results come from the recorded experiment. The official references explain the interfaces; they are not independent validation of this adaptation. The useful next step is a target-specific check with your own installed versions and a question that these diagnostics can actually answer.