Summary: This post is about the evolution of the WordPress editor and theme customization from a developer's viewpoint, evaluating the benefits and drawbacks of significant new changes to the platform.

After the release of WordPress in 2003, no one knew that it would be one of the most popular CMS platforms to be used. The scale of the WordPress community has made it one of the more customizable/flexible platforms to work with as a developer. A developer now has the freedom to work and develop how they want to around the system. It could be as easy as creating a basic static WordPress theme or as extensive as using WordPress as a headless CMS.  

My first interaction with WordPress was fresh out of college in 2009. At that time, I used WordPress relatively statically: to input content through the CMS and then display and style it through the theme.  

Over the past 12 years, the theming and editor system has evolved to have the qualities of a low-code/no-code solution, allowing non-programmers to create custom themes and pages without touching code, to an extent.

Showing full Gutenberg Editor. The left sidebar is the available blocks and block patterns, the middle section is the Block editor, and the right sidebar is the settings.

In WordPress 5.0, a new editor called Gutenberg was introduced, immensely changing how content editors entered their content. In place of a WYSIWYG editor (also known in WordPress as the 'Classic Editor'), the platform moved in the direction of a page builder type editor that allowed for adding WordPress predefined Blocks.

WordPress Classic Editor on the left and the Gutenberg Editor on the right.

As WordPress programmers, it wasn't unusual for us to add additional plugins to convert the Classic Editor into a page builder editor. It allowed flexibility for the content editors to make layouts more dynamic and customizable. It's not surprising that WordPress went in this direction, given the trend toward a page builder.

Building Block Themes

As blocks became more accepted, WordPress introduced 'Block Themes' in 5.8. The introduction of block themes impacts how developers produce custom themes: with templates composed of blocks.  

Traditional themes use PHP and the WordPress templating system to generate custom templates that are used on the CMS side of WordPress. With block themes, it's somewhat similar, but instead of using PHP, it uses HTML and WordPress blocks in WordPress' particular HTML commenting format to generate the templates.

Does that mean I have to create a new custom theme for items to work? Honestly, it does depend. The conversion to a block theme can be incremental if you have a simple WordPress theme. The reason is that WordPress has a fallback to the PHP template files when there is no HTML template file. In other words, if you convert one template to follow the Block Theme templating pattern, the other pages won't be affected, given that WordPress will still read the PHP template files.

For example, if you want to convert a PHP template that displayed the header, post content, and the footer to a block theme template, you will have to do the following:

PHP Template:

/** page.php file */

get_header(); ?>

<div class="wrap">
<div id="primary" class="content-area">
<?php if(have_posts()) : while(have_posts()) : the_post();?>
<?php the_content(); ?>
<?php endif; ?>
</div><!-- #primary -->
</div><!-- .wrap -->


Block Theme Template:

<!-- page.html file -->

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<div class="wrap">
<div id="primary" class="content-area">
<!-- wp:post-content {"layout":{"inherit":true}} /-->
</div><!-- #primary -->
</div><!-- .wrap -->
<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

The good news is there aren't very many differences! Essentially the block HTML comment replaces the equivalent PHP code. Thankfully the block HTML comment is relatively easy to grab from the Gutenberg editor. 

What you can do to grab these block HTML comments is to:

  1. Create a page through the WordPress CMS (ensure you are using the Gutenberg editor)
  2. On the page, add what block you want to copy the block HTML comment from
  3. Modify the settings as needed for the block
  4. Click the gear icon in the upper right corner of the editor
  5. Then click the Code Editor menu optionGutenberg editor with settings icon and code editor option highlighted.
  6. You will then see that the Visual Editor is swapped to show the blocks as HTML commentsblockHTMLComment
  7. Copy the block you want to add to your template 
  8. Paste the copied code into your block template

Why Block Themes?

Why create a block theme if the coding and the templating structure aren't that different? There are a few benefits of creating a block theme:

  • Usability: The ability to edit the template through the new 'Site Editor' is enabled.
  • Performance: reduce unused CSS! When loading, only request styles for the blocks on the page vs. all styles (for all templates).
  • Modularity: If you create custom blocks/patterns, you can reuse them through the template and throughout the Gutenberg editor for other pages.
  • Configurability: Handle theme support through a JSON file (declarative programming) instead of multiple PHP functions (imperative programming).

The challenge with block themes is that if the content editor or programmer has not previously used blocks, it could be a steep learning curve (even without further customization of the 'Site Editor,' which complicates the customization/editing one can do).

Exploring the Site Editor 

The 'Site Editor' is WordPress' new editor for block themes introduced in 5.9. The Site Editor design enables an individual in the content editor role to edit the contents of a Block Theme's template and create additional template parts for use within the Gutenberg editor.

A Normal Theme on the left with the Customize, Menu, and Theme Editor option remaining available through the Appearance Menu. A Block Theme on the right with the new Editor option replacing the Customize, Menu, and Theme Editor option.

To see the Site Editor, though, there is one essential file that you must include in the Block Theme: the index.html file. The Site Editor will not exist unless the index.html file lives in a templates folder. The minimum file structure you will need to make a block theme is:

 Theme folder
|__ parts
|____ header.html
|____ footer.html
|__ templates
|____ index.html
|____ single.html
|__ functions.php
|__ index.php
|__ style.css
|__ theme.json

Once you can see the menu option for the Site Editor, using the Site Editor is almost the same as the Gutenberg Editor. The only difference is there are additional menu options to navigate to the templates and template parts. 

Showing full Site Editor. The left sidebar is the editor's menu, and the full Gutenberg Editor is to the right.

Initially, clicking on the Site Editor will automatically bring up the index.html template to be edited. If you wanted to create new templates or edit a different template, you would have to click the WordPress icon on the upper left-hand corner to reveal the Editor menu to navigate to templates.  

While on the template page, you can see that a person that doesn't know much about coding but has knowledge of blocks could create a new template without needing to bother a developer. The low-code/no-code user performs work through the Site Editor, saves changes, and selects their template when editing or creating a page. 

Screen of the block template files

What happens when you edit a template file that is part of the Block Theme? What the editor does is it saves the changes within the WordPress database but does not change the physical template file from the block theme. Any template changed from its original template has a blue dot indicator; once it's changed, there is also an option to revert all the changes and return the template to its original state.

Working with the Site Editor

Since the Site Editor is currently in beta, there is still quite a bit to improve on and to learn about once it's officially released. While learning about the Site Editor and Block Theme, there were a few things that I had to get used to or understand. 

  • When editing a page with a block theme template, I assumed that the template would automatically copy the blocks onto the page editor so I could edit the blocks within the page itself. However, I had to use the Site Editor instead of the page editor to edit the blocks. So if the template you created is particular for one page or if it was more static, you would not need to touch the page through the page editor.
  • Adding template parts through the site editor will not show as a block. Instead, you will have to add the template part block to add the template part within the template.Template Part Block options
  • Through the current Site Editor, you can not create a custom template that is not within the WordPress template hierarchy.  To create a custom template separate from the hierarchy, you must make it through the theme. The name of the template will be what you name the file.New template options.

Overall I foresee the Block Theme and Site Editor helping create more structured and less repeated code within a theme. Getting developers and content editors on board will probably take some time as it's a significant change. WordPress will continue to blur the line between maintainability and reliability as it places more options in an editor's hand. While enhanced usability is attractive for customers, the trade-off may sometimes be functional/presentational correctness. Quoting Uncle Ben from Spiderman, "With great power, there must also come great responsibility."