Requirements and responsibilities
Have the nonprofits owner approve public copy, required staff roles and the exact sample journey. A nonprofit runs campaigns with volunteers updating stories and a treasurer reviewing donations.
xCloud agent capability boundaries · WordPress roles and capabilities
Use a compatible Nginx or OpenLiteSpeed stack for native WordPress. Verify current server resources, plan eligibility and each selected plugin or service license and requirements before installing; a Docker server does not host a new native WordPress site.
xCloud agent capability boundaries · WordPress plugin administration
Prepare a safe test identity and a completed, accessible backup before consequential changes. The important failure to plan around is: A public donation button alone proves neither settlement nor receipt delivery.
Illustrative situation
Illustrative scenario, not a customer case study: A nonprofit runs campaigns with volunteers updating stories and a treasurer reviewing donations. A test contribution appears in the payment service and expected record.
Choose the approach
Choose a donation service against receipts, export and reconciliation requirements. Verify the selected provider or plugin documentation and license against this requirement; xCloud hosting does not supply its business configuration.
xCloud agent capability boundaries · xCloud MCP documentation and connection profiles · WordPress roles and capabilities · Site Security PRO setup and eligibility
Keep application setup, domain/DNS ownership, mail delivery and external integrations with their named administrators. Use a plain documented path when a proposed integration cannot be demonstrated end to end.
xCloud agent capability boundaries · WordPress plugin administration
Dashboard and application procedure
Follow these steps yourself, or use the scoped AI handoff below for supported hosting operations.
Step 1 of 5
Approve mission copy, campaign owners and donation fields
- Where
- WordPress or selected application administrator and public test browser
- Permissions
- Named WordPress or selected application administrator; business owner accepts result.
- Inputs
- Approve mission copy, campaign owners and donation fields; named administrator and a harmless representative sample.
- Action
- Have campaign and finance owners approve purpose, target wording, donor fields and receipt responsibility.
- Expected result
- The organization knows which system records the gift.
- Verify
- The organization knows which system records the gift. Have the responsible business staff member record the sample identity and observed result.
- If it fails
- If a proposed campaign claim has no evidence or approver, leave it out.
Sources: WordPress roles and capabilities · WordPress plugin administration
Step 2 of 5
Publish campaign and impact pages with role-based editors
- Where
- WordPress or selected application administrator and public test browser
- Permissions
- Named WordPress or selected application administrator; business owner accepts result.
- Inputs
- Publish campaign and impact pages with role-based editors; named administrator and a harmless representative sample.
- Action
- Publish reviewed campaign pages in WordPress. Give volunteers Contributor or a separately verified custom role so their drafts require an editor’s approval; keep payment settings with the finance administrator.
- Expected result
- A volunteer can draft but cannot publish or edit donation settings.
- Verify
- A volunteer can draft but cannot publish or edit donation settings. Record the exact account or record tested, result, and time with the responsible owner.
- If it fails
- If a volunteer can alter payment links, narrow the role before launch.
Sources: WordPress roles and capabilities · WordPress plugin administration
Step 3 of 5
Configure documented donation service and receipt path
- Where
- WordPress or selected application administrator and public test browser
- Permissions
- Named WordPress or selected application administrator; business owner accepts result.
- Inputs
- Configure documented donation service and receipt path; named administrator and a harmless representative sample.
- Action
- If the organization chooses GiveWP, have its finance owner check current license and payment setup, then configure the documented test mode; otherwise use the selected donation provider’s own sandbox instructions.
- Expected result
- A test contribution can be reconciled.
- Verify
- A test contribution can be reconciled. Have the responsible business staff member record the sample identity and observed result.
- If it fails
- If the service lacks required export data, compare another provider before collecting gifts.
Sources: WordPress roles and capabilities · WordPress plugin administration · GiveWP test donations with Stripe
Step 4 of 5
Test contribution, failed payment and reconciliation export
- Where
- WordPress or selected application administrator and public test browser
- Permissions
- Named WordPress or selected application administrator; business owner accepts result.
- Inputs
- Test contribution, failed payment and reconciliation export; named administrator and a harmless representative sample.
- Action
- Make a small test-mode donation and a failed-payment attempt; compare donor view, provider event, receipt and finance export.
- Expected result
- Only the successful event appears as a contribution.
- Verify
- Only the successful event appears as a contribution. Have the responsible business staff member record the sample identity and observed result.
- If it fails
- If a receipt goes out for a failed payment, resolve the integration before publication.
Sources: WordPress roles and capabilities · WordPress plugin administration · GiveWP test donations with Stripe
Step 5 of 5
Review access and back up content separately from payment records
- Where
- WordPress or selected application administrator and owner handoff
- Permissions
- Named WordPress/application administrator and business owner; inspect backup separately if recovery is in scope.
- Inputs
- Review access and back up content separately from payment records; named administrator and a harmless representative sample.
- Action
- Review volunteer access, campaign dates and donation data ownership; back up site content and keep financial records with their provider.
- Expected result
- Treasurer and site editor have separate recovery responsibilities.
- Verify
- Treasurer and site editor have separate recovery responsibilities. Have the responsible business staff member record the sample identity and observed result.
- If it fails
- If a WordPress restore would duplicate a donation message, suppress/reconcile before going live.
Sources: Site backups in xCloud · xCloud agent capability boundaries · WordPress roles and capabilities
Maintenance
Assign a cadence for selected WordPress core, theme and plugin updates, review version-based findings and retest the path in this guide. In particular, repeat: A test contribution appears in the payment service and expected record. A chat prompt is not a scheduled task.
Manage WordPress updates with Updates Manager · Vulnerability Checker in xCloud
Record actual backup completion, storage access and responsible staff. Recheck connected application and provider behavior after changes rather than relying on a site health status alone.
Recovery decisions
Before restoring, compare the chosen recovery point with newer business records. A public donation button alone proves neither settlement nor receipt delivery. Use the xCloud dashboard for native restore only after the owner approves target and scope; reconcile or preserve newer data first.
Validate the restored copy with representative content, authentication, HTTPS and this guide’s business acceptance test before moving traffic or closing the incident.
AI handoff
Connect xCloud MCP through the current documented profile and grant only the scopes needed for the selected team. Discover tool schemas first. Read resources to plan; require approval for any supported write. Use returned dashboard URLs for manual work. The packaged REST wrapper accepts GET requests only.
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
- Review a WordPress business journey app · manual
Application data and observed transactions cannot be inferred from xCloud resource reads. Use authorized test accounts and the application or provider evidence.
Checkpoint: Record the test identity, timestamp, expected outcome, observed result and owner decision.
- Configure WordPress content, users and selected plugins app · manual
Requires a named WordPress administrator or suitable editor. Plugin behavior, commercial license, payment, email and external integration are verified in the chosen vendor documentation and application; xCloud hosting or MCP reads do not configure them.
Checkpoint: Open the actual WordPress or selected plugin interface, record the version and role, and have the business owner accept a real user journey.
WordPress roles and capabilities · WordPress plugin administration
Copyable agent brief
Manual checkpoints
- The named WordPress, app, dashboard or provider administrator performs the guide’s actual configuration step: If the organization chooses GiveWP, have its finance owner check current license and payment setup, then configure the documented test mode; otherwise use the selected donation provider’s own sandbox instructions.
- The business owner compares the controlled sample with this observable result: Only the successful event appears as a contribution.
- Staging push/pull, native backup schedules, restores and cache-setting edits require the authorized xCloud dashboard operator; the packaged REST wrapper is GET-only.
Feature coverage
- business-acceptance (covered): A test contribution appears in the payment service and expected record. Test contribution, failed payment and reconciliation export
- recovery (covered): A public donation button alone proves neither settlement nor receipt delivery. Review access and back up content separately from payment records
Sources
- xCloud agent capability boundaries
- WordPress roles and capabilities
- WordPress plugin administration
- Site backups in xCloud
- WordPress hardening handbook
- xCloud MCP documentation and connection profiles
- Site Security PRO setup and eligibility
- Manage WordPress updates with Updates Manager
- Vulnerability Checker in xCloud
- GiveWP test donations with Stripe