One essential tool in your toolbox as a professional website builder is source control, also called version control.

Source control is the practice of tracking and managing changes to code. This means using Git, often used along with Github to host the code.

Why use source control

Using Git or other source control tool to manage your code gives you lots of benefits:

1. Versioning: By tracking every change done to a code base, you can understand how it evolved. You’ll also be able to revert to previous versions or even undo specific changes.
2. Traceability: Each change provides information on who changed the code, when, and what was changed. This can provide insight into when and why certain changes were made.
3. Branching and merging: New features or bug fixes are implemented on specific forks or branches of the codebase. This allows you, for example, to develop and test a feature without changing the code of the production website.
4. Backup and recovery: Even if the code is deleted, you can always get it back from the history provided by the source control.
5. Collaboration: Multiple developers can work on the same code base without interference. Changes can then later be merged into the main code base and distributed to all developers.
6. Code review & testing: As changes are made separate from the main code base, you can review and even test them.

So, if you’re not using source control, I recommend that you start integrating it in your workflow. Github has a great tutorial that will get you started in no time

Challenges of using source control with block themes

In a classic theme, nearly everything a website needs to function is in the codebase:

1. PHP templates and template parts.
2. CSS and JavaScript files.
3. Customizations made through PHP actions and filters.

In a block theme, this is no longer the case:

1. The Site Editor enables visual editing of templates and template parts. Changes are stored in the database as wp_template and wp_template_part post types.
2. The Styles sidebar allows users to edit the theme and block styles. Changes are stored as a wp_global_styles post type.
3. Patterns and pattern categories use both theme storage and database storage.

Block themes can be entirely tracked in source control except for synced patterns, which must be stored in the database.

Avoid these three mistakes

My experience shows that developers make three common mistakes.

The first is not setting the WP_DEVELOPMENT_MODE constant. You must set this to theme so that WordPress does not cache any theme-related data.

You can set this variable in wp-config.php:

​
<?php
define( 'WP_DEVELOPMENT_MODE', 'theme' );
​

The second is not reloading the Site Editor after manual changes to theme.json. You need to understand that this file is only loaded once when the editor is loaded. For any changes after that to be considered, you need to reload the editor again.

If you do not reload the editor, then WordPress will use stale data when exporting theme changes, undoing all your manual changes.

The third is not exporting changes often enough. Whatever code you are working on, it’s important that your commits only impact one particular part of the codebase and that they are self-contained.

So far, let’s say you add a 404 template. For this, you build out the 404.html file and change a few global styles. But then you find out you need a new font size, and you add it to the palette.

In this case, I would make two commits:

1. First, I’d commit the theme.json with the new font size. This is a change that is independent of the template addition, as other templates might use it.
2. Second, I’d commit the 404 template file with the theme.json containing the style changes.

Helpful tools

Two plugins help with the development workflow.

First is Create Block Theme, which offers solid theme export functionality.

The second is the Pattern Manager. It is a fair warning that this plugin is no longer actively developed, but it’s still very useful.