WordPress Full Site Editing

Introduction to Block Themes (Part 1)

As I have written in my last blog post, we recently rebuilt Aino from a classic theme to a Full Site Editing block theme. When you start working with block themes in the WordPress editor, the difference to classic themes becomes obvious pretty quickly.

All elements of a website, like the header, footer and all page templates, can be edited without code in the new Site Editor. Style settings, typography, and color settings can also be edited in the Site Editor via Global Styles.

You can edit Global styles so that your changes will be applied either to the entire website, or just to specific blocks. The result is that users can customize their entire WordPress website in the editor and changes are far less theme dependent. Customizations can be saved as custom Page Templates or Page Template Parts, and these new template will remain available even after switching a theme.

What makes block theme so different?

So, users will see a lot more customization options, but what is changing in block themes under the hood? What does the switch to block themes mean for theme developers? Will building new themes become easier or more complex?

Block Themes versus Block-ready Themes

At this point, we should probably quickly look at the different theme terminologies currently used. Block-ready themes are themes that support the WordPress block editor. They are still classic themes, though, build with PHP files. Users can make style changes in the Customizer.

Block theme files

Block themes on the contrary support the upcoming Full Site Editing features that will become available in the next WordPress updates 5.9 and 6.0. At the moment, we still need the Gutenberg plugin to get access the early stages of Full Site Editing. In block themes, users edit the entire website solely in the WordPress editor. Therefore, block themes are entirely built with blocks.

Block Templates and Block Template Parts

This means that all theme template files are .html files. The template file structure stays the same. You still have an index.html file instead of an index.php file and the file is still used for the main post query.

Page template files of block themes.
Page Template files of a block theme.

You also have page, archive, and single.html files. All these template files will be stored inside a block-templates folder.

Template elements that will be used in multiple template files are stored inside the block-templates-parts folder. Here, you can add your header.html and footer.html files. I say files since it’s possible to offer multiple footers and headers in block themes. The users can then go to the Site Editor and choose the footer and header they want to use on a specific page template.

This means using headers and footers with different content and different designs is a lot easier in block themes. We use a simple version of this new feature on our Aino website, so we can have headers with different background colors on different pages of the site.

The theme.json file

The new theme.json file is the most important new file in block themes. It’s like the control room of a theme. Theme developers store all kinds of core theme information in the theme.json. Font families, font sizes, the default color palette, gradients, the default content widths and so on.

The theme.json file is the most important file in block themes.

It’s also possible to specify default style settings for specific blocks only. For instance, you can set the default font-weight to bold in the Heading block.

Per block settings in the theme json file.

Most of the theme.json settings can then be customized by the theme user via the Global Styles settings in the Site Editor. Global styles replace the Customizer settings of classic themes.

The theme.json settings also replace the font-size and color palette settings previously stored in the functions.php of block-ready themes. The functions.php is still available in block themes, but it holds a lot less information.

Global Styles and theme.json options are still very much under development and will be improved in the next WordPress releases. The visual Global Styles are still pretty limited, but improvements are on the way. You can see a few new design ideas and approaches for Global Styles on GitHub.

Design updates of Global Styles.

Preview sketches for improved Global Styles can be views on GitHub.

Since the theme.json file is so new, I will write more on this topic in the next part of my little block theme post series. For now, you can find lots of helpful information on Carolina’s fullsiteediting.com website and in the Block Editor Handbook on WordPress.org.

Ask me questions

Do you have questions regarding block themes and Full Site Editing and all the changes coming up for themes in general? Did you already have a chance to work with a block theme or create a block theme yourself? If so, what is your first impression? Do you like the direction themes and the WordPress editor is heading? Please write me your questions or any feedback in a comment below, I’m excited to hear from you.

Join the conversation

  1. Thank you for writing such an excellent post about introduction to Block themes. I have been making my own hands little dirty too recently. Impressed by Blockbase by Automattic – I have been testing and customized one of its child theme Quadrat and using in my personal project site as well, as a test case.

    Here are my personal learning-notes (not curated for public consumption yet). I might try your Aino theme and customize it for my personal site. But I am still wondering about creating a child-theme for Block themes.

    Thank you

    1. Hi Ganesh,
      thanks so much for your comment. Yes the Blockbase and Quadrat themes are both excellent themes to learn more about block themes. Thank you so much for sharing your resources. Do you know there is a WordPress Slack channel called FSE outreach program?

  2. Thanks Ellen, for the intro to what promises to be a much needed educational series.

    One concern I’ve always had with FSE is : will there be a way to prevent ‘clients’ making changes to their website that could cause serious issues? Is there a easy way, within the ‘theme.json’ file, to create CSS rules that can’t be altered via the block-editor on the WP back-end?

    1. Hi Richard,
      thank you so much for your kind feedback. This is definitely a concern for client sites and I believe that there will be options and settings to prevent access to certain templates etc. At the moment there is a plugin solution to prevent block access, called Block Visibility. It’s a little bit different but solves the block access per user role.

      I will research further and write a follow up post or include this topic in my blog post series on how access can be limited for the site editing features.

Leave a Reply

Your email address will not be published. Required fields are marked *