Rethinking our commitment to version control when building block themes in WordPress.
I’m a huge fan of dogfooding. It’s an incredible way to learn the challenges your customers may encounter when using your products. As WordPress theme and plugin developers, we would much rather catch a bug or edge case before someone rage-reviews our product or service.
As the Matchbox team transitions from building traditional WordPress themes to block themes, we find ourselves rethinking many of the processes we’ve developed over our 15+ years of using WordPress. The one that has me scratching my head the most is how we use Git.
As we’ve just launched another project, protecting our hard work and the client’s brand standards is top of mind. Today I posted the following message in the #outreach channel on Slack.
As an agency developer, we’re having to rethink our workflows surrounding Git and what is version controlled. I’d love to hear how other developers address version control for production sites.
Previously, we relied heavily on custom post types and ACF blocks that were part of the theme. This was a straightforward Git workflow for us as code (theme and project-specific plugins) was always pushed to the production environment. We also had theme and plugin editor options disabled to ensure changes weren’t overwritten in future deployments.
As we’ve fully embraced the Site Editor, we’re committing less and less. Where we previously had functional and code review processes to ensure accessibility, coding, and security standards were followed, we’re finding areas in the production sites where someone has changed the styling or layout of a block or pattern, leaving pages in a bit of a mess.
We love the power and flexibility of the Site Editor, but as an agency, we’ve lost a lot of control in ensuring our client’s brand standards are followed.
Our current Git workflow with block themes is to commit our theme.js, custom scss, block and plugins to the repo. Then, at the “end” of development, we pull the production site to our local environments using WP Migrate. We then use the Create Block Theme plugin to overwrite the theme locally, cleaning up the diffs and committing those changes.
We had a discussion last week that the step we’re taking pre-launch is a waste of time, as the second a user changes a layout or styling attribute, our code base is out of sync again.
I look forward to hearing how you’ve adjusted your workflows to accommodate block themes and the site editor.
It turns out the Hallway Hangout was happening at that exact moment 🤯, and I had the opportunity to join. I was surprised by how many other people on the call were experiencing the same issues. I’m pleased to hear that we’re not the only team struggling with these workflow changes, and I look forward to the feedback on the post.
Follow along, and let’s learn together.
https://github.com/WordPress/developer-blog-content/issues/229