Full Site Editing: The Future of Building with WordPress

If you are tuned into WordPress news sources or online communities, you’ve probably heard chatter about how Full Site Editing is coming to WordPress.

What exactly does that mean and what do you need to know to be prepared for the changes ahead? Those questions (and many more) are what we’ll cover in this article and upcoming articles about Full Site Editing. 

Our goal is to help you stay informed and ahead of the curve with open source and WordPress, and getting up to speed on Full Site Editing before it’s introduced into WordPress #Core is an excellent way to do that.

What is Full Site Editing?

Traditionally in WordPress, themes, plugins, and the native content editor have played distinct roles. Themes provide the logic, structure (header, footer, content area, etc.), and visual appearance of the site. Plugins extend the core functionality of WordPress. And the content editor (formerly the Classic Editor, but now the block editor) is used to create and manage content.

With Full Site Editing, that paradigm is shifting.

Blocks are no longer “just for content,” but instead are taking on a broader role. With Full Site Editing, blocks can be used in other places on a WordPress site, such as the header, the footer, or the sidebar. 

What does this mean for themes and plugins? Well, it’s not entirely clear yet. What is clear is that how we think about building sites with WordPress will look different moving forward.

Full Site Editing is still being developed, so know that the specifics of implementation, etc. will continue to evolve. That said, any examples provided in this article are intended to help explain concepts and should not be used in a production environment.

The language of Full Site Editing

With the evolution of the block-based editor, the lexicon of WordPress is evolving, too. While there is an official glossary, we’ve selected some core terms and concepts to get you started.

Blocks

If you’ve already worked with Gutenberg (a.k.a. The block editor), you’re familiar with the concept of blocks. 

Blocks treat Paragraphs, Headings, Media, and Embeds all as components that, when strung together, make up the content… – Block Editor Handbook

Instead of creating content with freeform text, inserted media, embeds, and shortcodes, content is created in a unit of blocks. The block editor was introduced with WordPress 5.0.

It’s worth mentioning that there are both static and dynamic blocks. A static block contains content that’s known at the time of saving a post (for example, a Paragraph block contains whatever text has been entered). A dynamic block, however, contains content that may not be known at the time of saving a post but instead is determined when the post is shown on the front end of the site. An example might be a list of latest posts. That content is dynamic as it’s determined at the time the post is displayed.

Block patterns

In WordPress 5.3, the Group block was introduced. This made it possible to group, or nest, child blocks within a parent container.

Block patterns take the idea of grouping blocks further and give site users a way to leverage predefined layouts on their sites. This benefits users by providing a starting point for page layout vs a blank canvas. 

Block patterns are predefined layouts of blocks that can be inserted as starter content that are meant to be changed by the user every time. Once inserted, they exist as a local save and are not global.

Mark Uraine, a WordPress contributor and Automattician, stated that block patterns are largely influenced by the Atomic Blocks and Design Library plugins.

At the time of this writing, block patterns are not yet part of WordPress core. They are available with the Gutenberg plugin v7.7+. Some block patterns will exist natively in WordPress. Themes and plugins can also define block patterns via the Block Patterns API (introduced with Gutenberg 7.8).

Templates

A template is a predefined arrangement of blocks and could include predefined attributes or even placeholder content.

Traditionally in WordPress, template files are included in themes (and sometimes plugins) and are applied contextually to posts and pages based on the WordPress Template Hierarchy. While template files are written in PHP, they may contain some HTML markup.

A typical theme directory structure might look like this:

├── theme-name

│   ├── template-parts

│   │   ├── content.php

│   ├── templates

│   │   ├── template-cover.php

│   │   ├── template-full-width.php

│   ├── index.php

│   ├── style.css

In terms of Full Site Editing, the concept is similar except that templates (and template parts, which we’ll address shortly) are HTML files containing block markup. The modified theme structure might look like this:

├── theme-name

│   ├── block-template-parts

│   │   ├── header.html

│   │   ├── footer.html

│   ├── block-templates

│   │   ├── index.html

│   ├── index.php

│   ├── style.css

Block template example

A simple template consisting of a header, content area, and footer might look like this index.html file from the Twenty Twenty Blocks theme:

<!-- wp:group {"align":"full","className":"site-header"} -->
<div class="wp-block-group alignfull site-header"><div class="wp-block-group__inner-container"><!-- wp:template-part {"slug":"header","theme":"twentytwenty-blocks"} /--></div></div>
<!-- /wp:group -->

<!-- wp:group {"align":"full","className":"site-content"} -->
<div class="wp-block-group alignfull site-content"><div class="wp-block-group__inner-container"><!-- wp:post-title /--><!-- wp:post-content /--></div></div>
<!-- /wp:group -->

