wordpress-agent-kit 0.5.1 → 0.6.0

package/.github/skills/wp-rest-api/SKILL.md

@@ -1,115 +0,0 @@
----
-name: wp-rest-api
-description: "Use when building, extending, or debugging WordPress REST API endpoints/routes: register_rest_route, WP_REST_Controller/controller classes, schema/argument validation, permission_callback/authentication, response shaping, register_rest_field/register_meta, or exposing CPTs/taxonomies via show_in_rest."
-license: GPL-2.0-or-later
-compatibility: "Targets WordPress 6.9+ (PHP 7.2.24+). Filesystem-based agent with bash + node. Some workflows require WP-CLI."
----
-
-# WP REST API
-
-## When to use
-
-Use this skill when you need to:
-
-- create or update REST routes/endpoints
-- debug 401/403/404 errors or permission/nonce issues
-- add custom fields/meta to REST responses
-- expose custom post types or taxonomies via REST
-- implement schema + argument validation
-- adjust response links/embedding/pagination
-
-## Inputs required
-
-- Repo root + target plugin/theme/mu-plugin (path to entrypoint).
-- Desired namespace + version (e.g. `my-plugin/v1`) and routes.
-- Authentication mode (cookie + nonce vs application passwords vs auth plugin).
-- Target WordPress version constraints (if below 6.9, call out).
-
-## Procedure
-
-### 0) Triage and locate REST usage
-
-1. Run triage:
-   - `node skills/wp-project-triage/scripts/detect_wp_project.mjs`
-2. Search for existing REST usage:
-   - `register_rest_route`
-   - `WP_REST_Controller`
-   - `rest_api_init`
-   - `show_in_rest`, `rest_base`, `rest_controller_class`
-
-If this is a full site repo, pick the specific plugin/theme before changing code.
-
-### 1) Choose the right approach
-
-- **Expose CPT/taxonomy in `wp/v2`:**
-  - Use `show_in_rest => true` + `rest_base` if needed.
-  - Optionally provide `rest_controller_class`.
-  - Read `references/custom-content-types.md`.
-- **Custom endpoints:**
-  - Use `register_rest_route()` on `rest_api_init`.
-  - Prefer a controller class (`WP_REST_Controller` subclass) for anything non-trivial.
-  - Read `references/routes-and-endpoints.md` and `references/schema.md`.
-
-### 2) Register routes safely (namespaces, methods, permissions)
-
-- Use a unique namespace `vendor/v1`; avoid `wp/*` unless core.
-- Always provide `permission_callback` (use `__return_true` for public endpoints).
-- Use `WP_REST_Server::READABLE/CREATABLE/EDITABLE/DELETABLE` constants.
-- Return data via `rest_ensure_response()` or `WP_REST_Response`.
-- Return errors via `WP_Error` with an explicit `status`.
-
-Read `references/routes-and-endpoints.md`.
-
-### 3) Validate/sanitize request args
-
-- Define `args` with `type`, `default`, `required`, `validate_callback`, `sanitize_callback`.
-- Prefer JSON Schema validation with `rest_validate_value_from_schema` then `rest_sanitize_value_from_schema`.
-- Never read `$_GET`/`$_POST` directly inside endpoints; use `WP_REST_Request`.
-
-Read `references/schema.md`.
-
-### 4) Responses, fields, and links
-
-- Do **not** remove core fields from default endpoints; add fields instead.
-- Use `register_rest_field` for computed fields; `register_meta` with `show_in_rest` for meta.
-- For `object`/`array` meta, define schema in `show_in_rest.schema`.
-- If you need unfiltered post content (e.g., ToC plugins injecting HTML), request `?context=edit` to access `content.raw` (auth required). Pair with `_fields=content.raw` to keep responses small.
-- Add related resource links via `WP_REST_Response::add_link()`.
-
-Read `references/responses-and-fields.md`.
-
-### 5) Authentication and authorization
-
-- For wp-admin/JS: cookie auth + `X-WP-Nonce` (action `wp_rest`).
-- For external clients: application passwords (basic auth) or an auth plugin.
-- Use capability checks in `permission_callback` (authorization), not just “logged in”.
-
-Read `references/authentication.md`.
-
-### 6) Client-facing behavior (discovery, pagination, embeds)
-
-- Ensure discovery works (`Link` header or `<link rel="https://api.w.org/">`).
-- Support `_fields`, `_embed`, `_method`, `_envelope`, pagination headers.
-- Remember `per_page` is capped at 100.
-
-Read `references/discovery-and-params.md`.
-
-## Verification
-
-- `/wp-json/` index includes your namespace.
-- `OPTIONS` on your route returns schema (when provided).
-- Endpoint returns expected data; permission failures return 401/403 as appropriate.
-- CPT/taxonomy routes appear under `wp/v2` when `show_in_rest` is true.
-- Run repo lint/tests and any PHP/JS build steps.
-
-## Failure modes / debugging
-
-- 404: `rest_api_init` not firing, route typo, or permalinks off (use `?rest_route=`).
-- 401/403: missing nonce/auth, or `permission_callback` too strict.
-- `_doing_it_wrong` for missing `permission_callback`: add it (use `__return_true` if public).
-- Invalid params: missing/incorrect `args` schema or validation callbacks.
-- Fields missing: `show_in_rest` false, meta not registered, or CPT lacks `custom-fields` support.
-
-## Escalation
-
-If version support or behavior is unclear, consult the REST API Handbook and core docs before inventing patterns.

