Requirements and responsibilities
Confirm team/site permissions, current versions, the affected plugin’s release notes and compatibility with WordPress, PHP and dependent extensions. Identify a maintainer who can interpret failures.
Manage WordPress core, themes and plugins · xCloud agent capability boundaries
Prepare an eligible paid WordPress staging environment through the dashboard and a completed recoverable backup before a production change. Stage representative data without exposing customer records or sending real customer mail.
Record the actual automatic-update mechanism. WordPress-native settings and xCloud scanner-related update/backup controls are distinct; inspect each before planning a manual change.
WordPress native automatic update settings · Vulnerability Checker in xCloud
Illustrative situation
Illustrative scenario: an agency maintains a WordPress booking site with a plugin security update available. The goal is to fix the affected version while preserving customer bookings and proving the booking and email paths still work.
Choose the approach
Use a small selected update set when several components change. Separate unrelated feature changes from the security fix so failed business tests have an identifiable cause.
Manage WordPress updates with Updates Manager · Manage WordPress core, themes and plugins
Where remediation is unavailable, record the affected functionality, exposure, owner and next review. Evaluate vendor guidance and optional Site Security PRO protections; do not equate mitigation, patching and malware cleanup.
Vulnerability Checker in xCloud · Site Security PRO setup and eligibility
Dashboard and application procedure
Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.
Step 1 of 7
Identify the exact site and proposed changes
- Where
- xCloud top-right menu → Updates Manager; Plugins, Themes, WordPress Core
- Permissions
- Authorized site administrator; confirm the selected team and site.
- Inputs
- Site domain, team, current/available versions and explicit plugin/theme selections.
- Action
- Open Updates Manager for the intended team. Identify the specific site and components, then read their release notes and dependency requirements. Record the selected versions and business flows they affect.
- Expected result
- A bounded change list for one identified site.
- Verify
- Compare the inventory with the WordPress administrator view and confirm no unrelated site is selected.
- If it fails
- If versions disagree, refresh through the supported interface and investigate pending jobs before planning an update.
Sources: Manage WordPress updates with Updates Manager · Manage WordPress core, themes and plugins
Step 2 of 7
Read the vulnerability and remediation details
- Where
- Site → WordPress → Vulnerability Scan
- Permissions
- Authorized site administrator; confirm the selected team and site.
- Inputs
- Finding details, affected version, severity, remediation and enabled automation settings.
- Action
- Open each relevant finding and record its affected component and recommended fix. Inspect scanner automation separately from WordPress-native automatic updates. Decide whether the selected update addresses the reported version range.
- Expected result
- A documented reason and priority for each selected fix.
- Verify
- Record findings that remain unresolved and their owners. A clean version scan does not prove the site is malware-free.
- If it fails
- If no compatible fix exists, stop the automatic update plan and obtain a documented mitigation decision; do not hide the finding simply to clear the list.
Sources: Vulnerability Checker in xCloud · WordPress native automatic update settings
Step 3 of 7
Confirm the production recovery point
- Where
- Site → Site Backup
- Permissions
- Authorized site administrator; confirm the selected team and site.
- Inputs
- Backup identity, time, completion status, storage destination and acceptable data-loss window.
- Action
- Create or identify a completed pre-change backup in the dashboard. Confirm its retention and accessible storage. Record how bookings, orders or membership changes after this point will be preserved or reconciled if recovery becomes necessary.
- Expected result
- An identified recovery point and a practical live-data decision.
- Verify
- Check completion status and the latest restoration rehearsal, rather than treating a scheduled or running backup as completed.
- If it fails
- If the backup fails or its restore scope is unclear, stop the production change and resolve storage or recovery access.
Sources: xCloud agent capability boundaries
Step 4 of 7
Prepare staging and apply only the chosen update
- Where
- Site overview → Add Staging; the staging site’s WordPress controls
- Permissions
- Authorized site administrator; confirm the selected team and site.
- Inputs
- Eligible plan, staging target, selected update list and test accounts.
- Action
- Create WordPress staging through the dashboard. Isolate public indexing and external effects such as real payment, email or webhook processing. Apply the selected update to staging and wait for its operation to finish.
- Expected result
- The staged site runs the selected new versions with controlled integrations.
- Verify
- Confirm the staging domain and target before the write. Inspect update completion and versions after it finishes.
- If it fails
- If staging is unavailable, do not claim staging was tested. Arrange an equivalent isolated test environment or defer the change for a separately approved maintenance plan.
Sources: xCloud agent capability boundaries · WordPress plugin and theme operations
Step 5 of 7
Run the site’s business regression checklist
- Where
- Staging WordPress and relevant booking/store/member interfaces
- Permissions
- Authorized site administrator; confirm the selected team and site.
- Inputs
- Baseline results, test accounts, mailboxes and payment-provider sandbox if applicable.
- Action
- Test a normal booking, a conflicting slot, cancellation/rescheduling, form submission, administrator login and mail delivery. For a store also test cart, sandbox checkout and account access; for memberships test permissions. Compare affected dynamic pages in separate sessions.
- Expected result
- The functions that earn revenue or handle customers still pass their acceptance checks.
- Verify
- Record actual inputs, expected and observed results. Confirm the plugin version and absence of newly introduced application errors.
- If it fails
- A failure blocks the production change. Investigate plugin compatibility and dependencies; do not label the update successful because the page loads.
Sources: Manage WordPress core, themes and plugins · xCloud agent capability boundaries
Step 6 of 7
Approve and apply the production change
- Where
- Production Updates Manager or site-level WordPress controls
- Permissions
- Authorized site administrator; confirm the selected team and site.
- Inputs
- Approved exact site, selected components, fresh backup, maintenance window and passing staging results.
- Action
- Confirm the approved change set and latest backup. Apply only those components on production using update controls; do not push a staging database over newer production orders or bookings. Wait for completion and inspect update history.
- Expected result
- Production has the approved versions and a recorded change outcome.
- Verify
- Repeat the business checks against production, safely using appropriate test methods, and confirm relevant messages reached their destination.
- If it fails
- If the operation is pending, monitor it. If a business check fails, stop further changes and use the recovery decision below.
Sources: Manage WordPress updates with Updates Manager · WordPress plugin and theme operations · xCloud agent capability boundaries
Step 7 of 7
Rescan and report unresolved work
- Where
- Site → WordPress → Vulnerability Scan; Updates Manager → Update History
- Permissions
- Authorized site administrator; confirm the selected team and site.
- Inputs
- Completed update, previous findings, test results and incident notes.
- Action
- Run an authorized vulnerability rescan and wait for it to complete. Compare the affected-version findings, record the update history and send the agreed report through your normal client process. Assign owners to unresolved issues.
- Expected result
- An evidence-based maintenance record with remaining work visible.
- Verify
- Record versions, backup reference, completion time, successful and failed checks, and the next review date.
- If it fails
- If a finding persists, inspect the actual installed version and remediation details. Do not repeatedly update or ignore it without a cause.
Sources: Vulnerability Checker in xCloud · Vulnerability operations · Manage WordPress updates with Updates Manager
Maintenance
Revisit update inventory and security findings on the agreed cadence. Keep owners for failures, unsupported plugins and outstanding fixes, and retain the acceptance checklist for the next change.
Manage WordPress updates with Updates Manager · Vulnerability Checker in xCloud
Review paid Site Security PRO status and virtual patching separately if used. Confirm eligibility and the actual protection configuration; do not present it as a replacement for component updates.
Recovery decisions
Decide whether the failure needs a compatible component rollback, a forward fix, or a full restore. A component rollback may not undo its database migration. Check the vendor’s supported recovery procedure and available version before acting.
Restore is a dashboard action. Confirm the exact backup, target and scope, preserve or reconcile newer bookings/orders, and approve the data-loss window before restoring. Verify login, customer records, booking/checkout and delivery afterward.
AI handoff
Connect xCloud MCP in your chosen agent client and select the intended team. Discover the available tools, input schemas and granted scopes. Start with resource reads. Approve a concrete change before each write. If a required tool or permission is missing, continue in the dashboard. The packaged REST fallback accepts GET requests only; do not use it for 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
- Review and apply selected WordPress updates mcp · write
Discover the current schema. Identify explicit plugin/theme slugs and update type; do not omit selection and unintentionally update all items.
Checkpoint: Approve selected changes only after a completed backup and staging checks. Verify asynchronous completion and business flows.
Operation identifiers and scopes to discover
sites.wordpress.update
Scopes: read:sites, write:sites
WordPress plugin and theme operations · Manage WordPress updates with Updates Manager
- 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 native WordPress backup and restore dashboard · manual
Native schedule, retention and destination changes and all restores are dashboard-only.
Checkpoint: Use Site → Site Backup. Before restoring, confirm backup, target, scope and treatment of newer records.
- Inspect and rescan vulnerabilities mcp · write
Discover the rescan tool in the connected profile; triggering a scan is a write. Findings describe known version vulnerabilities, not proof of complete site safety.
Checkpoint: Read findings before proposing remediation. Approve a rescan and verify its completion; never silently ignore a finding.
- Restore a backup dashboard · manual
Native and Docker restore operations are dashboard-only. An in-place Docker restore replaces current data.
Checkpoint: Use Site → Site Backup → Previous Backups → Restore Backup (or Restore to Another Site where offered). Confirm exact target and recovery point before proceeding.
xCloud agent capability boundaries · Back up and restore Docker apps
Copyable agent brief
Manual checkpoints
- Create and protect WordPress staging in the dashboard.
- Run customer, payment-sandbox, member and email acceptance tests appropriate to the site.
- Choose a recovery strategy and perform any restore through the dashboard.
Feature coverage
- updates (covered): Explicit selections and verified completion. Identify the exact site and proposed changes Approve and apply the production change
- vulnerabilities (covered): Triage and rescan with unresolved findings retained. Read the vulnerability and remediation details Rescan and report unresolved work
- staging (covered): Dashboard staging and integration isolation. Prepare staging and apply only the chosen update
- backup-recovery (covered): Completed backup and newer-data decision. Confirm the production recovery point
- performance-business-checks (covered): Dynamic-page isolation and business regression. Run the site’s business regression checklist
- reporting (covered): Version and test evidence with owners. Rescan and report unresolved work
Sources
- Manage WordPress core, themes and plugins
- xCloud agent capability boundaries
- WordPress native automatic update settings
- Vulnerability Checker in xCloud
- Manage WordPress updates with Updates Manager
- Site Security PRO setup and eligibility
- WordPress plugin and theme operations
- Vulnerability operations
- xCloud MCP documentation and connection profiles
- Back up and restore Docker apps