<!-- wp:group {"align":"full","className":"site-footer"} -->
<div class="wp-block-group alignfull site-footer"><div class="wp-block-group__inner-container"><!-- wp:template-part {"slug":"footer","theme":"twentytwenty-blocks"} /--></div></div>
<!-- /wp:group -->

Regardless of the final implementation, block templates like their predecessor, theme templates, are used to determine layout.

Template parts

Template parts are the blocks equivalent of theme template parts.They are reusable chunks of code, meaning that a single template part (i.e. footer.html) could be included in a variety of templates.

Just like block templates, block template parts include a predefined arrangement of blocks and HTML markup. Template parts are written in HTML and do not include any PHP. 

Template part example

Here’s a an example of the header.html template part from the Twenty Twenty Blocks theme:

<!-- wp:columns {"align":"full"} -->
<div class="wp-block-columns alignfull"><!-- wp:column -->
	<div class="wp-block-column"><!-- wp:heading {"level":1,"className":"is-style-header-site-title"} -->
		<h1 class="is-style-header-site-title" id="site-title"><a href="/">Twenty Twenty</a></h1>
		<!-- /wp:heading -->

		<!-- wp:paragraph {"className":"site-description"} -->
		<p class="site-description">Just another WordPress site</p>
		<!-- /wp:paragraph --></div>
	<!-- /wp:column -->

	<!-- wp:column -->
	<div class="wp-block-column"><!-- wp:navigation {"className":"is-style-header-nav","itemsJustification":"right"} -->
		<!-- wp:navigation-link {"label":"Home","title":"Home","type":"page","url":"/"} /-->

		<!-- wp:navigation-link {"label":"About","title":"About","url":"/about"} /-->

		<!-- wp:navigation-link {"label":"Blog","title":"Blog","url":"/blog"} /-->

		<!-- wp:navigation-link {"label":"Contact","title":"Contact","url":"/contact"} /-->
		<!-- /wp:navigation --></div>
	<!-- /wp:column --></div>
<!-- /wp:columns -->

That template part consists of a two-column layout with the site title and description in the first column and a navigation menu in the second. It might render in the block editor like this:

User-edited templates

While themes can define starter templates and template parts, users may want to modify them or even create new ones. 

Once a template is used in a post, the content is serialized and stored in the database as post_content. At the time of this writing, it is unclear how user-defined templates behave if a new theme is activated and contains templates of the same name.

For instance, if a user has edited the header.html template part in an existing theme, that “template” now exists in the database as serialized data. Should a user activate a new theme that includes a template part also named header.html, presumably the user-defined template would take precedence. However, the workflow around user-edited templates and template hierarchy are not documented as of yet.

Reusable blocks

Reusable blocks are a way to share a block (or a group of blocks) as reusable, repeatable pieces of content. A good use case might be a Call to Action or Email Signup form that you want to use in multiple locations on a site.

One important thing to note about reusable blocks: They are global, which means any edits to a reusable block are applied to every usage of that repeatable block on a site.

Block-based themes

To date, a block-based theme means a theme that includes support for the block editor and includes block styles. A great example is the default Twenty Twenty theme from WordPress. It’s designed to take full advantage of the flexibility of the block editor.

Eventually, block-based themes will include support for Full Site Editing. Here’s an experimental version of the Twenty Twenty theme that supports Full Site Editing. You can check it out to get an idea of how a block-based theme of the future might be structured and coded.

Global styles

The block editor currently supports style customization on a per-block basis. For instance, on a paragraph block a user could select a font color, size, and optional background color.

With Full Site Editing, global styles would enable things such as font scale, colors, buttons, etc. and universally apply those styles throughout the site.

This initiative adds an interface to apply styling when in site editing mode. The styling will initially be global but also be able to apply just to the document (e.g. a Page or a Post) or to a component itself. For example, styling an individual button, all buttons within a page, and/or all buttons across an entire site. – WordPress Design Handbook

As with other core concepts of Full Site Editing that we’ve discussed, the interface for global styles is still in flux. To see proposed/example interfaces for the first phase of global styles, follow this Github ticket.

What all is changing with FSE?

Full Site Editing is a complete paradigm shift. For content creators, it’s an extension of the block-based editing experience and offers a greater level of control without the need to code.

For theme and plugin developers, it’s a different approach to creating templates, applying base styles, and giving users a head start with block patterns.

While the ultimate application of Full Site Editing remains to be seen, the concept and experimental development is well underway. 

Blocks, blocks everywhere

The introduction of the block editor in WordPress 5.0 gave users the ability to create rich content in customizable blocks. The block editor, however, was limited to authoring pages and posts. The components of a full site layout, such as the header, sidebar, or footer were left to the theme.

With Full Site Editing, themes can still include these layout elements, however they can be edited and customized directly by the user. Blocks aren’t just for content. They’re used to define site layout.

Democratizing design

Ultimately, the full site editor offers greater control for non-technical users over front-end design and display. 

