As we detailed in the introductory installment of this blog series, full site editing is a coming change to WordPress core, which will broaden the use of blocks so they can be used in other places on a website, such as the header, the footer, or the sidebar.

While the first post explained some of the initial aspects of full site editing that are sure to come in handy, this post will help you dive in and start experimenting with it right now, so you can get hands-on experience. 

First, the Full Site Editing plugin by Automattic

Before we dive in, a quick note—If you search for “full site editing in WordPress,” you may turn up this plugin by Automattic. It’s intended as an experiment to guide WordPress.com users through a page creation workflow in the block editor.

Once installed, if you create a new page (not post), you’ll have an option to select from a variety of layouts, such as a contact page layout, or a services page.

Page creation workflow on WordPress.com or with Full Site Editing plugin

While you can install it on a self-hosted WordPress.org site, the plugin is only supported for WordPress.com sites. Additionally, the implementation of templates and block patterns involves a different workflow from what you’ll see with the Gutenberg plugin detailed below.

Unless you’re using WordPress.com, there’s not really a need for this plugin. Use the Gutenberg plugin instead to test features in development.

Gutenberg plugin

Before the block editor was introduced into WordPress core, all development for the block editor took place in the Gutenberg plugin. 

The Gutenberg plugin continues to be where feature development happens for block-based editing. Once mature, these features are regularly rolled into WordPress. So, if you want to experiment with full site editing, you’ll need the Gutenberg plugin to try it out.

Start by downloading and installing the latest version of the Gutenberg plugin on a development site and enable “Full Site Editing” under plugin settings. 

Gutenberg Plugin > Experimental Settings

Theme experiments

The anatomy of themes is changing. To help users and developers better understand the concepts of full site editing and how it could work in conjunction with a theme, WordPress has published a handful of theme experiments.

These themes include block templates and block template parts and provide examples for how a developer can include support for full site editing in a theme. As the name suggests, these are early experiments and may not represent how full site editing is ultimately implemented in a theme.

To try one of these themes, you’ll need a local development environment (we recommend Local) and the Gutenberg plugin with Full Site Editing enabled. From there, follow the instructions in the repository’s README file. 

You can also watch this demo for setting up the Twenty Twenty Blocks theme:

A technical look at how full site editing works

If you’re a developer, you’ll want to look “under the hood” to see how full site editing actually works. Keeping in mind that the final implementation will most likely change, here are some core concepts to understand.

Templates and hierarchy

Template files are meant for reusable, structural parts of the site. 

The WordPress template hierarchy determines which PHP file is used to output a page on a site based on the post content requested (i.e. a single post, an archive, a 404 page, etc.), with index.php being the ultimate fallback. 

Visual Overview of the WordPress Template Hierarchy

As we’ve discussed, full site editing introduces HTML templates that are meant to be used in lieu of traditional PHP template files in themes and plugins.

With traditional PHP template files being replaced by HTML block templates, how does this new hierarchy work?

Consider three types of templates that could determine the page output:

  • Theme (or plugin) PHP template file (the “original” way of templating in WordPress)
  • Theme (or plugin) HTML block template file (introduced with full site editing)
  • User-edited template stored in database as post_content (introduced with full site editing)

While there is no formal documentation around template hierarchy for full site editing, current development direction suggests that WordPress will “look for” user-edited templates first. If one doesn’t exist, any existing block template files residing in a theme will be used to display the post content requested. Finally, if no block template exists, WordPress will look for a PHP template.

Essentially, there is now a block template hierarchy sitting on top of a template hierarchy.

Additional Resources:

Creating templates

With full site editing, traditional PHP-based theme template files are replaced with HTML template files that include block markup.

At this point, the simplest way to create an HTML template is to use the block editor to build a page, export the resulting HTML markup, and save it as a template or template part.

Block patterns

Patterns are predefined block layouts, ready to insert and modify.

Just as the block editor includes core blocks, it also includes some core block patterns. Similarly, themes and plugins can add their own block patterns via the Blocks Patterns API (Experimental).

If you’ve worked with third-party block libraries such as Atomic Blocks, you’ll be familiar with the concept of adding predefined “sections” or “layouts” (collections of blocks) to a page. In fact, the idea of block patterns is largely influenced by the Atomic Blocks and Design Library plugins.

Atomic Blocks Layouts

Until now, plugins such as Atomic Blocks have used their own API to implement block patterns. With the addition of a Block Patterns API to WordPress core, developers can register custom block patterns in a consistent way. 

Registering block patterns

Themes and plugins have the ability to register block patterns using the register_pattern function included in the experimental Block Patterns API.

