User styles and theme files do not get along. The advice for block themes has been “just use the Site Editor,” and that holds up right until you need the work to exist in your codebase. Editor changes live in the database. Any serious block theme development workflow hits that wall the first time you try to sync a design between environments or keep a Git history that means anything.
I have watched a designer spend forty hours on a layout in the Site Editor and lose it because a transient expired or a database migration went sideways. That is why plenty of developers still edit theme.json by hand. WordPress Playground, the Create Block Theme (CBT) plugin and GitHub together are the first setup I have used where the visual-to-code bridge actually holds.
Why Site Editor changes fail developers
Styling in the block editor is a hierarchy: Core defaults, then block-level overrides, then theme level, which is your files, and user-level customizations on top of all of it. Those user changes sit in the wp_posts table as wp_template or wp_global_styles post types, and they win over whatever is in your templates/*.html files.
With no way to pull those database entries back into the filesystem, you are decorating one database instance rather than building a theme. WordPress Playground is what changes that: it runs a full WordPress instance in the browser through WebAssembly (WASM).
The block theme development workflow I use
The aim is to get the work out of a disposable browser environment and into permanent storage on GitHub. My workbench runs like this:
- Spin up a Playground URL that pre-loads the Gutenberg and Create Block Theme plugins.
- Connect Playground to your repository so it pulls the theme files into its virtual filesystem.
- Design visually, tweaking templates, parts and global styles inside the Site Editor.
- Run the CBT plugin’s “Save Changes to Theme” feature, which writes the database changes into the virtual
theme.jsonand HTML files. - Export those changes back to GitHub as a pull request.
If you localize media along the way, you probably want control over where those images land. A filter overrides the default CBT behavior:
<?php
/**
* Customize the asset path for localized images in CBT.
*/
add_filter( 'create_block_theme_localize_media_folder', 'bbioon_custom_asset_path' );
function bbioon_custom_asset_path( $path ) {
// Move localized images to a specific subdirectory
return 'assets/localized-media';
}What this buys you on performance and handoffs
This block theme development workflow removes the translation step between what a designer builds and what a developer commits, and it lets you prototype without standing up a staging server. Anyone who has had to explain to a client why their CSS changes are not showing up, because the database and a cached theme.json disagree, will appreciate starting from a clean slate.
My guide on Building Pro Theme Previews with Playground Blueprints goes further and automates the whole environment setup.
If block theme work is eating your dev hours, I take that kind of job on. I have been wrestling with WordPress since the 4.x days.
What to do with this
Fighting the Site Editor is a waste of time; bridging it is not. Playground as a temporary workbench with GitHub as the source of truth gives you the speed of designing visually plus files you can review in a diff. You end up with code that matches what the user actually sees.
