Book a demo
Book a demo
Login

App workflow WordPress

Review pending WordPress updates in xCloud

Inspect available update information and select a testable change set. Check the named site's prerequisites, task result, backup scope and recovery handoff with xCloud.

Technical review: · Source reviewed; no production deployment test claimed

Published · Updated · xCloud editorial

Read this guide as Markdown

Requirements and responsibilities

Illustrative situation

A site manager sees 17 pending WordPress updates before a sales campaign. They need to identify risky dependencies and prepare a change plan, with no production update in this task.

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

Identify the review scope

Where
xCloud site and WordPress → Updates
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Site ID, current WP version, campaign dates
Action
Open the named site and confirm its domain and environment. Record WordPress core version and the date of the last completed backup.
Expected result
A dated review target, not an update request.
Verify
Compare the xCloud site ID with the campaign owner's inventory.
If it fails
If the site or environment does not match, do not continue with component assessment.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Site backups in xCloud

Step 2 of 5

Inventory pending versions

Where
xCloud Updates Manager and WordPress Updates
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Core, theme and plugin names and slugs
Action
Read pending versions and installed versions for each component. Group inactive plugins separately and identify any must-use plugins not shown in normal update notices.
Expected result
A component-by-component update table.
Verify
Cross-check at least the critical checkout/form/booking plugins in WordPress admin.
If it fails
If lists disagree, capture both views and inspect the component before planning a write.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Manage WordPress updates with Updates Manager

Step 3 of 5

Read impact evidence

Where
Vendor changelogs, xCloud vulnerability findings
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Release notes, advisories, compatibility claims
Action
Inspect changelogs for database migrations, minimum PHP/WordPress versions and breaking changes. Match vulnerability findings to installed versions and affected features.
Expected result
A priority and risk note for every important update.
Verify
Reference the actual advisory or vendor release for each high-priority component.
If it fails
If release notes are missing, mark compatibility unverified rather than guessing.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Vulnerability Checker in xCloud · xCloud site PHP settings

Step 4 of 5

Choose staging checks

Where
Staging plan and business-flow owners
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Checkout, form, account, email and cache test cases
Action
Select the smallest coherent update batch and assign a staging test for each affected flow. Check staging eligibility and ensure a safe production backup exists before scheduling a future change.
Expected result
A reviewable future update plan with named testers.
Verify
Confirm the test cases can observe both success and failure of critical flows.
If it fails
If no staging path or owner exists, document the deferral and compensating monitoring.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Manage WordPress updates with Updates Manager · Site backups in xCloud · Create a staging environment in xCloud

Step 5 of 5

Record decision without applying

Where
Change record or client maintenance plan
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Exact slugs, proposed versions, risks and approval owner
Action
Publish a decision table: update now after a separate approval, defer with reason, or replace the component. Include the planned window and rollback decision point. Do not call sites.wordpress.update in this review.
Expected result
A documented recommendation and no production version change.
Verify
Reopen Updates Manager and confirm pending versions remain unchanged.
If it fails
If a version changed during review, investigate actor/history and refresh the plan.

Sources: xCloud MCP documentation and connection profiles · xCloud agent capability boundaries · Manage WordPress updates with Updates Manager

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