package/.github/skills/wp-rest-api/references/authentication.md

@@ -1,18 +0,0 @@
-# Authentication (summary)
-
-## Cookie authentication (in-dashboard / same-site)
-
-- Standard for wp-admin and theme/plugin JS.
-- Requires a REST nonce (`wp_rest`) sent as `X-WP-Nonce` header or `_wpnonce` param.
-- If the nonce is missing, the request is treated as unauthenticated even if cookies exist.
-
-## Application Passwords (external clients)
-
-- Available in WordPress 5.6+.
-- Use HTTPS + Basic Auth with the application password.
-- Recommended over the legacy Basic Auth plugin.
-
-## Auth plugins
-
-- OAuth 1.0a or JWT plugins are common for external apps.
-- Use only if required; follow plugin docs and security guidance.

package/.github/skills/wp-rest-api/references/custom-content-types.md

@@ -1,20 +0,0 @@
-# Custom Content Types (summary)
-
-## Custom post types
-
-- Set `show_in_rest => true` in `register_post_type()` to expose in `wp/v2`.
-- Use `rest_base` to change the route slug.
-- Optionally set `rest_controller_class` (must extend `WP_REST_Controller`).
-
-## Custom taxonomies
-
-- Set `show_in_rest => true` in `register_taxonomy()`.
-- Use `rest_base` and optional `rest_controller_class` (default `WP_REST_Terms_Controller`).
-
-## Adding REST support to existing types
-
-- Use `register_post_type_args` or `register_taxonomy_args` filters to enable `show_in_rest` for types you do not control.
-
-## Discovery links for custom controllers
-
-- If you use a custom controller class, use `rest_route_for_post` or `rest_route_for_term` filters to map objects to routes.

package/.github/skills/wp-rest-api/references/discovery-and-params.md

@@ -1,20 +0,0 @@
-# Discovery and Global Parameters (summary)
-
-## API discovery
-
-- REST API root is discovered via the `Link` header: `rel="https://api.w.org/"`.
-- HTML pages also include a `<link rel="https://api.w.org/" href="...">` element.
-- For non-pretty permalinks, use `?rest_route=/`.
-
-## Global parameters
-
-- `_fields` limits response fields (supports nested meta keys).
-- `_embed` includes linked resources in `_embedded`.
-- `_method` or `X-HTTP-Method-Override` allows POST to simulate PUT/DELETE.
-- `_envelope` puts headers/status in the response body.
-- `_jsonp` enables JSONP for legacy clients.
-
-## Pagination
-
-- Collections accept `page`, `per_page` (1-100), and `offset`.
-- Pagination headers: `X-WP-Total` and `X-WP-TotalPages`.

package/.github/skills/wp-rest-api/references/responses-and-fields.md

