Book a demo
Book a demo
Login

App workflow WordPress

Review WordPress PHP settings before a change

Record the current environment and compatibility concerns before making a planned adjustment. 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 plugin requires a newer PHP release, but the site also runs an older booking extension. The owner wants compatibility evidence before changing production PHP.

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 PHP baseline

Where
xCloud site PHP settings and WordPress Site Health
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Current PHP version, extensions, limits, error log
Action
Record current runtime and relevant PHP settings. Identify plugins and themes that depend on it, with a recent error baseline.
Expected result
A before-state for testing and rollback.
Verify
Compare displayed PHP version with WordPress Site Health.
If it fails
If the two views differ, identify cache or server mismatch before proposing change.

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

Step 2 of 5

Read compatibility requirements

Where
Plugin vendor changelogs and WordPress requirements
Permissions
Authorized WordPress/WooCommerce application administrator or delegated role with rights for this task; hosting access alone is insufficient.
Inputs
Required PHP range and extension list
Action
Check the target plugin and booking extension support matrices. Note removed functions, required extensions and database dependencies.
Expected result
A proposed version with documented compatibility evidence.
Verify
List every critical component whose support status is unknown.
If it fails
If any essential plugin lacks support evidence, test it on staging or defer.

Sources: Manage WordPress plugins

Step 3 of 5

Prepare a safe test

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 eligibility, completed backup, test cases
Action
Create or refresh staging through the dashboard, isolate mail/payments, and capture a completed production backup before runtime change.
Expected result
A test environment and recovery point.
Verify
Confirm staging matches the relevant plugin set and current PHP baseline.
If it fails
If staging differs materially, adjust fixture before interpreting its result.

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

Step 4 of 5

Change one setting on staging

Where
xCloud staging PHP settings
Permissions
Authorized xCloud site owner with dashboard rights for the exact setting, backup, staging or restore action and a reviewed target.
Inputs
Approved PHP version or single limit value
Action
Apply only the selected PHP version or setting in staging. Record the old value and job status; do not combine unrelated tuning edits.
Expected result
A controlled runtime comparison.
Verify
Check PHP version, admin login, uploads and booking flow.
If it fails
If a fatal error appears, revert the setting on staging and inspect the PHP log.

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

Step 5 of 5

Approve production decision

Where
Change record and production site
Permissions
Authorized xCloud read access to the named team and site; the relevant app or provider owner supplies records outside xCloud.
Inputs
Staging results, release window, rollback owner
Action
Summarize compatibility checks and business tests. Specify the single production setting, old value, release window and checks for a separate approved execution; leave production unchanged in this review.
Expected result
A documented go/no-go plan for a future production change.
Verify
Have the owner compare proposed setting and rollback value with the current dashboard.
If it fails
If staging and production differ, resolve the mismatch before scheduling the separate change.

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

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