Full Site Editing in version 2.0

[jrtashjian]

Full Site Editing with Go

With full-site editing coming into WordPress 5.9 we needed to answer some questions around how Go can become a FSE theme without starting from scratch.

The biggest question we need to answer is how do we maintain backwards compatibility in our existing theme. It is unacceptable for us to create a brand new theme just for FSE support and instead we would like to support existing users while (as seamlessly as possible) upgrading users to FSE when it is available to them.

So how do we continue support existing users without FSE while utilizing the new features FSE provides?

Begin utilizing theme.json

In my experiment of rebuilding our Barista design template from PHP templates to block templates, I discovered that we can partially trigger FSE functionality without triggering the FSE interface entirely. By providing a theme.json file in the theme directory without the block-templates/index.html file, it seems that WordPress will still load the theme.json file and generate all the custom css properties on the front-end. This will give us an iterative approach to enabling FSE.

The primary purpose of the theme.json file is to provide a baseline design framework from which our design styles can build from. We need to rethink and/or ensure our design styles adhere to the same baseline standard. This may require standardizing things such as our color slugs, font sizes, spacings, and responsive breakpoints.

In my experiment around the Barista design I was able to remove a significant amount of custom styles by leaning on theme.json and individual blocks to provide the needed styles.

Barista theme in current version of Go:

Barista theme built with FSE:

Migrate existing templates and template parts into block templates

In order to take advantage of blocks in any capacity as a full on block theme we need to begin rebuilding our templates and template parts using blocks. To do this without creating a block-templates directory and triggering the FSE interface we should create our own go-block-templates and go-block-template-parts directories to store and manually load these new templates.

We can build these templates using the FSE interface and then exporting the templates into the appropriate directories. We would need to create the following templates:

1. go-block-templates/index.html
2. go-block-templates/page.html
3. go-block-templates/single.html
4. go-block-template-parts/header-01.html
5. go-block-template-parts/header-02.html
6. go-block-template-parts/header-03.html
7. go-block-template-parts/header-04.html
8. go-block-template-parts/header-05.html
9. go-block-template-parts/header-06.html
10. go-block-template-parts/header-07.html
11. go-block-template-parts/footer-01.html
12. go-block-template-parts/footer-02.html
13. go-block-template-parts/footer-03.html
14. go-block-template-parts/footer-04.html

Maintain Customizer controls

Because we are wanting to prevent the FSE interface from loading right now we need to maintain the current customizer controls and their functionality. Eventually all the functionality that lives here will move into the global styles sidebar within FSE or into a custom sidebar we create ourselves depending on what features are supported by core at the time.

Utilize existing PHP templates to load our Block based templates

Currently the experience for users modifying their site design in FSE can still be confusing for our target user, specifically around header and footer variations and the ability to swap to a new template part. Our customizer controls currently provide the ideal experience we're looking for and applies the header or footer design variation to the site globally.

By not triggering the full FSE experience and continuing to utilize our PHP templates, we can replace a majority of the PHP and HTML code in each template with a simple line to pull the block based template and render its blocks.

echo do_blocks( file_get_contents( get_stylesheet_directory() . '/go-block-templates/index.html' ) );

This one line allows us to still be conditional in how we load templates and use block templates while controlling the experience. There is a function in Gutenberg that makes this easier but is considered a private function and shouldn't be used. There does not yet (and my not ever) exist a hook for filtering where WordPress should look for the block templates so this manual method is the best right now.

This method also allows us to be iterative in our approach to utilizing these templates. We can gradually start replacing header variations with the block template version without needing to change everything over to the block templates.

Final Verdict

There are a lot of benefits in moving towards Go as a FSE theme and although development has progressed at an impressive rate, it has not been merged into Core yet (though it will be released in WP 5.9). That said there are still some friction areas that are easy to trip up on and I don't think brings the level of user experience our customers expect.

In my opinion, an iterative approach as I've described above would be most beneficial and as we move forward I expect FSE to make significantly more progress which would allow us to adopt more and more features until we are fully integrated. I expect most of the community will make brand new themes focused on FSE rather than take this kind of inexpedient approach.