@@ -1,30 +0,0 @@
-# Responses and Fields (summary)
-
-## Do not remove core fields
-
-- Removing or changing core fields breaks clients (including wp-admin).
-- Prefer adding new fields or using `_fields` to limit response size.
-
-## register_rest_field
-
-- Use for computed or custom fields.
-- Provide `get_callback`, optional `update_callback`, and `schema`.
-- Register on `rest_api_init`.
-
-## Raw vs rendered content
-
-- For posts, `content.rendered` reflects filters (plugins like ToC inject HTML).
-- Use `?context=edit` (authenticated) to access `content.raw`.
-- Combine with `_fields=content.raw` when you only need the editable body.
-
-## register_meta / register_post_meta / register_term_meta
-
-- Use when the data is stored as meta.
-- Set `show_in_rest => true` to expose under `.meta`.
-- For `object` or `array` types, provide a JSON schema in `show_in_rest.schema`.
-
-## Links and embedding
-
-- Add links with `WP_REST_Response::add_link( $rel, $href, $attrs )`.
-- Use `embeddable => true` to allow `_embed`.
-- Use IANA rels or a custom URI relation; CURIEs can be registered via `rest_response_link_curies`.

package/.github/skills/wp-rest-api/references/routes-and-endpoints.md

@@ -1,36 +0,0 @@
-# Routes and Endpoints (summary)
-
-## Registering routes
-
-- Register routes on the `rest_api_init` hook with `register_rest_route( $namespace, $route, $args )`.
-- A **route** is the URL pattern; an **endpoint** is the method + callback bound to that route.
-- For non-pretty permalinks, the route is accessed via `?rest_route=/namespace/route`.
-
-## Namespacing
-
-- Always namespace routes (`vendor/v1`).
-- **Do not** use the `wp/*` namespace unless you are targeting core.
-
-## Methods
-
-- Use `WP_REST_Server::READABLE` (GET), `CREATABLE` (POST), `EDITABLE` (PUT/PATCH), `DELETABLE` (DELETE).
-- Multiple endpoints can share a route, one per method.
-
-## permission_callback (required)
-
-- Always provide `permission_callback`.
-- Public endpoints should use `__return_true`.
-- For restricted endpoints, use capability checks (`current_user_can`) or object-level authorization.
-- Missing `permission_callback` emits a `_doing_it_wrong` notice in modern WP.
-
-## Arguments
-
-- Register `args` to validate and sanitize inputs.
-- Use `type`, `required`, `default`, `validate_callback`, `sanitize_callback`.
-- Access params via the `WP_REST_Request` object, not `$_GET`/`$_POST`.
-
-## Return values
-
-- Return data via `rest_ensure_response()` or a `WP_REST_Response`.
-- Return `WP_Error` with a `status` in `data` for error responses.
-- Do not call `wp_send_json()` in REST callbacks.

package/.github/skills/wp-rest-api/references/schema.md

@@ -1,22 +0,0 @@
-# Schema and Argument Validation (summary)
-
-## JSON Schema in WordPress
-
-- REST API uses JSON Schema (draft 4 subset) for resource and argument definitions.
-- Provide schema via `get_item_schema()` on controllers or `schema` callbacks on routes.
-- Schema enables discovery (`OPTIONS`) and validation.
-
-## Validation + sanitization
-
-- Use `rest_validate_value_from_schema( $value, $schema )` then `rest_sanitize_value_from_schema( $value, $schema )`.
-- If you override `sanitize_callback`, built-in schema validation will not run; use `rest_validate_request_arg` to keep it.
-- `WP_REST_Controller::get_endpoint_args_for_item_schema()` wires validation automatically.
-
-## Schema caching
-
-- Cache the generated schema on the controller instance (`$this->schema`) to avoid recomputation.
-
-## Formats and types
-
-- Common formats: `date-time`, `uri`, `email`, `ip`, `uuid`, `hex-color`.
-- For `array` and `object` types, you must define `items` or `properties` schemas.

package/.github/skills/wp-wpcli-and-ops/SKILL.md