At the time of this writing, here’s how you could use the register_pattern function to add a custom block pattern to your theme or plugin:

register_pattern(
    'my-plugin/my-awesome-pattern',
    array(
        'title'   => __( 'Two buttons', 'my-plugin' ),
        'content' => "<!-- wp:buttons {\"align\":\"center\"} -->\n<div class=\"wp-block-buttons aligncenter\"><!-- wp:button {\"backgroundColor\":\"very-dark-gray\",\"borderRadius\":0} -->\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link has-background has-very-dark-gray-background-color no-border-radius\">" . esc_html__( 'Button One', 'my-plugin' ) . "</a></div>\n<!-- /wp:button -->\n\n<!-- wp:button {\"textColor\":\"very-dark-gray\",\"borderRadius\":0,\"className\":\"is-style-outline\"} -->\n<div class=\"wp-block-button is-style-outline\"><a class=\"wp-block-button__link has-text-color has-very-dark-gray-color no-border-radius\">" . esc_html__( 'Button Two', 'my-plugin' ) . "</a></div>\n<!-- /wp:button --></div>\n<!-- /wp:buttons -->",
    )
);

The register_pattern function receives the name of the pattern as the first argument and an array describing properties of the pattern as the second argument.

The properties of the style array must include name and label:

  • title: A human-readable title for the pattern.
  • content: Raw HTML content for the pattern.

Patterns (Experimental), Block Editor Handbook

Developers also have the ability to unregister existing block patterns. This could be useful if a developer creates a custom block pattern that’s similar to a core block pattern and wants to unregister the core pattern in order to eliminate confusion for a user.

Unregistered a pattern might look like this:

unregister_pattern( 'my-plugin/my-awesome-pattern' );

The unregister_pattern function takes the registered name of the pattern as its argument.

How WP Engine is pressing ahead

At WP Engine, one of our core values is aspiring to lead and committed to giving back.

As the web continues to play an increasingly crucial role in the way we all do business, WordPress remains the best way to harness the power of the web, quickly, so you can build your business faster. WP Engine offers a number of benefits here, and this is particularly true as the Genesis Framework evolves to align with the introduction of full site editing. 

Moving forward with the Genesis Framework

The Genesis Framework, created by StudioPress, is the most popular WordPress theme framework. What does full site editing mean for Genesis and child themes designed to work on Genesis?

Certainly, the future of WordPress themes is changing and WP Engine is working hard to ensure Genesis evolves with it. Since the acquisition of StudioPress in 2018, WP Engine has quadrupled the number of engineering resources dedicated to Genesis, underscoring its commitment and investment in the WordPress open source community.

The Genesis development team is actively working to keep the framework relevant and valuable in a full site editing world. While it’s final form remains to be seen, the future of full site editing most definitely includes Genesis.

All in on the Block Editor

In 2018, Atomic Blocks joined the WP Engine family as part of an effort to stay on the forefront of developing with the block editor. The Atomic Blocks plugin continues to evolve (and even serve as inspiration for WordPress block patterns) and is tightly integrated with StudioPress child themes.

In April 2020, Block Lab, a “code-free” solution for building custom blocks, announced that its developers would be joining the WP Engine family. WP Engine recruited the Block Lab developers to work on product development.

Those developers (Luke, Rob, and Ryan) will work with the Block Editor-focused product team to focus on technologies that improve block-based site-building for creatives and developers.

WP Engine is investing heavily in the future of full site editing to help both its customers and the larger WordPress ecosystem get the maximum benefit from the block editor.

Genesis is leaning into full site editing

As part of WP Engine’s effort to contribute to open source technologies, the Genesis team has also been attending core chats, contributing code and ideas, and staying in the loop on the changes coming with full site editing. This will help ensure the Genesis community is ready for the update. Recently announced was Genesis Pro, which offers a peek into a supercharged full site editing experience. 

In summary

Blocks are the future of WordPress, and as changes like full site editing take hold, being ahead of the curve will mean you can take advantage of these changes to grow your business and build better sites faster.  

As full site editing continues to mature, WP Engine will be here to serve as a resource—with additional blog posts like these, as well as webinars and other long-form content to help you understand the coming changes and how to best put them to use. In addition to our blog, here are some ways you can stay informed or even contribute:

Community and developer resources:

More WordPress News from WP Engine

Join the conversation.

Leave a Comment.

There are 1 comments

  • Iris Todd-Lewis on
    June 2, 2020 at 12:31 pm

    My thanks to Bud for his informative tour of Gutenberg! now I can use this tool way more effectively. Wow!

    Iris

    Reply