While working with Block Themes some more over the past few months, there was one thing I always struggled with. And that was versioning.
If we work on (traditional/classic) themes for clients or for ourselves, we usually have separate git repositories for the theme and for any helper plugins that we might build. Every change we make in the code gets committed and properly versioned through git, which makes sure that no changes are lost and all of the progress is properly documented.
With Full Site Editing and the Site Editor some of those conventions were turned upside down and I needed to find a way to adapt our workflow a bit. The main pain point for me was that suddenly we (can) have styling and templates stored in the database instead of in the theme files. This probably wont be a problem for many end users, but has some implications if you are a team of developers used to work with versioning.
I was painfully reminded about that, when I accidentally deleted changes I had made to a template on the local site, because I “quickly grabbed the newest content from the live site”, which in turn replaced the local database and therefore synced my template changes into oblivion. This led me to investigate how to integrate this into our workflow.
Plugin: Create Block Theme
I initially thought the Create Block Theme by the WordPress.org team is “just” a way to jumpstart a theme project, equivalent to the create-block-plugin command. But as it turned out it is more of a general helper plugin that you can use while developing block themes. Apart from creating a new theme from scratch, it also lets you “overwrite the active theme files” with changes you made in the Site Editor. This will write changes to your theme files, which is crucial if you want to commit those changes to a git repository.
Basically I can make changes to the theme files or to theme.json etc. manually, but also change things in the templates and parts of the Site Editor, and when I’m done, I save those changes to files. In git I then see exactly what changes were made and can adjust, edit or ignore them before making a commit.
While this works quite well with my git workflow, there were also a few things I missed.
Wish #1: I would love to have some more control over which changes to write to the theme. For example: It would be nice if you are able to save the changes made to one particular template to the theme files, instead of always saving all of the changes at once (especially as all those changes get swiped from the database in the same step, without any way of restoring them).
Wish #2: Somewhat related to the above, a “restore” functionality would have been handy many times over. For example: in case you realize the changes you made were not ready yet or you “exported” them to files by accident, while it would be easy to “ignore” the changes made to the files in your git repository, there’s no easy way of restoring them in the Site Editor, other than redoing them manually.
My current workflow
First things first: Starter Template
As a starting point, I created an FSE starter theme, which includes the overall directory structure, some basic stuff in functions.php, our default Grunt workflow to preprocess SCSS and a few other things. To start a new project, I clone this repo and rename things to match the new project.
Add Global Styles
The starter theme doesn’t include any styling at all, so I start by adding a few global styles to make it look more like the design I’m after. Some styles are only possible to add manually to the theme.json file (but more and more gets exposed in the UI, so this is changing rapidly), others can be changed in the global styles section of the Site Editor, which feels a bit faster.
Build Templates in Site Editor
Next, I start to build the main templates, like index.html, single.html or page.html right inside the Site Editor. This feels a bit unusual at first, but works quite well and I actually started to enjoy to put some basic layouts together in this visual way.
Write templates to the theme files
Once the templates are somewhat ready, I use the Create Block Theme plugin to write them to the theme.
Versioning
As soon as the changes are written to files, I can review, edit, ignore and finally commit them to the repository to have them versioned and under control.
Changes made in the site editor
As soon as I change anything in the site editor that I want to keep, I go to the Create Block Theme menu and choose “Overwrite Theme” to write the changes to files and commit them to the git repo. In my experience, this also does a good job at merging changes made in the Site Editor with the changes I made to the files myself, which is quite handy.
Conclusion
While this workflow still isn’t perfect, it works well for now to get some of the control back that I felt was lost when I started working with FSE and block themes.
My first impression was that the Site Editor and Full Site Editing are built more for end users than agencies and developers, and wasn’t sure how good of a fit it will be for our client work. But while working with it some more, I realized there are not that many features missing to make this workflow truly work for us and those gaps are closing fast.
Also, we just launched our first client project using a block theme and the designer working with us was more than impressed by how fast and easy he could build up layouts for new landing pages etc. with the patterns we provided them.
There are still some rough edges, but those are getting addressed and all in all I see lots of potential for this to become our standard way of building themes in the future.
Update 17. March 2024: Just after I hit publish, I stumbled upon this article by Brian Coords, where he asks a lot of the same questions I had when working with Block Themes and proposes some possible solutions for the future.