Want to change the background color for the header? There’s no need to learn CSS — simply edit the settings for that block. Or what about changing fonts site-wide? Users won’t need code to do that either.

While designers may cringe at giving users that much control, that control is what many users want. WordPress may dominate market share in the CMS space, but the popularity of website builders such as Squarespace and Wix is evidence that people want the ability to design and build websites without knowing how to code.

Between global styles and theme-defined styles, developers can place parameters around the choices that users have. For instance, a theme can define a default color palette. While users could select any color, having a predefined color palette can help direct users to make design decisions that are in alignment with theme styles.

Eventually, user roles or permissions may also help determine which users can access these styles.

Custom templates

In the current world of WordPress, themes (and sometimes plugins) are used to define templates. For instance, a theme could provide a landing page template, a template for blog archives, or a front page. Plugins that register a custom post type might provide a custom template for that post type.

Block-based themes will eventually use block templates and block template parts, giving users a starting point for smart site design. Site and content creators could then fine-tune styles, layouts, etc. as needed to meet their needs.

Do page builders have a place in a block-based world?

Page builders enable non-technical users to build complex layouts for their websites with little to no code. Many page builders can control the design of an entire layout, including the header, sidebar, content area, and footer.

When Gutenberg was first released, the block-based editor only applied to the content area, making it distinct from a page builder both in terms of experience and capability. With Full Site Editing around the corner, however, the block editor becomes increasingly competitive with page builders.

Does this mean there is no future for page builders? Not necessarily. Page builders such as Elementor, Divi, and Beaver Builder enjoy widespread usage and it’s not likely that their respective customer bases will bail the moment Full Site Editing is available.

Justin Tadlock has an insightful editorial on whether page builders will stay competitive in the block era.

When should you adopt FSE?

The block editor was introduced to WordPress core in December 2018. Many users pushed back on adopting Gutenberg and continued using the Classic Editor for various reasons, but primarily because the editor felt more like an MVP than a fully-baked feature. Since that time, the block editing experience has improved significantly.

If you (or your clients) are still relying on the Classic Editor, this is the time to make the switch to the block editor as that is the foundation for Full Site Editing.

That said, FSE is still very much in development, so how quickly you engage with it depends on how you use WordPress. According to the WordPress Roadmap, Full Site Editing is a top priority for 2020 project development. It would not be surprising to see FSE in core by the end of 2020 or early in 2021.

Content Creators

For folks that use WordPress to create content, there’s nothing to really “adopt” at this point. Other than getting comfortable using the block editor for content creation, there’s nothing else you need to do right now.

Just know that the experience of creating content with WordPress will continue to improve in new and exciting ways.

Consultants & Site Creators

This is the right time to fully embrace the block editor for your own sites and for use on new client site builds. The more comfortable you are working with blocks, the more easily you’ll be able to transition to Full Site Editing when the time comes.

For now, make sure you’re using Gutenberg-ready, block-based themes. These are themes built specifically with the block editor in mind. One of the biggest changes you’ll notice is that widgets play a lesser role than ever before. Block-based themes enable you to create visually complex layouts, so instead of hard-coded widget areas in themes (especially on the front page), you use blocks as the foundation of your content design.

The Navigation Pro theme from StudioPress is a nice example of this. Looking at the demo of the home page (or the screenshot below), you’ll see text overlaying images, overlapping elements, multi-column and grid layouts, etc. Each of these components is a block, some native to WordPress and some blocks provided by the free plugin Atomic Blocks.

Creating layouts with blocks instead of widgets gives you greater flexibility when it comes to delivering attractive designs for your clients. And, of course, you can make many customizations without needing to touch the code, speeding up your workflow.

If you haven’t started working with block-based themes that are currently available, download a free theme from WordPress.org or a StudioPress theme such as Navigation Pro* and start experimenting. Once you feel comfortable working with block-based content layouts, you’ll be ready to embrace Full Site Editing when it’s officially rolled into WordPress.

* all StudioPress theme packages are free for WP Engine customers

Theme & plugin developers

The time to dive into Full Site Editing is now! 

It bears repeating that these are experimental features and not intended for use on production sites. However, as you make plans for future theme development or plugin development that will leverage blocks, you’ll want to be familiar with the development of Full Site Editing.

In addition to the instructions below, here is related developer documentation: 

• Blocks API
• Block-based Themes (experimental)
• Block Patterns API (experimental)

To keep track of the Gutenberg project in Github, here are two great “summary” tickets:

• Full Site Editing Breakdown #20791
• Phase 2 Scope & Features #13113

Stay tuned for the second part of this post which will offer additional detailed information about getting started with Full Site Editing. As we continue to get closer to its launch in WordPress #Core, we’ll have much more here on the WP Engine blog as well as other channels, to help you get up to speed.