@@ -1,124 +0,0 @@
----
-name: wp-wpcli-and-ops
-description: "Use when working with WP-CLI (wp) for WordPress operations: safe search-replace, db export/import, plugin/theme/user/content management, cron, cache flushing, multisite, and scripting/automation with wp-cli.yml."
-license: GPL-2.0-or-later
-compatibility: "Targets WordPress 6.9+ (PHP 7.2.24+). Requires WP-CLI in the execution environment."
----
-
-# WP-CLI and Ops
-
-## When to use
-
-Use this skill when the task involves WordPress operational work via WP-CLI, including:
-
-- `wp search-replace` (URL changes, domain migrations, protocol switch)
-- DB export/import, resets, and inspections (`wp db *`)
-- plugin/theme install/activate/update, language packs
-- cron event listing/running
-- cache/rewrite flushing
-- multisite operations (`wp site *`, `--url`, `--network`)
-- building repeatable scripts (`wp-cli.yml`, shell scripts, CI jobs)
-
-## Inputs required
-
-- Where WP-CLI will run (local dev, staging, production) and whether it’s safe to run.
-- How to target the correct site root:
-  - `--path=<wordpress-root>` and (multisite) `--url=<site-url>`
-- Whether this is multisite and whether commands should run network-wide.
-- Any constraints (no downtime, no DB writes, maintenance window).
-
-## Procedure
-
-### 0) Guardrails: confirm environment and blast radius
-
-WP-CLI commands can be destructive. Before running anything that writes:
-
-1. Confirm environment (dev/staging/prod).
-2. Confirm targeting (path/url) so you don’t hit the wrong site.
-3. Make a backup when performing risky operations.
-
-Read:
-- `references/safety.md`
-
-### 1) Inspect WP-CLI and site targeting (deterministic)
-
-Run the inspector:
-
-- `node skills/wp-wpcli-and-ops/scripts/wpcli_inspect.mjs --path=<path> [--url=<url>]`
-
-If WP-CLI isn’t available, fall back to installing it via the project’s documented tooling (Composer, container, or system package), or ask for the expected execution environment.
-
-### 2) Choose the right workflow
-
-#### A) Safe URL/domain migration (`search-replace`)
-
-Follow a safe sequence:
-
-1. `wp db export` (backup)
-2. `wp search-replace --dry-run` (review impact)
-3. Run the real replace with appropriate flags
-4. Flush caches/rewrite if needed
-
-Read:
-- `references/search-replace.md`
-
-#### B) Plugin/theme operations
-
-Use `wp plugin *` / `wp theme *` and confirm you’re acting on the intended site (and network) first.
-
-Read:
-- `references/packages-and-updates.md`
-
-#### C) Cron and queues
-
-Inspect cron state and run individual events for debugging rather than “run everything blindly”.
-
-Read:
-- `references/cron-and-cache.md`
-
-#### D) Multisite operations
-
-Multisite changes can affect many sites. Always decide whether you’re operating:
-
-- on a single site (`--url=`), or
-- network-wide (`--network` / iterating sites)
-
-Read:
-- `references/multisite.md`
-
-### 3) Automation patterns (scripts + wp-cli.yml)
-
-For repeatable ops, prefer:
-
-- `wp-cli.yml` for defaults (path/url, PHP memory limits)
-- shell scripts that log commands and stop on error
-- CI jobs that run read-only checks by default
-
-Read:
-- `references/automation.md`
-
-## Verification
-
-- Re-run `wpcli_inspect` after changes that could affect targeting or config.
-- Confirm intended side effects:
-  - correct URLs updated
-  - plugins/themes in expected state
-  - cron/caches flushed where needed
-- If there’s a health check endpoint or smoke test suite, run it after ops changes.
-
-## Failure modes / debugging
-
-- “Error: This does not seem to be a WordPress installation.”
-  - wrong `--path`, wrong container, or missing `wp-config.php`
-- Multisite commands affecting the wrong site
-  - missing `--url` or wrong URL
-- Search-replace causes unexpected serialization issues
-  - wrong flags or changing serialized data unsafely
-
-See:
-- `references/debugging.md`
-
-## Escalation
-
-- If you cannot confirm environment safety, do not run write operations.
-- If the repo uses containerized tooling (Docker/wp-env) but you can’t access it, ask for the intended command runner or CI job.

package/.github/skills/wp-wpcli-and-ops/references/automation.md

@@ -1,30 +0,0 @@
-# Automation with WP-CLI
-
-Use this file when turning an ops sequence into a repeatable script or CI job.
-
-## `wp-cli.yml`
-
-If the repo uses `wp-cli.yml`, use it to standardize:
-
-- `path:` (WordPress root)
-- `url:` (default site)
-- PHP settings (memory limits)
-
-## Shell scripting
-
-Guardrails for scripts:
-
-- `set -euo pipefail`
-- print commands before running them
-- make destructive operations require an explicit flag (e.g. `--apply`)
-
-## CI jobs
-
-Prefer CI jobs that are read-only by default:
-
-- `wp core version`
-- `wp plugin list`
-- `wp theme list`
-
-Only enable write operations in dedicated deploy/maintenance workflows.
-

package/.github/skills/wp-wpcli-and-ops/references/cron-and-cache.md

