App workflow WordPress

Clone a WordPress site for staging

Use the documented staging/clone path and verify environment separation and indexing settings. 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

An agency must test a plugin upgrade for a live booking site. It needs a staging copy that cannot send real booking mail or accept live payments.

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

Confirm staging eligibility

Where
xCloud production Site overview
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Site ID, plan, backup timestamp
Action
Open the production site overview, confirm Add Staging is offered for this plan, and record current WordPress and plugin versions.
Expected result
A supported staging path and production baseline.
Verify
Check the exact source site ID and latest completed file/database backup.
If it fails
If Add Staging is absent, do not invent an MCP staging-create call; resolve plan eligibility first.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Create a staging environment in xCloud

Step 2 of 5

List copied side effects

Where
WordPress plugins and connected providers
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Payment mode, booking endpoint, SMTP route, webhooks
Action
Inventory plugins that can charge, notify or synchronize outside WordPress. Plan sandbox credentials, mail capture or disabled triggers for the copy.
Expected result
A written isolation checklist before customer data is cloned.
Verify
Have the booking owner sign off on each integration's staging state.
If it fails
If an external endpoint cannot be isolated, exclude that test or use a separate harmless fixture.

Sources: Manage WordPress plugins

Step 3 of 5

Create the staging site

Where
xCloud Site overview → Add Staging
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Source site, staging name and current form inputs
Action
Create staging from the named production site in the dashboard. Wait for the new site to appear, then record both URLs and site IDs.
Expected result
A separate staging environment with a traceable source.
Verify
Compare the staging ID and URL with production; confirm production content has not changed.
If it fails
If the copy stalls, inspect its task status and logs rather than restarting production.

Sources: Create a staging environment in xCloud · xCloud agent capability boundaries

Step 4 of 5

Lock down the copy

Where
Staging WordPress and site access controls
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Test users, indexing choice, sandbox endpoints
Action
Restrict access, inspect WordPress search-engine visibility, replace live payment or mail credentials with test routes, and clear or anonymize unnecessary customer data.
Expected result
Staging can be tested without public indexing or live side effects.
Verify
Submit a test booking and verify it reaches only sandbox recipients and no live charge occurs.
If it fails
If any real notification or charge occurs, disable the integration and investigate before giving testers access.

Sources: WordPress roles and capabilities

Step 5 of 5

Run and document the rehearsal

Where
Staging URL and production comparison
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Selected plugin update and booking cases
Action
Apply the update only on staging, check booking creation, cancellation and notifications, and document differences from production. Keep production unchanged until a separate release approval.
Expected result
Evidence for or against promoting the change.
Verify
Inspect staging version, test records and production version side by side.
If it fails
If staging diverged for unrelated reasons, fix the fixture or repeat on a fresh copy; do not push its database blindly.

Sources: Manage WordPress plugins · Create a staging environment in xCloud

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