headless-step-provision-wordpress

headless-step-provision-wordpress

Create the headless WordPress backend for <domain> and prove it is ready. One platform call lays every headless site out identically: WordPress in public_html/cms, Hostinger AI Assistant + MCP adapter, site marked headless. Out: site.json.

WordPress + WooCommerce? This same recipe serves it. When the brief's Suggested backend is **WordPress + WooCommerce**, provision the WordPress site exactly as below, then run the optional WooCommerce tail in Step 5 (install + activate the woocommerce plugin and verify the store endpoints; the catalog is seeded in content-model via the per-site WP MCP). WooCommerce is a plugin on this WordPress install, not a separate backend: site.json → backend stays "wordpress" and the store is recorded under site.json → woocommerce. For a plain WordPress brief, skip Step 5 entirely.

All operations below go through the Hostinger connector (execute).

Fire vs join (background provision). Step 1, plus the queuing call — hosting_websites_start-setup for a fresh site (Step 2) or wordpress_installations_install to swap an empty headless shell (Step 2b) — are the fire half: once the job is queued, record provision.in_progress and return to do prepare work (see the router ../SKILL.md). The readiness poll at the end of Step 2 / 2b, plus Steps 3–6, are the join half — run them when an instance-barrier step needs the backend (or immediately, if the agent can't interleave). An already-completed site with WordPress at /cms detected in Step 1 means provision is already done: record provision.completed and adopt it.

Step 1 — Detect before you create (never provision twice)

1. hosting_websites_list { "domain": "<domain>" } — substring filter, so exact-match the row's domain. If a row exists, note username, order_id, website_type.
2. No exact row → nothing exists on this domain → create fresh (Step 2).
3. A row exists. If website_type is not headless, stop and tell the user — this domain already hosts a different kind of site (plain WordPress, Node.js, builder, …); never overwrite it. If it is headless, work out whether WordPress is already installed or the shell is still empty (see the router's Onboarding handoff): check hosting_websites_list-setups { "domain": "<domain>" } (exact row) and wordpress_installations_list { username, domain, ownership: "all" } (exact row):
   • Setup running → provisioning is underway → skip to Step 2's poll.
   • Setup failed → tell the user and point them at hPanel; do not call start-setup again yourself.
   • A WordPress install with directory: "cms" already present (or setup type: headless_wordpress) → already provisioned → skip to Step 3 (adopt it).
   • A headless site with no /cms install (an empty headless shell — setup type: headless_empty, typically from onboarding) → swap it to WordPress (Step 2b). Do not call start-setup again — the website already exists; you only install WordPress into it.