We need to talk about the mess that is “User Styles” versus theme files. For years, the standard advice for block themes has been: “just use the Site Editor.” But if you’re a professional developer, you know the catch. Changes made in the editor live in the database, not your code. This creates a massive bottleneck in any serious block theme development workflow, especially when you need to sync designs across environments or keep a clean Git history.
I’ve seen too many projects where a designer spends forty hours tweaking a layout in the Site Editor, only for those changes to vanish because a transient expired or a database migration went sideways. It’s messy, and it’s why most “pro” devs still prefer manually editing theme.json. However, a new stack—WordPress Playground, the Create Block Theme (CBT) plugin, and GitHub—is finally making the visual-to-code bridge reliable.
The Database Trap: Why Site Editor Changes Fail Devs
In the block editor, styling is a hierarchy. You have Core defaults, block-level overrides, theme-level (your files), and finally, user-level customizations. Those user-level changes are stored in the wp_posts table as wp_template or wp_global_styles post types. Consequently, they overwrite whatever you have in your templates/*.html files.
Without a way to extract these database entries back into the filesystem, you aren’t really developing a theme; you’re just decorating a single database instance. This is where WordPress Playground changes the game by running a full WP instance in your browser via WebAssembly (WASM).
The Modern Block Theme Development Workflow
The goal is to move from a “disposable” browser environment to permanent storage on GitHub. Here is how I set up this workbench for my projects:
- Spin up the Workbench: Use a Playground URL that pre-loads the Gutenberg and Create Block Theme plugins.
- Import from GitHub: Connect Playground to your repository. It pulls your theme files into its virtual filesystem.
- Visual Design: Tweak your templates, parts, and global styles inside the Site Editor.
- Sync to Filesystem: Use the CBT plugin’s “Save Changes to Theme” feature. This writes the DB changes into the virtual
theme.jsonand HTML files. - Pull Request: Export those changes directly back to GitHub as a PR.
Speaking of syncing changes, if you are localizing media, you might want to control where those images land. Most developers prefer a specific structure. You can use a filter to refactor 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';
}Why This Matters for Performance and Handoffs
This block theme development workflow effectively eliminates the “translation” phase between a designer’s vision and a developer’s code. Furthermore, it allows for rapid prototyping without the overhead of a staging server. If you’ve ever had to explain to a client why their “CSS changes” aren’t showing up because of a race condition between the database and a cached theme.json, you’ll appreciate the clean slate this provides.
For more advanced setups, you should check out my guide on Building Pro Theme Previews with Playground Blueprints. It takes this concept further by automating the entire environment setup.
Look, if this block theme development workflow stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
The Pragmatic Takeaway
Stop fighting the Site Editor. Instead, use tools that bridge the gap. By using Playground as a temporary workbench and GitHub as your source of truth, you get the best of both worlds: visual speed and version-controlled stability. It’s not about “no-code”—it’s about “better code” that matches what the user actually sees.
