Requirements and responsibilities
Have named ownership of the domain, selected xCloud team and site, and WordPress administrator access. For this scenario, agree who supplies the data and signs off: A retailer has just promoted a theme change and needs proof that orders still work.
xCloud agent capability boundaries · WordPress roles and capabilities
Use a compatible Nginx or OpenLiteSpeed stack for native WordPress. Verify current server resources, plan eligibility and each selected plugin or service license and requirements before installing; a Docker server does not host a new native WordPress site.
xCloud agent capability boundaries · WordPress plugin administration
Prepare a safe test identity and a completed, accessible backup before consequential changes. The important failure to plan around is: A green home page says little about checkout health.
Illustrative situation
Illustrative scenario, not a customer case study: A retailer has just promoted a theme change and needs proof that orders still work. A test order has the expected total, status, stock movement and notifications.
Choose the approach
Test a safe payment method or gateway sandbox before accepting campaign traffic. Verify the selected provider or plugin documentation and license against this requirement; xCloud hosting does not supply its business configuration.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · WordPress roles and capabilities · xCloud WooCommerce hosting
Keep application setup, domain/DNS ownership, mail delivery and external integrations with their named administrators. Use a plain documented path when a proposed integration cannot be demonstrated end to end.
xCloud agent capability boundaries · WordPress plugin administration
Dashboard and application procedure
Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.
Step 1 of 5
Record the change, order baseline and gateway test mode
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Record the change, order baseline and gateway test mode; exact site identity, named approver and controlled sample data.
- Action
- Record released theme or plugin version, last good live order and an isolated staging/gateway sandbox with the store owner. Never switch a live gateway to test mode merely for this check.
- Expected result
- The test has a known release and starting order state.
- Verify
- The test has a known release and starting order state. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If no safe test environment exists, use a provider-documented production-safe procedure approved by the store owner.
Sources: WordPress roles and capabilities · WooCommerce testing orders · xCloud WooCommerce hosting
Step 2 of 5
Open product, cart and checkout in separate sessions
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Open product, cart and checkout in separate sessions; exact site identity, named approver and controlled sample data.
- Action
- On the isolated copy open a representative product, add it to cart and move through shipping and checkout; repeat with a logged-in customer. Observe the live storefront separately.
- Expected result
- Both test sessions display their own cart and expected item.
- Verify
- Both test sessions display their own cart and expected item. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If cart data leaks or changes between sessions, suspend the risky cache or theme setting.
Sources: WordPress roles and capabilities · WooCommerce testing orders · xCloud WooCommerce hosting
Step 3 of 5
Place a sandbox order with shipping and tax cases
- Where
- WooCommerce administrator and payment gateway sandbox
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Place a sandbox order with shipping and tax cases; exact site identity, named approver and controlled sample data.
- Action
- On the isolated copy place a sandbox order using configured shipping and tax, then a rejected payment if supported. Do not generate fake live orders.
- Expected result
- Only the successful sandbox test produces the expected test order state.
- Verify
- Only the successful sandbox test produces the expected test order state. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If WooCommerce and gateway disagree, investigate webhooks before marking checkout healthy.
Sources: WooCommerce testing orders · WordPress plugin administration · xCloud WooCommerce hosting
Step 4 of 5
Compare order record, stock and customer email
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Compare order record, stock and customer email; exact site identity, named approver and controlled sample data.
- Action
- Compare order total, stock decrement, customer mail and staff notice in application and provider records.
- Expected result
- Staff can fulfill the paid test while rejected payment did not reduce stock incorrectly.
- Verify
- Staff can fulfill the paid test while rejected payment did not reduce stock incorrectly. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If notification is absent but order exists, handle the order manually and repair mail separately.
Sources: WordPress roles and capabilities · WooCommerce testing orders · xCloud WooCommerce hosting
Step 5 of 5
Approve launch or revert with newer orders preserved
- Where
- WordPress or selected plugin administrator
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Approve launch or revert with newer orders preserved; exact site identity, named approver and controlled sample data.
- Action
- Sign off with the store owner and record a rollback choice that preserves orders created after release.
- Expected result
- The owner knows whether sales can continue and what data recovery risks exist.
- Verify
- The owner knows whether sales can continue and what data recovery risks exist. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If a real order arrived since backup, do not restore the old database without reconciliation.
Sources: WordPress roles and capabilities · WordPress plugin administration · WooCommerce testing orders · xCloud WooCommerce hosting
Maintenance
Assign a cadence for selected WordPress core, theme and plugin updates, review version-based findings and retest the path in this guide. In particular, repeat: A test order has the expected total, status, stock movement and notifications. A chat prompt is not a scheduled task.
Manage WordPress updates with Updates Manager · Vulnerability Checker in xCloud
Record actual backup completion, storage access and responsible staff. Recheck connected application and provider behavior after changes rather than relying on a site health status alone.
Recovery decisions
Before restoring, compare the chosen recovery point with newer business records. A green home page says little about checkout health. Use the xCloud dashboard for native restore only after the owner approves target and scope; reconcile or preserve newer data first.
Validate the restored copy with representative content, authentication, HTTPS and this guide’s business acceptance test before moving traffic or closing the incident.
AI handoff
Connect xCloud MCP through the current documented profile and grant only the scopes needed for the selected team. Discover tool schemas first. Read resources to plan; require approval for any supported write. Use returned dashboard URLs for manual work. The packaged REST wrapper accepts GET requests only.
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
- Review a WordPress business journey app · manual
Application data and observed transactions cannot be inferred from xCloud resource reads. Use authorized test accounts and the application or provider evidence.
Checkpoint: Record the test identity, timestamp, expected outcome, observed result and owner decision.
- Configure and test application behavior app · manual
xCloud hosting operations do not configure WooCommerce checkout, n8n workflows, Nextcloud sharing policy or application users.
Checkpoint: An application administrator verifies each real business journey and records observed outcomes.
WooCommerce testing orders · n8n Webhook node and test/production URLs · Nextcloud file sharing administration · xCloud agent capability boundaries
- Configure WordPress content, users and selected plugins app · manual
Requires a named WordPress administrator or suitable editor. Plugin behavior, commercial license, payment, email and external integration are verified in the chosen vendor documentation and application; xCloud hosting or MCP reads do not configure them.
Checkpoint: Open the actual WordPress or selected plugin interface, record the version and role, and have the business owner accept a real user journey.
WordPress roles and capabilities · WordPress plugin administration
Copyable agent brief
Manual checkpoints
- The named WordPress, app, dashboard or provider administrator performs the guide’s actual configuration step: On the isolated copy place a sandbox order using configured shipping and tax, then a rejected payment if supported. Do not generate fake live orders.
- The business owner compares the controlled sample with this observable result: Staff can fulfill the paid test while rejected payment did not reduce stock incorrectly.
- Staging push/pull, native backup schedules, restores and cache-setting edits require the authorized xCloud dashboard operator; the packaged REST wrapper is GET-only.
Feature coverage
- business-acceptance (covered): A test order has the expected total, status, stock movement and notifications. Compare order record, stock and customer email
- recovery (covered): A green home page says little about checkout health. Approve launch or revert with newer orders preserved
Sources
- xCloud agent capability boundaries
- WordPress roles and capabilities
- WordPress plugin administration
- Site backups in xCloud
- WordPress hardening handbook
- xCloud MCP documentation and connection profiles
- xCloud WooCommerce hosting
- Manage WordPress updates with Updates Manager
- Vulnerability Checker in xCloud
- WooCommerce testing orders
- n8n Webhook node and test/production URLs
- Nextcloud file sharing administration