File size: 6,950 Bytes
dfb775d | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 | # Integrating WordPress.agent with mindX
This document is written for **Claude (or any agent) deploying WordPress.agent
into the mindX runtime on the VPS**. It describes the canonical wiring between
mindX, AuthorAgent, and this tool.
## Topology
```
┌─────────────────────────────────┐
│ VPS (mindx.pythai.net) │
│ │
┌───────────┐ invoke │ ┌────────────┐ HTTP/IPC │
│ mindX │──────────▶│ │AuthorAgent │────────────┐ │
│ cortex │ │ └────────────┘ │ │
└───────────┘ │ ▼ │
│ ┌─────────────┐│
│ │ WordPress. ││
│ │ agent ││
│ │ :8765 (loop)││
│ └──────┬──────┘│
└─────────────────────────┼───────┘
│ HTTPS
│ wp-json/wp/v2
▼
┌──────────────────────────┐
│ Hostinger PHP/Apache │
│ rage.pythai.net │
│ WordPress │
└──────────────────────────┘
```
WordPress.agent runs only on the loopback interface of the VPS. AuthorAgent
calls it on `127.0.0.1:8765`. Outbound HTTPS to `rage.pythai.net` is the only
external network path the agent uses.
## Deployment Path (for Claude)
When asked to deploy WordPress.agent on the VPS, follow these steps. Each is
idempotent and safe to re-run.
1. **Verify Python 3.12+ is present.**
```bash
python3.12 --version || sudo apt-get install -y python3.12 python3.12-venv
```
2. **Confirm the Hostinger preconditions** (one-time, manual on the WordPress
side, not on the VPS):
- Generate an Application Password for the `codephreak` WordPress user
under `Users → Profile → Application Passwords`. Label it
`wordpress-agent-vps`.
- Confirm permalinks are set to `Post name` under `Settings → Permalinks`.
- If LiteSpeed Cache or another caching plugin is active, exclude
`/wp-json/*` from caching.
- If a security plugin is restricting REST API access, allowlist the VPS
egress IP.
3. **Install on the VPS.**
```bash
git clone https://github.com/codephreak/wordpress-agent /opt/wordpress-agent.src
cd /opt/wordpress-agent.src
sudo bash scripts/install.sh
```
4. **Populate the env file.**
```bash
sudo ${EDITOR:-nano} /etc/wordpress-agent/wordpress-agent.env
```
At minimum set `WP_BASE_URL`, `WP_USER`, and `WP_APP_PASSWORD`.
5. **Start the service and verify health.**
```bash
sudo systemctl restart wordpress-agent.service
sudo systemctl status wordpress-agent.service
curl -s http://127.0.0.1:8765/healthz | jq
```
A healthy response returns `"ok": true` and the WordPress user id.
6. **Register with AgenticPlace.**
Copy `agent.manifest.json` into the AgenticPlace agent registry directory
on the VPS. The manifest declares `wordpress.publish` as a callable
capability with HTTP transport on `127.0.0.1:8765`.
## Calling from AuthorAgent
AuthorAgent should treat WordPress.agent as one publishing destination among
many. The minimal call from Python:
```python
import httpx
async def publish_to_rage(article: dict) -> dict:
async with httpx.AsyncClient(base_url="http://127.0.0.1:8765") as c:
response = await c.post("/publish", json={
"title": article["title"],
"content": article["html"],
"status": "publish",
"categories": article.get("category_ids", []),
"tags": article.get("tag_ids", []),
"featured_media": article.get("featured_media_id"),
"excerpt": article.get("excerpt"),
"meta": {
"_mindx_content_hash": article["mindx_hash"],
"_x402_receipts": article.get("x402_receipts", []),
},
})
response.raise_for_status()
return response.json()
```
The featured-image flow is two calls: first `/media` to upload, then `/publish`
with the returned `media_id` as `featured_media`.
## Scheduled and Event-Driven Publishing
This tool deliberately does **not** ship an in-process scheduler. WordPress's
own cron handles `status="future"` posts.
- **Scheduled:** AuthorAgent calls `/publish` with `status="future"` and a
future ISO 8601 `date`. WordPress publishes at that time. If AuthorAgent
goes down, the scheduled post still publishes.
- **Event-driven:** AuthorAgent's event listeners (NATS, on-chain logs,
webhooks) decide when to call `/publish`. WordPress.agent never listens for
events directly.
- **Milestone publishing:** AuthorAgent watches the relevant milestone source
and triggers `/publish` when conditions are met.
This separation keeps WordPress.agent stateless and easy to reason about.
## Failure Modes and Recovery
| Symptom | Likely cause | Action |
|---------|--------------|--------|
| `/healthz` returns `"ok": false`, status 401 | Bad app password | Regenerate in WordPress admin, update env, restart service |
| `/healthz` returns 5xx | Hostinger throttling or maintenance | Wait, retry; the tool retries with exponential backoff automatically |
| `/publish` returns 502 | Repeated upstream failures | Inspect `journalctl -u wordpress-agent` for response body |
| Post created but no featured image | Media upload not done first | AuthorAgent must call `/media` before `/publish` |
| Scheduled post never publishes | WordPress cron not firing | Confirm `wp-cron.php` is being hit (Hostinger sometimes disables wp-cron and requires a system cron entry) |
## Updating
```bash
cd /opt/wordpress-agent.src
git pull
sudo bash scripts/install.sh
sudo systemctl restart wordpress-agent.service
```
## Removal
```bash
sudo bash /opt/wordpress-agent.src/scripts/uninstall.sh # leave env
sudo bash /opt/wordpress-agent.src/scripts/uninstall.sh --purge # remove all
```
|