Bulk Price Updates with Undo

Identify the product set

Decide which products are in scope. Ask your AI to build the ID list from a category, tag, price range, or SKU pattern:

Get all products in category "Summer 2025 Collection" using wc_get_products. Give me the array of product IDs and their current regular_price + sale_price.

Or if you already have the IDs from a spreadsheet, skip this step and go to step 2.

Compute new prices (client-side, in the AI)

Have your AI apply the campaign math to each product and build the updates array:

For each of those products, compute a new sale_price at 12% off the regular_price rounded to .99 (e.g. regular $50 → sale $43.99). Build me the updates array for wc_bulk_price_update.

The output will look like:

updates: [
  { "product_id": 42, "sale_price": "43.99" },
  { "product_id": 108, "sale_price": "26.39" },
  { "product_id": 143, "sale_price": "17.59" },
  ...
]

Dry-run the price update

Call wc_bulk_price_update with dry_run: true. Nothing is written — you get back the list of products that would be touched, plus which would be skipped or errored:

Preview the price update with wc_bulk_price_update dry_run=true using the updates array above.

Response shape:

{
  "isError": false,
  "content": [
    { "type": "text", "text": "Updated prices on 47 products (0 skipped, 0 errors) [dry-run]." }
  ],
  "structuredContent": {
    "updated": [42, 108, 143, ...],
    "skipped": [],
    "errors": [],
    "dry_run": true,
    "updated_count": 47,
    "skipped_count": 0,
    "errors_count": 0
  }
}

If anything appears in skipped or errors, review before committing. Common reasons:

• skipped: [{ id, reason: "insufficient_caps" }] — the acting user doesn't have edit_post on that product
• skipped: [{ id, reason: "no_price_fields" }] — the update row didn't include regular_price OR sale_price (at least one is required)
• errors: [{ id, reason: "not_found" }] — product ID doesn't exist
• errors: [{ id: 0, reason: "invalid_product_id" }] — malformed row missing product_id

Commit the campaign

Once the dry-run looks clean, call the tool again with dry_run: false:

Commit the price update with wc_bulk_price_update dry_run=false using the same updates array.

What happens per product on the server:

• The tool snapshots the current regular_price and sale_price BEFORE mutating (line-level guarantee: the undo payload reflects true pre-state, not a race).
• If regular_price is in the row, $product->set_regular_price() is called.
• If sale_price is in the row, $product->set_sale_price() is called (passing null deletes the sale price and reverts to regular).
• $product->save() commits.
• wc_delete_product_transients($pid) fires so cached shop/category displays refresh.

The response includes a 72-hour undo token you'll need for step 5:

{
  "isError": false,
  "content": [{ "type": "text", "text": "Updated prices on 47 products (0 skipped, 0 errors)." }],
  "structuredContent": {
    "updated": [42, 108, 143, ...],
    "skipped": [],
    "errors": [],
    "dry_run": false,
    "updated_count": 47,
    "skipped_count": 0,
    "errors_count": 0
  },
  "undo": {
    "token": "<64-character-hex-token>",
    "expires_at": "2026-08-08T14:23:15Z",
    "ttl_hours": 72
  }
}

Save the undo token somewhere durable. Paste it into your project notes, a Slack DM to yourself, whatever. You'll need it for step 5 — and you have 72 hours before it expires.

Verify on the storefront

Load the actual shop / category pages in an incognito browser (bypass logged-in admin caching) and check:

• Sale prices render on product cards (regular price shown struck-through, sale price highlighted)
• Cart / checkout math uses the new prices
• Product structured data (view page source, look for schema.org/Product) reflects the new prices — important for Google Shopping / SERP snippets
• Any active FB/Google product catalog sync picks up the new prices on next sync (usually within 24hr)

If prices don't render but the tool response said success:

• Purge any page-cache plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache) — the tool fires wc_delete_product_transients but page caches are a separate layer
• Purge CDN cache (Cloudflare, BunnyCDN, etc.)
• If using ForgeCache Pro, ask your AI to run fc_purge_url or fc_clear_cache

End the campaign — undo OR set-back

Two paths depending on how long the campaign ran:

Path A: Short campaign, still within 72h

Call royal_mcp_undo_last_operation with the token from step 4:

Undo the price campaign with royal_mcp_undo_last_operation using token <64-character-hex-token>.

The undo_restore_product_meta handler loops through every snapshotted product and restores the prior regular_price + sale_price per product exactly. One call, campaign fully reverted.

Path B: Long campaign, past the 72h window

The undo token has expired. Path back: re-run wc_bulk_price_update with the original prices, passing them explicitly. If you captured the original prices in step 1 (asking the AI for current prices at the start of the workflow), those values are still in your chat transcript. Re-issue the same tool call structure:

updates: [
  { "product_id": 42, "regular_price": "50.00", "sale_price": "" },
  { "product_id": 108, "regular_price": "30.00", "sale_price": "" },
  ...
]

Passing sale_price: "" or sale_price: null deletes the sale price and reverts the product to displaying its regular price only. This "re-run in reverse" is not as clean as the undo path but works past the TTL window.