Shipping a Site-Wide Banner Feature: Worker to WordPress in One Session
Just wrapped up a solid dev session building out a complete site-wide sticky banner feature. This one felt good - clean three-component architecture that spans our entire stack.
The Build
Started with the worker endpoints. Added four new routes to handle banner management:
- Public GET endpoint for WordPress to fetch banner data (gated with our standard header auth)
- POST to save banner content (text, CTA text, and URL)
- DELETE for removal
- POST with AI generation using Haiku to create disaster recovery copy
The AI route is pretty neat - it pulls the client name and vertical from our KV store and generates contextually relevant banner copy. No more staring at blank fields wondering what to write.
Worker deployed and live at version 8c043aeb.
Dashboard Integration
Added a "Site Banner" card to the Site Manager tab in our dashboard. Built out the full panel with:
- Client selector
- Live preview that updates as you type
- Text and CTA input fields
- AI Assist section for copy generation
This codebase doesn't use our usual apiFetch helper, so everything's raw fetch calls with getAuthHeaders() from the state management. Consistent with the existing patterns.
WordPress Theme Component
The WordPress side was straightforward. Created site-banner.php with:
bbs_fetch_site_banner()function that hits our worker endpoint- 5-minute transient cache because we're not savages
bbs_render_site_banner()hooked intowp_body_openat priority 1- Smart dismiss functionality using localStorage with auto-reset when banner content changes
Bonus Fix
Found and killed some old DNS setup function stubs that were hoisting over the correct async versions. Always satisfying to delete dead code.
What's Left
Worker's live, dashboard auto-deployed via Vercel, but I still need to push the WordPress theme to Cloudways. That's tomorrow's first task along with diving into the workflows section.
Three commits, full-stack feature, clean architecture. Good session.