Book a demo
Book a demo
Login

Operations WordPress

Plan WordPress update windows

Set a cadence and business-safe window with staging, owner, and rollback prerequisites. 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 booking site needs WordPress and plugin updates without interrupting peak appointment hours. The operator plans exact components, testers and a rollback point.

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

List changes and dependencies

Where
xCloud Updates Manager and vendor notes
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Pending slugs, versions, booking integrations
Action
Group core, theme and plugin changes by effect on bookings, payment, forms and mail. Mark security urgency separately.
Expected result
A bounded update candidate.
Verify
Compare the list with current production versions.
If it fails
If dependencies are unknown, isolate them on staging first.

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

Step 2 of 5

Choose low-impact window

Where
Traffic and booking calendar
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Peak hours, staff coverage, incident contact
Action
Find a period when operators can test and respond, with enough time for backup and rollback before peak traffic resumes.
Expected result
A realistic maintenance slot.
Verify
Confirm booking staff and provider availability.
If it fails
If no tester can attend, defer non-urgent changes.

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

Step 3 of 5

Prepare staging and backup

Where
xCloud staging and Site Backup
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Staging site, completed backup, test bookings
Action
Refresh staging while isolating mail and payment side effects. Confirm a completed production files/database backup before production change.
Expected result
A safe rehearsal and recovery point.
Verify
Check staging identity, backup timestamp and test credentials.
If it fails
If backup failed or staging is not isolated, postpone the window.

Sources: Create a staging environment in xCloud · xCloud agent capability boundaries

Step 4 of 5

Test selected versions

Where
Staging WordPress and booking app
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Exact component slugs, valid/invalid booking cases
Action
Apply selected updates in staging only. Test availability, overlap prevention, confirmation, cancellation and staff notifications.
Expected result
A pass/fail record per affected flow.
Verify
Match test booking IDs and messages to expected results.
If it fails
If any critical path fails, remove that component from the release plan.

Sources: Manage WordPress plugins · Create a staging environment in xCloud

Step 5 of 5

Approve production checklist

Where
Change record and update owner
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Approved slugs, window, rollback trigger
Action
Present exact update selection, expected interruption, monitoring, verification and who decides stop/rollback. A separate approved execution follows this plan.
Expected result
A decision-ready release with clear gate.
Verify
Have the operator read selected slugs and test cases back to owner.
If it fails
If approval or recovery point is missing, leave versions unchanged.

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