MainWP Docs

Appearance

Update Pipeline Workflow ​

Fresh

A structured pipeline for safely testing and deploying updates across your WordPress fleet.

Pipeline Stages ​

Stage 0: Detect Updates ​

Run sync across all sites to detect available updates:

bash
# Sync all sites
curl -X POST -u "admin:xxxx" \
  -H "Content-Type: application/json" \
  -d '{"input":{"site_ids":"all"}}' \
  "https://dashboard.com/wp-json/wp-abilities/v1/abilities/mainwp/sync-sites-v1/run"

# List all available updates
curl -u "admin:xxxx" \
  "https://dashboard.com/wp-json/wp-abilities/v1/abilities/mainwp/list-updates-v1/run"

Stage 1: Canary Sites (1-3 sites) ​

Canary sites are low-risk sites used to test updates before wider deployment.

Setup Canary Group ​

Tag 1-3 sites as "Canary":

  • Choose sites that are representative of your fleet
  • Prefer staging sites or low-traffic production sites
  • Ensure they have the same plugins/themes as critical sites

Apply Updates to Canary ​

bash
# Update canary sites only
curl -X POST -u "admin:xxxx" \
  -H "Content-Type: application/json" \
  -d '{"input":{"site_ids":[101,102,103]}}' \
  "https://dashboard.com/wp-json/wp-abilities/v1/abilities/mainwp/run-updates-v1/run"

Verify Canary Sites ​

Wait 24 hours, then check:

  • [ ] Sites load correctly
  • [ ] No PHP errors in debug log
  • [ ] Key functionality works (forms, checkout, etc.)
  • [ ] Uptime monitoring shows no downtime
  • [ ] Performance metrics stable

Stage 2: Non-Critical Sites ​

If canary sites pass, deploy to non-critical production sites:

bash
# Update non-critical group
curl -X POST -u "admin:xxxx" \
  -H "Content-Type: application/json" \
  -d '{"input":{"site_ids":[201,202,203,204,205]}}' \
  "https://dashboard.com/wp-json/wp-abilities/v1/abilities/mainwp/run-updates-v1/run"

Verify ​

Wait 4-8 hours, then verify same checklist as canary.

Stage 3: Critical Sites ​

If non-critical sites pass, deploy to high-value production sites:

  1. Backup all critical sites first
  2. Apply updates during low-traffic window
  3. Monitor closely for 24 hours
bash
# Update critical group
curl -X POST -u "admin:xxxx" \
  -H "Content-Type: application/json" \
  -d '{"input":{"site_ids":[301,302,303]}}' \
  "https://dashboard.com/wp-json/wp-abilities/v1/abilities/mainwp/run-updates-v1/run"

Rollback Procedure ​

If any stage fails:

  1. Identify the problematic update
  2. Rollback affected sites from backup
  3. Add to ignore list to prevent re-application:
    bash
    curl -X POST -u "admin:xxxx" \
  -H "Content-Type: application/json" \
  -d '{"input":{"type":"plugins","slug":"problem-plugin","action":"ignore"}}' \
  "https://dashboard.com/wp-json/wp-abilities/v1/abilities/mainwp/set-ignored-updates-v1/run"
  4. Report the issue to the plugin/theme developer
  5. Re-test when a fix is released

Automation Tips ​

Scheduled Pipeline ​

Use WP-Cron or system cron to automate:

  • Monday 2 AM — Sync all sites, detect updates
  • Monday 3 AM — Apply to canary sites
  • Tuesday 3 AM — If canary passed, apply to non-critical
  • Wednesday 3 AM — If non-critical passed, apply to critical
  • Thursday — Review all sites, generate update report

MCP Integration ​

With the MCP Server, you can build conversational update management:

You: "What updates are available across all sites?"
MCP: "Found 15 plugin updates, 3 theme updates, 2 core updates..."
You: "Apply plugin updates to canary sites first"
MCP: "Updated 3 canary sites. Monitoring..."