/wordpress

name: headless-step-provision-wordpress
description: "Provision a headless WordPress backend for the Hostinger Headless flow: create the headless website with WordPress at /cms, verify and self-heal, then record it in site.json."

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.

Step 2 — Create a fresh headless WordPress site (only when no site exists)

1. Pick the plan: `hosting_orders_list { "statuses": ["active"] }`. One active order → use it; several → ask the user which. 2. Start the setup:

   { "operation": "hosting_websites_start-setup",
     "params": { "order_id": <order_id>, "type": "headless_wordpress", "domain": "<domain>" } }

`domain` must be a **customer-owned** domain. For a temporary `*.hostingersite.com` subdomain, **omit `domain`** — the setup generates one itself and returns it in the response. Don't call a separate subdomain op to make one first: there's no need in this flow. (The API would also accept a subdomain you generated via `hosting_domains_generate-free-subdomain`, valid for 24 h from the client that made it — this flow just doesn't use that.) The response then carries the generated domain: if it differs from the workspace directory name, move `~/.hostinger/<old>/` to `~/.hostinger/<new>/`, update the domain in `brief.md`, and tell the user the new domain. Admin credentials are generated by the platform; never ask the user for a password. 3. Poll `hosting_websites_list-setups { "domain": "<domain>" }` every ~15 s until `completed` (typically under a minute; allow a few minutes). `failed` → stop, point at hPanel.

Step 2b — Swap an empty headless shell to WordPress (only when onboarding already made the shell)

The website already exists as an empty `headless` shell, so there is **no `start-setup`** here — you install WordPress straight into its `/cms` directory. This is the onboarding handoff path.

1. Use the shell's `username` and `order_id` from Step 1's row — no new order pick, no new website. 2. Install WordPress into `/cms`, flagged headless:

   { "operation": "wordpress_installations_install",
     "params": { "username": "<username>", "domain": "<domain>", "type": "headless",
       "site_title": "<site title from brief.md>",
       "credentials": { "login": "<admin login>", "email": "<account email>",
         "password": "<strong generated password>" } } }

• `type: "headless"` installs into `/cms` with the Hostinger headless MU plugin and marks the site

headless-WordPress; **`directory` is not allowed with it** (it is always `cms`). The target must already be `headless` — the headless install rewrites the root `.htaccess`, so the API rejects it with `422` on any non-headless site (which is why Step 1 confirms `website_type: headless` first).

• **You generate the admin password** (strong, 8–50 chars, m