As part of my research leading up to my WCUS talk this year, I published a short survey that many were kind enough to fill out. It covered a number of agency workflows around block themes to see what tools people are using these days. One of those tools is Create Block Theme.
If you haven’t used it before, Create Block Theme (CBT) is a plugin that adds a number of developer tools for getting block theme changes out of that database and into your theme’s filesystem. One of the trickiest bits with block themes is version controlling your changes outside the database (which I’ve covered before on this blog, more than once). CBT flattens your site editor changes into theme files, allowing you to distribute those changes via git or by simply sharing a zip file.
CBT is helpful for theme developers who are building one-off, bundled themes to distribute widely. But it was never fully-featured enough to use in agency workflows, especially it’s lack of a command line option (yes, that’s my two-year-old issue) and a full pattern manager. It’s not CBT’s fault- I don’t think agencies are the target audience. Some of CBT’s features (like localizing text or creating blank themes) may not be necessary in an agency workflow. In my survey I found that many agencies are simply building their own tooling or forgoing version control entirely.
The problem is that WordPress transitioned away from PHP-based themes right before agents came and made the filesystem important again. This was tough before agentic coding, but it’s an even larger pain point now. All of the issues that agencies have been expressing for years around block themes are exactly the same issues we’re seeing today with agentic coding. Don’t get me wrong – overall I enjoy block themes. I just wish they were easier for developers (and agents) to work with directly.
Static sites are on the rise for many reasons (cheap hosting, for one), but the muddled approach to theming in WordPress is definitely contributing. Templates split across PHP, HTML, and the database. Styles split across theme.json, stylesheets, custom CSS, and block-level JSON and CSS classes. These are all foundational choices that have turned into technical debt. Tools like CBT exist, but this is still not a solved problem.
Making a CBT alternative
I decided to try something new because WordPress – and more importantly WP-CLI- might actually contain all the functionality you need. WordPress bundles its own ability to reconcile theme.json and Style Editor changes (though, to be fair, not as a public function). More importantly, the upcoming release of WP-CLI includes granular wp block commands for managing and exporting blocks, styles, templates, parts, and patterns.
To take advantage of this, I’ve created an experimental agent skill with bundled scripts called wp-theme-control. It’s available on GitHub, but note that it’s still experimental and should be tested only on a site where there’s no critical changes you’re afraid you’d lose forever.
Note: If WP-CLI ≥3.0.0 isn’t out by the time you’re reading this, you’ll need to have the nightly/trunk version installed.
I should also mention that the agent skill is helpful, but not necessary. The real power comes from bundled bash scripts- essentially some wrappers around WP-CLI commands. I just find it easier to let the agent do the work than try to remember the commands.
Commands instead of UI
It starts with a read-only plan command to get a list of what changes are in the database that need to move to the theme (template updates, patterns, styles, parts, etc).
Once the agent has the list of theme changes, you can review it and then decide to do a dry run, export them into the current theme, and optionally have those edited items cleared from the WordPress database. The last piece is important if you want any future changes to the files themselves recognized by WordPress, as WordPress always favors the database version over the theme version.
One thing I learned is that the wp block pattern command seem to only interact with code-registered patterns, not user-created patterns in the database. Instead we’ll use the oddly-named wp block synced-pattern --sync-status=unsynced command, which lets you query for unsynced, but user-created patterns.
Overall, it’s pretty similar to CBT, but built to be agent-first, rather than UI-first. I have some future to-dos still need to tackle with this. For example, what about pages that you might want to version control (like Cart and Checkout or deploying custom landing pages)? How robust is the link and navigation menu management (i.e. making sure no local dev links end up in templates)? What about media files that were added locally, should they move to the theme like CBT does? Plenty to think through.
That’s the hard part– every WordPress environment is unique and the lines are still blurry between design and content.
Try it out
You can take it for a test drive on a throwaway site and let me know if it’s useful. Or just peruse the repo. Some driving questions for feedback:
- Would this be useful? Is having an agent skill bundled with commands that handle this for you easier than Create Block Theme?
- Is it important to solve other database-level content pieces (page updates, navigation menus, newly added media) through a version-control workflow (i.e. something similar to Laravel’s migrations)?
- What’s missing? What’s broken? What would you have expected this to do?
- What else are you doing with agents and WordPress?
Share your thoughts and hopefully I’ll see you at WCUS
Leave a Reply