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 membership release changes a protected template.
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: Cached pages can expose protected content across sessions.
Before any database copy or restore starts, the authorized operator restricts the target and quarantines outbound mail, payment, fulfillment and other provider effects. Restored settings may overwrite plugin suppression; reapply sandbox credentials and verify isolation before testing.
Create a staging environment in xCloud · Site backups in xCloud
Illustrative situation
Illustrative scenario, not a customer case study: A membership release changes a protected template. Active member sees content; canceled visitor and anonymous user do not.
Choose the approach
Test access states with independent accounts after the release. 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 · Create a staging environment in xCloud
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
List roles, entitlements and protected urls
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- List roles, entitlements and protected urls; exact site identity, named approver and controlled sample data.
- Action
- List protected URLs and active, expired and anonymous test identities with their expected entitlements.
- Expected result
- A release has positive and negative access cases.
- Verify
- A release has positive and negative access cases. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If no expired account exists, create a safe test account in the application first.
Sources: WordPress roles and capabilities · Paid Memberships Pro initial setup and payment gateway planning · Create a staging environment in xCloud
Step 2 of 5
Copy representative data to eligible staging safely
- Where
- xCloud Staging Management dashboard
- Permissions
- Named xCloud team/site administrator; confirm target and scope.
- Inputs
- Copy representative data to eligible staging safely; exact site identity, named approver and controlled sample data.
- Action
- Confirm a backup and use eligible staging with controlled member data and mail settings.
- Expected result
- The change can be tested without changing live access.
- Verify
- The change can be tested without changing live access. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If production data is copied, restrict staging and avoid real billing events.
Sources: Create a staging environment in xCloud · xCloud agent capability boundaries · Paid Memberships Pro initial setup and payment gateway planning
Step 3 of 5
Apply selected template or plugin change
- Where
- WordPress or selected plugin administrator
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Apply selected template or plugin change; exact site identity, named approver and controlled sample data.
- Action
- Apply the approved template or membership plugin change in WordPress staging; record exact version and rules changed.
- Expected result
- Staging reflects only the intended release.
- Verify
- Staging reflects only the intended release. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If the plugin requires an undocumented paid extension, stop and verify licensing.
Sources: WordPress roles and capabilities · WordPress plugin administration · Paid Memberships Pro initial setup and payment gateway planning · Create a staging environment in xCloud
Step 4 of 5
Test entitled and unentitled accounts
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Test active, expired and anonymous sessions; exact site identity, named approver and controlled sample data.
- Action
- Use separate active member, expired or otherwise unentitled, and anonymous accounts. For a canceled account, first inspect whether the chosen membership policy grants access through the paid term; test against that documented rule.
- Expected result
- Each account sees only the content allowed by its actual entitlement state.
- Verify
- Each account sees only the content allowed by its actual entitlement state. Record the exact account or record tested, result, and time with the responsible owner.
- If it fails
- If protected material leaks, do not promote and inspect cache/exclusion rules.
Sources: WordPress roles and capabilities · Paid Memberships Pro initial setup and payment gateway planning · Create a staging environment in xCloud
Step 5 of 5
Release and watch access errors without restoring over new members
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Release and watch access errors without restoring over new members; exact site identity, named approver and controlled sample data.
- Action
- After release repeat the access matrix on production and compare new memberships with backup time before considering rollback.
- Expected result
- Member access remains correct with newer records preserved.
- Verify
- Member access remains correct with newer records preserved. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If a restore would lose signups, choose a forward fix or owner-approved reconciliation.
Sources: WordPress roles and capabilities · Paid Memberships Pro initial setup and payment gateway planning · Create a staging environment in xCloud
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: Active member sees content; canceled visitor and anonymous user do not. 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. Cached pages can expose protected content across sessions. 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.
- Create and synchronize WordPress staging dashboard · manual
WordPress staging requires an eligible paid plan. The API staging-create operation is for Git sites.
Checkpoint: Use Site overview → Add Staging and staging Site → Manage Staging. Inspect push/pull scope before overwriting data.
- 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: Apply the approved template or membership plugin change in WordPress staging; record exact version and rules changed.
- The business owner compares the controlled sample with this observable result: Each account sees only the content allowed by its actual entitlement state.
- 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): Active member sees content; canceled visitor and anonymous user do not. Test entitled and unentitled accounts
- recovery (covered): Cached pages can expose protected content across sessions. Release and watch access errors without restoring over new members
Sources
- xCloud agent capability boundaries
- WordPress roles and capabilities
- WordPress plugin administration
- Site backups in xCloud
- WordPress hardening handbook
- Create a staging environment in xCloud
- xCloud MCP documentation and connection profiles
- Manage WordPress updates with Updates Manager
- Vulnerability Checker in xCloud
- Paid Memberships Pro initial setup and payment gateway planning