@@ -1,23 +0,0 @@
-# Cron, caches, and rewrites
-
-Use this file when debugging background jobs or “changes not visible”.
-
-## Cron
-
-- List scheduled events:
-  - `wp cron event list`
-- Run a specific event now:
-  - `wp cron event run <hook>`
-
-## Cache + rewrite
-
-- Flush object cache:
-  - `wp cache flush`
-- Flush rewrite rules:
-  - `wp rewrite flush`
-
-## Guardrails
-
-- Don’t “run all cron events” on production without understanding impact.
-- Cache flush can cause load spikes; coordinate if needed.
-

package/.github/skills/wp-wpcli-and-ops/references/debugging.md

@@ -1,17 +0,0 @@
-# Debugging WP-CLI
-
-## WP not found / wrong WP root
-
-- Run `wp --info`.
-- Provide `--path=<wordpress-root>` if WP is not in the current directory.
-- Confirm `wp-config.php` exists in the expected root.
-
-## HTTP/URL targeting issues
-
-- On multisite, include `--url=<site-url>` for site-specific actions.
-
-## Permission/file ownership issues
-
-- If running in containers, ensure you’re using the same user/volume mapping as the app.
-- Avoid `--allow-root` unless you understand the environment and have no alternative.
-

package/.github/skills/wp-wpcli-and-ops/references/multisite.md

@@ -1,22 +0,0 @@
-# Multisite targeting
-
-Use this file any time you might be operating on multisite.
-
-## Key flags
-
-- `--url=<site-url>` targets a specific site/blog context.
-- `--network` applies to the network where supported.
-
-## Common commands
-
-- List sites:
-  - `wp site list`
-- Get site options for a specific site:
-  - `wp option get siteurl --url=<site-url>`
-
-## Guardrails
-
-- Always include `--url` when you mean “one site” in a multisite install.
-- If you need to run something across sites, prefer scripting:
-  - list sites → iterate → run a safe per-site command.
-

package/.github/skills/wp-wpcli-and-ops/references/packages-and-updates.md

@@ -1,22 +0,0 @@
-# Plugin/theme operations
-
-Use this file for installs, activation, updates, and listing state.
-
-## Common commands
-
-- Plugins:
-  - `wp plugin list`
-  - `wp plugin status <slug>`
-  - `wp plugin activate <slug>`
-  - `wp plugin deactivate <slug>`
-  - `wp plugin update --all`
-- Themes:
-  - `wp theme list`
-  - `wp theme activate <slug>`
-  - `wp theme update --all`
-
-## Guardrails
-
-- On production, avoid `update --all` without a maintenance window.
-- On multisite, plugin activation may be per-site or network-wide; confirm intent.
-

package/.github/skills/wp-wpcli-and-ops/references/safety.md

@@ -1,30 +0,0 @@
-# Safety rules (WP-CLI)
-
-Use this file before running any write operations.
-
-## Golden rules
-
-- Assume production is **unsafe** unless explicitly confirmed.
-- Always confirm targeting:
-  - `--path` (WordPress root)
-  - `--url` (multisite / specific site targeting)
-- Prefer a backup (`wp db export`) before risky operations.
-- Prefer `--dry-run` where available (especially `search-replace`).
-
-## High-risk commands (require explicit confirmation)
-
-- `wp db reset`
-- `wp db import` (overwrites data)
-- `wp search-replace` (can affect serialized data and URLs)
-- bulk deletes (`wp post delete --force --all`, `wp user delete --reassign`, etc.)
-- plugin/theme mass updates on production
-
-## Logging
-
-For ops scripts, log:
-
-- date/time
-- environment (dev/staging/prod)
-- exact WP-CLI commands
-- exit codes
-

package/.github/skills/wp-wpcli-and-ops/references/search-replace.md

@@ -1,40 +0,0 @@
-# Safe `wp search-replace`
-
-Use this file when migrating domains, switching http→https, or changing paths.
-
-## Recommended workflow
-
-1. Backup:
-   - `wp db export`
-2. Dry run:
-   - `wp search-replace OLD NEW --dry-run`
-3. Run for real (carefully choose scope):
-   - consider `--all-tables-with-prefix` if you need to include non-core tables with the WP prefix
-4. Flush:
-   - `wp cache flush`
-   - `wp rewrite flush`
-
-## Multisite notes
-
-For multisite, decide whether you’re replacing:
-
-- a single site (`--url=...`), or
-- across the network (`--network` or iterating `wp site list`).
-
-Read:
-- `references/multisite.md`
-
-## Common flags
-
-- `--dry-run`
-- `--precise` (slower but can be safer in complex cases)
-- `--skip-columns=...` (avoid touching large/binary columns)
-- `--report-changed-only`
-
-## Serialization caution
-
-WP-CLI search-replace is designed to handle PHP serialized data, but you must still:
-
-- avoid replacing within binary/blob columns
-- validate results with application smoke tests
-

