---
name: wordpress-weekly-maintenance
description: Use when asked to run weekly maintenance on a WordPress site connected via Cowboy MCP — checks for updates, verifies site health, reviews error logs and the audit trail, and applies updates safely with a database checkpoint first.
---

# WordPress weekly maintenance

Run a safe, repeatable weekly pass over a WordPress site through Cowboy MCP. Read the site's state first, take a checkpoint, apply updates one at a time, then confirm nothing broke. Never skip the checkpoint, and never batch every plugin into one update call.

## Before you start

1. Confirm safe mode is on and the connection is healthy: call `wp_site_info` and, if anything looks off, `wp_connection_doctor`.
2. Create a database checkpoint with `wp_create_checkpoint` (label it "weekly-maintenance").
3. Verify it exists: call `wp_list_checkpoints` and confirm the new checkpoint id and label are listed before making any change.

## Steps

1. **Health baseline.** Call `wp_site_health` (read-only) and record the summary counts (good / recommended / critical).
2. **Error log.** Call `wp_get_php_error_log` (read-only). Note any recurring fatal errors or warnings.
3. **Database health.** Call `wp_db_health_report` (read-only): post revisions, spam/trashed comments, transient count, and autoloaded-options size.
4. **Audit trail.** Call `cowboy_mcp_get_audit_log` to review what agents did since the last run, and `wp_list_changes` to see the undo journal.
5. **Find updates.** Call `wp_list_plugins` and `wp_list_themes` (read-only) and list every item with a pending update.
6. **Apply updates one at a time.** For each plugin, call `wp_update_plugin` with `dry_run: true` first to resolve the real plan (target version and download source), then call it again for that single slug to apply. Do the same with `wp_update_theme`. Each update takes a file backup and checkpoint, runs a post-update health check, and auto-restores the old version if the site breaks. Update core last via `wp_cli` (`core update`) if one is pending.
7. **Optional cleanup.** If `wp_db_health_report` flagged a large transient backlog, clear expired transients with `wp_get_transients` using `dry_run: true` first, then apply.
8. **Re-verify.** Call `wp_site_health` and `wp_get_php_error_log` again and compare against the baseline from steps 1–2.

## Notes

- `dry_run` applies to write tools only. Read-only tools (`wp_site_health`, `wp_list_plugins`, `wp_get_php_error_log`, the audit and journal tools) reject `dry_run` — call them directly.
- On large sites, update a few plugins per call at most to stay within PHP time limits; never fire one update call for everything.
- If an update leaves the site up but misbehaving, roll back that single change with `wp_undo_change` before moving to the next item, so you never stack two unverified updates.

## Report format

Summarize back to the site owner:
- Health before vs. after (the summary counts).
- Each plugin, theme, or core update applied, with target versions — and anything auto-restored.
- Errors found in the log and whether they are new or recurring.
- The checkpoint id, so a full rollback is one `wp_restore_checkpoint` away. Individual updates roll back with `wp_undo_change`.
- Anything you skipped and why, and anything that needs the owner's decision.