Review WordPress plugin updates site by site

Where

xCloud team and site resource views

Permissions

Named agency reviewer has permitted read access; client owns change decisions.

Inputs

Client register, exact domains, site UUIDs, team IDs, critical business journey and maintenance window.

Action

List each intended client team and production WordPress site, then compare the returned site identity with the agency register. Record whether the site takes orders, leads or only editorial content and who can approve a change for that client.

Expected result

The review covers a finite, named site set with an approver and business path for each.

Verify

Check one hostname and team ID per client against the register; mark inaccessible sites as unknown rather than up to date.

If it fails

If a team grant is missing or a staging site is mistaken for production, stop that row and ask the authorized client owner to clarify access.

Sources: xCloud team roles and permissions · xCloud agent capability boundaries

Where

xCloud WordPress update and vulnerability views; WordPress plugin list

Permissions

Reviewer reads; WordPress administrator supplies any version not visible to MCP.

Inputs

Per-site installed and proposed plugin versions, active status, finding identifier, scan time and update history.

Action

For each site record the exact plugin slug, installed version, active state, available version and last update history. Read xCloud vulnerability findings separately and attach finding IDs and observation time; do not infer a plugin is fixed merely because an update is offered.

Expected result

The queue separates actual installed state, available update and vulnerability evidence for every reviewed site.

Verify

Compare at least one plugin row with the WordPress administrator and note mismatches, missing rows and stale scan timestamps.

If it fails

If version or scan freshness is uncertain, label that row blocked for research instead of assigning a misleading priority.

Sources: Manage WordPress updates with Updates Manager · Vulnerability Checker in xCloud · WordPress plugin administration

Where

Vendor release notes and client application evidence

Permissions

Named reviewer, vendor-documentation reader and client business owner.

Inputs

Vendor changelog, required PHP/WordPress versions, payment/form integrations and client acceptance path.

Action

Read the selected vendor’s fixed or target release notes and check stated WordPress/PHP compatibility. For each site, identify whether the plugin touches checkout, forms, membership, content or a noncritical feature; ask the client owner which path would prove it still works.

Expected result

Each proposed update has a documented target and a client-specific reason for its urgency and test scope.

Verify

Write an affected URL or transaction and expected result beside each version pair; mark unsupported compatibility as unknown.

If it fails

If the vendor does not document compatibility or a required extension lags, keep production change pending and propose a safe test first.

Sources: Manage WordPress core, themes and plugins · WordPress plugin administration · Vulnerability Checker in xCloud

Where

xCloud Site Backup and staging overview

Permissions

Reviewer inspects status; dashboard owner later performs any backup or staging write.

Inputs

Last completed files/database point, retention/destination, restore owner, staging eligibility and live-data sensitivity.

Action

For each site inspect the latest completed backup and its files/database scope, then note whether eligible staging and a safe test account exist. A configured schedule or remote-storage label is not proof of a restorable point; record any site with live orders or leads that a restore could overwrite.

Expected result

The update queue shows which sites are ready to test and which lack a recovery or staging prerequisite.

Verify

Record backup identifier and timestamp with site ID, and compare it with the latest order, lead or post supplied by the application owner.

If it fails

If backup or test eligibility is missing, mark the update blocked and request a separate authorized dashboard task before scheduling it.

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

Where

Agency per-site decision ledger

Permissions

Agency maintainer proposes; client owner accepts priority and window.

Inputs

Evidence rows, severity context, target versions, dependencies, business paths, backup status and client windows.

Action

Rank the individual site/plugin rows by affected version, exposure and business impact, then group only compatible changes for a maintenance window. For each row write a specific staging test, expected application/provider record and rollback decision that preserves post-backup data.

Expected result

The owner has a prioritized per-site change sheet, not an undifferentiated update-all instruction.

Verify

Ask a second maintainer to explain why the top row precedes the next and identify each unresolved dependency and test owner.

If it fails

If priorities rest only on a badge or severity label, recheck plugin use and vendor evidence before recommending an order.

Sources: Manage WordPress updates with Updates Manager · Vulnerability Checker in xCloud · Site backups in xCloud

Where

Client approval sheet and selected future procedure

Permissions

Client owner authorizes any later update; this review does not perform it.

Inputs

Exact site, plugin slug, current/target versions, backup point, planned window, tester and unresolved risks.

Action

Send each client owner a separate proposed update sheet and acceptance criteria, including any blocked row and required backup or staging work. Hand approved rows to the site-specific WordPress update procedure; record that no plugin was changed by this review.

Expected result

Each client can approve or defer an exact update without mistaking the review for completed maintenance.

Verify

Verify the owner can name the chosen site, target version, test path and rollback authority; retain the decision timestamp.

If it fails

If approval is absent or a critical test owner is unavailable, leave the row pending and keep its finding visible in the next review.

Sources: Manage WordPress updates with Updates Manager · xCloud agent capability boundaries