Block themes and the Site Editor have transformed the WordPress design landscape, making professional theme development accessible to designers who prefer visual interfaces over code. This shift opens the ecosystem to a new group of creators who previously relied on external design tools. However, a significant hurdle remains: how can changes made within the Site Editor’s database be extracted into a theme’s file system and integrated into a version-controlled workflow?
This article details a “no-code” development workflow that uses a powerful combination of tools—WordPress Playground , the Create Block Theme (CBT) plugin, and GitHub —to bridge the gap between browser-based design and professional version control.
The core challenge of Site Editor changes
In the WordPress block editor environment, design, and styling exist at four levels:
Default mostly the styling and layouts of WordPress Core.Block-level styling can be altered with plugins and overwrites the Default styling.Theme-level styling is the whole suite of design tools, controlled by the active Theme. It overwrites Default and block-level styles and layouts for instance (e.g. template and template parts).User-level styling uses the Design tools within the Site Editor to modify styles and layouts. These changes are stored in the database and overwrite the theme-level styling.
</svg>
</button></figure>
As mentioned, when a designer modifies a template in the Site Editor, those changes are stored in the database as “user-level” customizations. Without a way to sync these changes back to the theme’s files (the “theme level”), they cannot be easily reused on other sites, version-controlled, or protected from being overwritten during updates.
To understand how this workflow bridges the gap between visual design and version-controlled development, it is helpful to look at the specific roles of each tool in the stack.
WordPress Playground
The Create Block Theme (CBT) Save Changes to Theme feature. It takes modifications stored in the WordPress database and writes them directly into the theme’s virtual file system within Playground, updating theme.json and HTML templates automatically.
GitHub Pull Requests (PRs).
Setting up the workbench
The workflow begins by launching a pre-configured Playground instance. You can launch a workbench with the necessary tools already installed by appending plugin slugs to the Playground URL: https://playground.wordpress.net/?plugin=gutenberg&plugin=create-block-theme
Note: Once the instance is loaded, set the storage type to “Browser” within the Playground settings (the site manager icon
</svg>
</button></figure>
Importing the theme from GitHub
To work on an existing project, the theme must be imported from its GitHub repository:
Open the Playground menu and select Import from GitHub .
Authenticate the connection to GitHub.
Provide the repository URL and specify that the import is a Theme .
Identify the correct directory (usually the root /).
Playground will download the theme files and activate the theme within the browser instance and reload the site.
</svg>
</button></figure>
</svg>
</button></figure>
</svg>
</button></figure>
Three workflow screens to import a Theme from GitHub </figure>
Designing and syncing changes
With the theme active, modifications are made directly within the Site Editor . After saving changes in the Site Editor, they must be written to the theme files:
Open the CBT sidebar within the editor (click the wrench icon in the top toolbar).
Select Save Changes to Theme .
Optionally select Localize Images to move uploaded media from the database to the theme’s /assets folder. The folder is customizable via a WordPress filter.
This step moves the modifications from the WordPress database into the virtual file system of the Playground instance, preparing them for a GitHub commit.
</svg>
</button></figure>
</svg>
</button></figure>
</figure>
Submitting a Pull Request via Playground
Once the design is synced to the files, the changes can be submitted back to GitHub without leaving the browser:
Open the Playground menu and select Export to GitHub .
Playground automatically populates the repository information.
Enter a descriptive commit message .
Click Create Pull Request .
</svg>
</button></figure>
</svg>
</button></figure>
</svg>
</button></figure>
The three screens to create a Pull Request in GitHub </figure>
In the last step, you will find a link to the created GitHub PR, where you can continue submitting it as a code commit.
</svg>
</button></figure>
The developer can then visit GitHub to review the changes and merge the Pull Request into the main project.
Use cases for this workflow
The Designer-to-Developer handoff: A designer works visually in the Site Editor, saves changes via CBT, and submits a PR. The developer reviews the code in GitHub, ensuring it meets standards before merging. This eliminates the “translation” phase from design tools to code.
Rapid prototyping and client previews: Spin up a Playground instance, make requested layout changes visually, and share the project’s Playground URL with the client for instant feedback—without touching a staging server.
Open-source theme contributions: This democratizes contributions. Anyone can click a link to open a theme in Playground, fix a styling bug visually, and submit a PR without ever opening a terminal or a code editor.
By using this powerful combination of tools, the WordPress community is moving toward a future where the distinction between “user” and “developer” continues to blur. This browser-based workflow provides a safe, scalable, and professional way to build the next generation of block themes while maintaining the integrity of version control.
Props to @ greenshady and @ areziaal
