Book a demo
Book a demo
Login

App workflow WordPress

Use WordPress update history during troubleshooting

Find the relevant documented history view and correlate it with observed site behavior. 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 contact form stopped delivering messages shortly after a plugin maintenance window. The owner wants to use update history to narrow the cause before any rollback.

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

Capture the failing journey

Where
Public form, recipient inbox and provider logs
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Sample submission time, expected recipient, form URL
Action
Submit one harmless test message. Record the success screen and actual inbox/provider result; note whether this form plugin stores entries at all.
Expected result
A reproducible symptom with a timestamp or message ID.
Verify
If entries are stored, compare them; otherwise correlate submission and provider time.
If it fails
If no test can be reproduced, gather customer timestamps and avoid arbitrary rollback.

Sources: Manage WordPress plugins

Step 2 of 5

Read xCloud update history

Where
xCloud WordPress → Updates or Updates Manager history
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Site ID and suspected window
Action
List core, theme and plugin changes around the first failed message. Record actor, before/after versions and completion state.
Expected result
A chronological change table.
Verify
Compare each history item with the incident start and provider events.
If it fails
If history has gaps, do not infer that no change occurred; check WordPress and deployment records.

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

Step 3 of 5

Compare dependencies

Where
Plugin changelog, WordPress settings and mail provider
Permissions
Mail provider and DNS administrators for provider records or test sends; xCloud hosting access alone is insufficient.
Inputs
Form plugin version, SMTP integration, PHP version
Action
Review whether the changed component handles form submission, mail sending or templates. With the provider owner, inspect changelog and provider event history without exposing credentials.
Expected result
A small set of plausible causes.
Verify
Compare any stored form entry, message ID or provider event with the failing submission.
If it fails
If the provider rejected a message, address sender or route before touching plugins.

Sources: xCloud WordPress site email configuration

Step 4 of 5

Reproduce safely

Where
Staging copy with isolated mail route
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Known-good plugin version and test inbox
Action
On staging, reproduce the fault on current version, then change only the suspect plugin or setting. Run identical test submissions after each change.
Expected result
Evidence that a specific change fixes or fails to fix the symptom.
Verify
Compare submission IDs and mail logs before/after the isolated change.
If it fails
If staging cannot reproduce, avoid a production rollback based only on timing.

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

Step 5 of 5

Decide the smallest repair

Where
Change record and production owner
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Verified fix, backup and recent submissions
Action
Approve a targeted setting or version repair, with a backup and validation window. Reconcile form entries received during the incident and retest end-to-end.
Expected result
A repaired mail flow with missing submissions accounted for.
Verify
Check new recipient delivery and historical entry queue.
If it fails
If the repair fails, revert the narrow repair and escalate with captured evidence.

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

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