Operations WooCommerce + WordPress

Review WooCommerce restore impact on recent orders

Compare backup time with order activity and plan reconciliation before restoring. Check the named site's prerequisites, task result, backup scope and recovery handoff with xCloud.

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

A WooCommerce store considers restoring yesterday’s database after a plugin failure, but new paid orders and refunds exist. The owner needs to quantify and preserve them first.

Choose the approach

Dashboard and application procedure

Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.

Step 1 of 5

Pin recovery time

Where
WooCommerce Orders and xCloud backup history
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Candidate snapshot, latest order ID, incident start
Action
Record backup time, current order IDs/statuses, payment captures, refunds and stock changes after snapshot.
Expected result
A precise post-backup transaction list.
Verify
Match sample WooCommerce orders to gateway ledger.
If it fails
If gateway access is unavailable, do not approve database restore.

Sources: WooCommerce order review and management

Step 2 of 5

Determine damage scope

Where
Plugin logs and storefront checks
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Checkout error, database integrity, affected component
Action
Test whether the failure is code, setting or data. Identify whether reverting a plugin can restore checkout without replacing orders.
Expected result
A least-destructive recovery option.
Verify
Try reproduction on staging using sandbox payment.
If it fails
If data is intact, choose targeted code repair.

Sources: WooCommerce order review and management · xCloud restore a WordPress backup to another site

Step 3 of 5

Preserve newer state

Where
Current-state backup and WooCommerce Orders
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Orders/refunds, customers, stock, gateway IDs
Action
Create a current backup, then use the site's documented order export extension if installed or produce a restricted manual ledger of all post-snapshot records with payment references. Hold live checkout only as long as needed.
Expected result
A reconciliation bundle before destructive action.
Verify
Count records and verify backup Completed.
If it fails
If export or backup fails, stop the database restore proposal.

Sources: Site backups in xCloud · xCloud agent capability boundaries · WooCommerce order review and management · WooCommerce order export extension procedure

Step 4 of 5

Rehearse on a separate target

Where
Isolated WordPress destination
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Old snapshot, safe host, newer transaction ledger
Action
Quarantine destination mail, payment, webhooks and public traffic before the restored app can run. Restore the old snapshot to that target, reapply sandbox credentials before any test, then compare its order ledger with preserved new transactions.
Expected result
A measured gap and reconciliation plan.
Verify
Match old and new order IDs and payment statuses.
If it fails
If reconciliation is ambiguous, seek commerce specialist review; do not assume an import is lossless.

Sources: xCloud restore a WordPress backup to another site · Site backups in xCloud · xCloud agent capability boundaries · WooCommerce order review and management

Step 5 of 5

Approve and reconcile

Where
Production change record and WooCommerce
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Selected repair, customer impact, owner approval
Action
Apply the least destructive approved repair. If database replacement is unavoidable, reconcile payment/order/stock data before reopening checkout.
Expected result
A functioning store with complete ledger.
Verify
Place a production-safe check and compare new order to gateway.
If it fails
If totals diverge, keep checkout paused and investigate before customer traffic resumes.

Sources: WooCommerce order review and management

Maintenance

Recovery decisions

AI handoff

Connect an authorized xCloud MCP profile and discover its exact tools and team scope. The packaged REST wrapper is GET-only; use dashboard or app controls for undocumented writes.

Supported scope

  • Confirm requirements and inspect resources mcp · read

    Discover the connected profile and operation schema first; only teams granted to the connection are visible.

    Checkpoint: Confirm exact team, server and site identity. Use dashboard_url returned by the resource; do not invent a dashboard link.

    Operation identifiers and scopes to discover

    teams.index, servers.show, sites.show

    Scopes: read:servers, read:sites

    xCloud MCP documentation and connection profiles · xCloud agent capability boundaries

Copyable agent brief

Manual checkpoints

  • Approve exact site, target, cost and any write or maintenance window after inspecting the proposed plan.
  • An authorized WordPress administrator must configure and test app users, content, integrations and business rules in the app.
  • Native WordPress staging, backup schedule/settings, push/pull and all restores are dashboard-only; Docker restore is dashboard-only and replaces state.
  • Reconcile data created after the chosen recovery point before any destructive restore.
Feature coverage

Sources

Continue

Explore all use cases