Wp Wpcli And Ops
- 3.1k installs
- 2k repo stars
- Updated August 3, 2026
- wordpress/agent-skills
wp-wpcli-and-ops is a WordPress skill for safe WP-CLI search-replace, DB ops, plugins, cron, cache, and multisite automation.
About
WP-CLI and Ops guides WordPress operational tasks via WP-CLI with guardrails for environment confirmation, path and URL targeting, and backup before destructive writes. Covered workflows include safe search-replace with dry-run then export backup, plugin and theme install or update, cron inspection and single-event runs, cache and rewrite flushing, multisite site and network operations, and repeatable automation with wp-cli.yml plus shell scripts. The procedure starts with wpcli_inspect.mjs to verify WP-CLI availability and site targeting, then routes to reference docs for search-replace, packages, cron, multisite, automation, safety, and debugging. Multisite work requires explicit --url for single sites or --network for network-wide commands. Verification reruns inspect after config changes and confirms URLs, package state, and cron or cache effects. Failure modes include wrong path targeting, missing wp-config, serialization issues from unsafe search-replace, and multisite commands hitting the wrong site URL.
- Environment and blast-radius guardrails before write commands.
- wpcli_inspect.mjs for deterministic WP-CLI and site targeting.
- Safe search-replace sequence with db export and dry-run.
- Multisite --url and --network targeting guidance.
- Automation patterns with wp-cli.yml and CI read-only defaults.
Wp Wpcli And Ops by the numbers
- 3,097 all-time installs (skills.sh)
- +164 installs in the week ending Aug 5, 2026 (Skillselion tracking)
- Ranked #51 of 1,435 DevOps & CI/CD skills by installs in the Skillselion catalog
- Security screen: MEDIUM risk (skills.sh audit)
- Data as of Aug 5, 2026 (Skillselion catalog sync)
wp-wpcli-and-ops capabilities & compatibility
- Capabilities
- wp cli environment inspection script · safe search replace with backup and dry run · plugin and theme package operations · cron and cache management commands · multisite url and network targeting · automation via wp cli.yml and shell scripts
- Use cases
- devops · ci cd
- Pricing
- Free
What wp-wpcli-and-ops says it does
WP-CLI commands can be destructive. Before running anything that writes:
node skills/wp-wpcli-and-ops/scripts/wpcli_inspect.mjs --path=<path>
npx skills add https://github.com/wordpress/agent-skills --skill wp-wpcli-and-opsAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 3.1k |
|---|---|
| repo stars | ★ 2k |
| Security audit | 3 / 3 scanners passed |
| Last updated | August 3, 2026 |
| Repository | wordpress/agent-skills ↗ |
How do I run WP-CLI operations without hitting the wrong site or skipping backups on destructive changes?
Run safe WordPress operations with WP-CLI including search-replace, DB export, plugins, cron, cache, and multisite automation.
Who is it for?
WordPress operators running migrations, plugin updates, cron debugging, or multisite maintenance via WP-CLI.
Skip if: Skip for greenfield theme development without WP-CLI or non-WordPress stacks.
When should I use this skill?
User runs wp search-replace, db export, plugin ops, cron, cache flush, or multisite commands.
What you get
Verified WP-CLI targeting, completed ops workflow, and post-change smoke checks.
- Executed wp-cli command logs
- Migrated or exported SQL databases
By the numbers
- Targets WordPress 6.9+ on PHP 7.2.24+
Files
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.ymlfor 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_inspectafter 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 missingwp-config.php - Multisite commands affecting the wrong site
- missing
--urlor 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.
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 versionwp plugin listwp theme list
Only enable write operations in dedicated deploy/maintenance workflows.
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.
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.phpexists 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-rootunless you understand the environment and have no alternative.
Multisite targeting
Use this file any time you might be operating on multisite.
Key flags
--url=<site-url>targets a specific site/blog context.--networkapplies 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
--urlwhen 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.
Plugin/theme operations
Use this file for installs, activation, updates, and listing state.
Common commands
- Plugins:
wp plugin listwp plugin status <slug>wp plugin activate <slug>wp plugin deactivate <slug>wp plugin update --all- Themes:
wp theme listwp theme activate <slug>wp theme update --all
Guardrails
- On production, avoid
update --allwithout a maintenance window. - On multisite, plugin activation may be per-site or network-wide; confirm intent.
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-runwhere available (especiallysearch-replace).
High-risk commands (require explicit confirmation)
wp db resetwp 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
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-prefixif you need to include non-core tables with the WP prefix
4. Flush:
wp cache flushwp rewrite flush
Multisite notes
For multisite, decide whether you’re replacing:
- a single site (
--url=...), or - across the network (
--networkor iteratingwp 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
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();
Related skills
Azure DeploySafely execute production deployments of already-prepared applications to Microsoft Azure.485k1.3kAzure ValidateRun deep pre-deployment checks on Azure configuration, infrastructure definitions, RBAC roles, and managed identities before pushing to production.485k1.3k
Github Actions DocsGet precise, docs-grounded answers about GitHub Actions workflows, syntax, security, and migration instead of relying on stale knowledge.275k72
Setup Pre CommitAutomatically run Prettier, type checking, and tests on every commit via Husky and lint-staged.170k199k
Deploy To VercelSafely turn any local project into a live Vercel preview with one instruction.99.3k29.7kVercel Cli With TokensDeploy projects to Vercel from agents and scripts using token authentication instead of interactive browser login.74.6k29.7kForks & variants (1)
Wp Wpcli And Ops has 1 known copy in the catalog totaling 1 installs. They canonicalize to this original listing.
- dobriclilujun - 1 installs
How it compares
Pick wp-wpcli-and-ops for live WordPress operational commands instead of block theme or Gutenberg block development skills.
FAQ
What run before search-replace?
Export the database, run search-replace --dry-run, then execute the real replace with correct flags.
Why use wpcli_inspect first?
It confirms WP-CLI availability and correct path or URL targeting before writes.
How avoid multisite mistakes?
Pass --url for a single site or --network only when network-wide impact is intended.
Is Wp Wpcli And Ops safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.