package/.github/skills/wp-wpcli-and-ops/scripts/wpcli_inspect.mjs

@@ -1,90 +0,0 @@
-import { spawnSync } from "node:child_process";
-
-const TOOL_VERSION = "0.1.0";
-
-function parseArgs(argv) {
-  const args = { path: null, url: null, allowRoot: false };
-  for (const a of argv) {
-    if (a === "--allow-root") args.allowRoot = true;
-    if (a.startsWith("--path=")) args.path = a.slice("--path=".length);
-    if (a.startsWith("--url=")) args.url = a.slice("--url=".length);
-  }
-  return args;
-}
-
-function runWp(cmdArgs, { pathArg, urlArg, allowRoot }) {
-  const args = [];
-  if (allowRoot) args.push("--allow-root");
-  if (pathArg) args.push(`--path=${pathArg}`);
-  if (urlArg) args.push(`--url=${urlArg}`);
-  args.push(...cmdArgs);
-
-  const out = spawnSync("wp", args, { encoding: "utf8" });
-  return {
-    ok: out.status === 0,
-    status: out.status,
-    error: out.error ? { message: out.error.message, code: out.error.code } : null,
-    stdout: (out.stdout || "").trim(),
-    stderr: (out.stderr || "").trim(),
-    args,
-  };
-}
-
-function main() {
-  const opts = parseArgs(process.argv.slice(2));
-
-  const info = runWp(["--info"], { pathArg: null, urlArg: null, allowRoot: opts.allowRoot });
-  const report = {
-    tool: { name: "wpcli_inspect", version: TOOL_VERSION },
-    wpCli: {
-      available: info.ok,
-      info,
-    },
-    wordpress: {
-      path: opts.path,
-      url: opts.url,
-      isInstalled: null,
-      coreVersion: null,
-      isMultisite: null,
-      siteurl: null,
-      home: null,
-    },
-    notes: [],
-  };
-
-  if (!info.ok) {
-    report.notes.push("WP-CLI not available on PATH. Install WP-CLI or run inside the intended container/environment.");
-    process.stdout.write(`${JSON.stringify(report, null, 2)}\n`);
-    return;
-  }
-
-  const isInstalled = runWp(["core", "is-installed"], { pathArg: opts.path, urlArg: opts.url, allowRoot: opts.allowRoot });
-  report.wordpress.isInstalled = isInstalled.ok;
-
-  if (!isInstalled.ok) {
-    report.notes.push("WordPress not detected at the given path/url. Check --path/--url (multisite) and that wp-config.php is present.");
-    process.stdout.write(`${JSON.stringify(report, null, 2)}\n`);
-    return;
-  }
-
-  const coreVersion = runWp(["core", "version"], { pathArg: opts.path, urlArg: opts.url, allowRoot: opts.allowRoot });
-  report.wordpress.coreVersion = coreVersion.ok ? coreVersion.stdout : null;
-
-  const isMultisite = runWp(["core", "is-installed", "--network"], {
-    pathArg: opts.path,
-    urlArg: opts.url,
-    allowRoot: opts.allowRoot,
-  });
-  // If network check passes, we can assume multisite. If it fails, it might still be multisite depending on context.
-  report.wordpress.isMultisite = isMultisite.ok;
-
-  const siteurl = runWp(["option", "get", "siteurl"], { pathArg: opts.path, urlArg: opts.url, allowRoot: opts.allowRoot });
-  report.wordpress.siteurl = siteurl.ok ? siteurl.stdout : null;
-
-  const home = runWp(["option", "get", "home"], { pathArg: opts.path, urlArg: opts.url, allowRoot: opts.allowRoot });
-  report.wordpress.home = home.ok ? home.stdout : null;
-
-  process.stdout.write(`${JSON.stringify(report, null, 2)}\n`);
-}
-
-main();