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 publishing client is taking over daily editorial 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: Giving every writer administrator access increases incident scope.
Illustrative situation
Illustrative scenario, not a customer case study: A publishing client is taking over daily editorial work. An editor publishes but cannot change infrastructure; a contributor drafts only.
Choose the approach
Verify role boundaries with named accounts before handing over access. 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
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 staff and the actions each role needs
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- List staff and the actions each role needs; exact site identity, named approver and controlled sample data.
- Action
- List editorial staff and their expected actions: draft, edit another author's post, publish and administer plugins.
- Expected result
- A permissions matrix is ready for handover.
- Verify
- A permissions matrix is ready for handover. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If a writer needs hosting access for normal editing, reconsider the workflow.
Sources: WordPress roles and capabilities
Step 2 of 5
Review WordPress roles and existing accounts
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Review wordpress roles and existing accounts; exact site identity, named approver and controlled sample data.
- Action
- Inspect current WordPress accounts and roles, including shared or dormant administrators.
- Expected result
- The owner sees who can change content or site settings.
- Verify
- The owner sees who can change content or site settings. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If an unknown account exists, investigate before adding new users.
Sources: WordPress roles and capabilities
Step 3 of 5
Test draft, review, publish and correction journeys
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Test draft, review, publish and correction journeys; exact site identity, named approver and controlled sample data.
- Action
- Test contributor, author and editor accounts on a draft and correction. Confirm a contributor cannot publish and an editor can.
- Expected result
- Roles match the agreed approval process.
- Verify
- Roles match the agreed approval process. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If capabilities were modified by a plugin, document the effective permission instead of assuming defaults.
Sources: WordPress roles and capabilities
Step 4 of 5
Remove agency-only or stale credentials
- Where
- WordPress or selected plugin administrator
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Remove agency-only or stale credentials; exact site identity, named approver and controlled sample data.
- Action
- Have the authorized administrator remove stale agency credentials and add client-owned accounts only after the client proves access.
- Expected result
- No operational access is stranded.
- Verify
- No operational access is stranded. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If client login fails, restore approved access before revocation.
Sources: WordPress roles and capabilities · WordPress plugin administration
Step 5 of 5
Document approval path and emergency access owner
- Where
- WordPress public/admin views and relevant provider evidence
- Permissions
- Named WordPress/app administrator or business owner; use authorized test accounts.
- Inputs
- Document approval path and emergency access owner; exact site identity, named approver and controlled sample data.
- Action
- Give the client an approval map and emergency contact; run a harmless draft-to-review rehearsal.
- Expected result
- Client staff can publish without agency intervention.
- Verify
- Client staff can publish without agency intervention. Record the observed site, account or transaction and time in the release sheet.
- If it fails
- If the handover test fails, retain a supported transition window.
Sources: WordPress roles and capabilities
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: An editor publishes but cannot change infrastructure; a contributor drafts only. 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
For an access mistake, have the authorized xCloud or WordPress owner correct named roles and retest effective access. Preserve a client-controlled administrator before revoking agency credentials; database restore does not fix xCloud team membership.
xCloud team roles and permissions · WordPress roles and capabilities
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 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: Test contributor, author and editor accounts on a draft and correction. Confirm a contributor cannot publish and an editor can.
- The business owner compares the controlled sample with this observable result: No operational access is stranded.
- 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): An editor publishes but cannot change infrastructure; a contributor drafts only. Remove agency-only or stale credentials
- recovery (covered): Giving every writer administrator access increases incident scope. Document approval path and emergency access owner
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
- Manage WordPress updates with Updates Manager
- Vulnerability Checker in xCloud
- xCloud team roles and permissions