Building a REST API Health Check for WordPress Site Management
Had one of those sessions where I fixed a bunch of annoying deployment issues and actually shipped something useful.
The Cloudways rsync Nightmare
First up, I finally cracked the rsync permission error that's been haunting my deploy.sh script. Turns out using -a (archive mode) was causing headaches because the Cloudways master user can't set ownership on directories owned by the app user. The fix was switching to:
rsync -rl --no-perms --no-owner --no-group --delete
Not the most elegant, but it works. Sometimes you just gotta work with the hosting provider's quirks.
The Great Dark Mode Disaster
Remember kids: never accidentally delete your dark mode CSS block. I learned this the hard way when the entire site styling disappeared. Apparently in a previous session I'd removed the dark mode CSS thinking I could fix dark mode issues by tweaking it, but that block drives all the html.hb-dark-mode and html.hb-respects-dark variable overrides.
Mental note: fix dark mode via the WordPress option hb_site_dark_mode_enabled instead. Leave the CSS alone.
Building the Health Check API
The main accomplishment today was creating a proper REST endpoint for site health monitoring. I built inc/api.php which registers a GET /wp-json/hb/v1/deploy-check endpoint that's gated behind admin permissions.
The endpoint returns a structured JSON response with everything I need to monitor remotely:
- Theme version
- Site settings
- Content counts
- Schema field mappings
- System info (WordPress, PHP, ACF, Breeze versions)
- Validation rules with pass/fail status
This is way cleaner than trying to manage sites over SSH. With WordPress Application Passwords, I can authenticate securely and get all the health data I need for the dashboard.
What's Next
Now I need to:
- Generate a WordPress Application Password for the dashboard to use
- Wire this endpoint into the HoneyBun dashboard UI
- Add more validation checks as I discover what else needs monitoring
The endpoint is live and deployed. Time to build the dashboard side and actually use this thing.
Sometimes the best coding sessions are the ones where you fix a bunch of small annoying things and ship something that'll make your life easier down the road.