Full Site Editing Update

It’s time for an update on Full Site Editing!

As we approach this new way of using blocks to build out entire sites, we’d like to update you on how things are progressing. If you’re not sure what Full Site Editing is or want a refresher, check out our articles on what it is and how to get started with it.

Overview

WordPress 5.6 has officially landed! While originally intended to include a public beta of full site editing, that has been pushed to WordPress 5.7. This is not a surprise, as FSE is still very much in active development and critical components, such as handling of theme template files, remain in flux.

To put things in perspective, let’s highlight the moving pieces:

Gutenberg plugin
WordPress core
Block-based themes

The Gutenberg plugin is where all block-related development takes place. It’s an experimental playground where 650+ developers are working on the block editor experience, including new features, improved UI, global styles, and other foundational items that pave the way for full site editing.

As plugin features pass beta, they are then rolled into WordPress core. While full site editing was originally expected to hit core by WordPress 5.6, that is no longer the plan. Instead, full site editing will be partially ready in Gutenberg when 5.6 arrives.

Alongside the development of full site editing is the development of block-based themes. Since the introduction of the block editor in WordPress 5.0, blocks are used to create content. Full site editing expands the idea of block-based content by making other theme components (such as the header, sidebar, and footer), editable with blocks.

In the rest of this article, we’ll get into more detail on each of these moving pieces, highlighting the aspects most relevant to full site editing.

New Full Site Editing Blocks

Gutenberg 9.2 was released on October 21, 2020 and is the last release of the plugin to be included in WordPress 5.6. This article at WP Tavern highlights some new features in Gutenberg that we’re not covering here.

Instead, we’ll share a series of new blocks that inch us closer to full site editing capabilities.

Header Blocks

Full site editing promises a block-based experience for editing, well, a full page. To support that, several new blocks are available for headers:

Site Title block – Displays the site title as a link to the front page. The site title is wrapped in an H1 tag, although you can change it to any heading level (H1-H6). Additionally, you can edit the title text.
Site Tagline block – Displays the site tagline. Like the title, the text is editable.
Site Logo block – Upload a new logo image or select an image from the media library. The logo image is linked to the front page.

If you’ve ever tried customizing the header for a theme (particularly one that doesn’t support a custom logo), you’ll love the ease with which you can lay out site headers.

With the addition of block patterns in WordPress 5.5, you can probably expect to see various header layout patterns appear in the wild.

Post Blocks

The site header isn’t the only one getting new blocks. Also coming to WordPress 5.6 (and already included in Gutenberg 9.1+) are the following new blocks for posts:

Post Title block
Post Author block
Post Date block
Post Featured Image block
Post Content block
Post Excerpt block
Post Tags block
Post Categories block

For a detailed breakdown of markup and output for each of these blocks, check out Carolina Nymark’s excellent documentation.

While these blocks may seem simple at first glance, they offer tremendous power to both theme creators and end users. For instance, typically a theme controls the layout of single posts and archives. Where and how the featured image is displayed, the post author, etc. is typically defined by the theme. If you want to re-arrange these elements, you either create a custom theme template or, if you’re using Genesis Framework, use hooks to get the layout you want.

The introduction of post blocks brings the creation of those templates to the block editor — no code required. Theme authors can use post blocks to get creative and design interesting layouts and individual users can make changes to those designs or even create their own.

Comment Blocks

Together with post blocks, these comment blocks round out the common elements found on a post:

Post Comments block
Post Comments Count block
Post Comments Form block

These are complex blocks (the post comments form in particular), however the available block attributes are rather simple at the moment — for example, you can modify alignment, font size, and color settings, but there are no controls for changing labels or text.

Additionally, standard WordPress comment filters can’t be used to modify the output yet. This is one of many examples of the feature parity between the block editor as we currently use it and full site editing blocks.

Query Blocks

In WordPress, a query is used to grab data from the database. Queries are contextual, meaning the query in a single post template will only return information for that post, while a query on an archive template would return all posts within that context.

WordPress 5.6 will include three new blocks related to queries:

Query block
Query Loop block
Query Pagination block

The Query block is a “block version” of the WordPress post loop and determines what will be queried (i.e. posts, custom post types, categories, etc.). The Query Loop block can then be used within the Query block to contextually display content, such as the post title, post excerpt, etc. Finally, as you might imagine, the Query Pagination block outputs pagination buttons.

These blocks are very basic in their current form, but a number of improvements are in the works.

Like the post blocks, query blocks hold a lot of power for less-technical users, enabling them to generate custom queries sans-code.

Not Making the Cut for 5.6

Not everything that was originally intended for the 5.6 release will make it.

WordPress powers over 39% of the web, which means there’s a tremendous responsibility to take care when rolling out new features.

Navigation Screen

Part of the full site editing experience means re-thinking how menus are added to a site. To date, menus are created and managed via Appearance > Menus or via the Customizer. The new Navigation Screen attempts to bring the menu management process into the editor.

The Navigation Screen is still experimental at this point and has several major blockers before it’s ready for release:

So, while this feature was originally slated for inclusion in WordPress 5.6, it was pushed back in favor of focusing on the Widgets Screen.

Widgets Screen

As with navigation menus, full site editing brings the opportunity to turn widget management into a block-based experience. In a block-based widget world, all existing core widgets are transformed into blocks. Users can then add these blocks to a theme’s defined widget areas (also called sidebars).

While the Widgets Screen saw tremendous focus during the latest development cycle, work on major features is still underway. Josepha Haden, Executive Director of the WordPress project and Release Lead for 5.6 explained the reasoning for not shipping the widgets screen in 5.6:

“Making the Customizer work with the block editor is a challenging process, and one that needs substantial and thoughtful work to make sure that we deliver the best possible user experience.

“At the current stage of this project a bulk of that work is done, but more focused testing revealed notable concerns for overall usability (including customizer interactions, some confusions between block & legacy widgets, and UX disparities between the old and new screens).”

Regarding the decision to punt the Widgets Screen to a future release, lead developer Helen Hou-Sandi put it this way:

“For history and for when we return to this, I’m going to leave my “didn’t make it for 5.6” thoughts here because they are to inform how we see the feature for core readiness:

“My question for features that affect the front-end is “can I try out this new thing without the penalty of messing up my site?” – that is, user trust. At this current moment, given that widget areas are not displayed anything like what you see on your site without themes really putting effort into it and that you have to save your changes live without revisions to get an actual contextual view, widget area blocks do not allow you to try this new feature without penalizing you for experimenting.”

In short, care for both accessibility and usability issues made it prudent to push off the Widgets Screen. It’s tentatively planned for inclusion with 5.7.

Block-Based Themes

When the block editor was first introduced in WordPress 5.0, the idea of a block-based theme meant one that included support for Gutenberg features, such as full width alignment, block color palettes, etc.

So, block-based themes as we currently know them enable users to add blocks to the content area. As full site editing becomes less experimental and more the new standard, theme development will evolve in that direction.

At present, there are several theme experiments under development meant to demonstrate how full site editing works. Read on to learn more about two in particular…

The Twenty Twenty-One Blocks theme

Every year since 2010, WordPress has released a new default theme meant to highlight the latest and greatest features of WordPress. As you might imagine, the upcoming Twenty Twenty-One (TT1) theme, to be released in conjunction with WordPress 5.6, highlights blocks and block patterns.

A variant of the TT1 theme is Twenty Twenty-One Blocks (TT1 Blocks). It’s under active development (as is TT1) and explores full site editing*.

It includes block template parts (i.e. header.html, footer.html) and block templates (i.e. single.html, front-page.html). It also includes some block patterns and global styles, which are declared via a single experimental-theme.json file. If you’re a developer who’s curious about what goes on “under the hood” of a full site editing theme, you’ll want to dig around the TT1 Blocks repository.

Both TT1 and TT1 Blocks meet the criteria of an accessibility-ready theme. This is exciting as it underscores the importance of accessibility in WordPress theme development and serves as a model for other theme developers.

At this point, there are only 18 themes in the WordPress theme repository that are both accessibility-ready and include block editor styles. There’s historically been a need for greater representation in the accessibility-ready theme category and it’s refreshing to see a specific focus on accessibility during the development of full site editing.

Sarah Ricker, a web developer at WP Engine and Accessibility Lead for the 5.6 release said:

“Very often themes are developed at the cost of accessibility concerns. As stewards of best practices for the web, it is our duty to create themes that lead the way in accessibility readiness, ensuring our entire community can enjoy excellent digital experiences, regardless of any disabilities they may face. ”

Once TT1 Blocks is out of its experimental stage, it will likely be the first theme in the repository that’s both accessible and supports full site editing.

* To try out full site editing features, you’ll need the Gutenberg plugin installed and “Full Site Editing” enabled under Experiments.

Genesis Block Theme (BETA)

The Genesis development team here at WP Engine has also been working on a beta version of a future FSE theme called Genesis Block Theme, released on November 11, 2020.

The beta period will serve to get feedback to the development team and help inform the future development of Genesis Block Theme.

If you want to participate in the beta, follow the instructions outlined in this article.

What’s next for theme creators?

First off, don’t panic. Full site editing has a way to go before it’s ready for the masses.

At this point, we’re nearly two years out from the introduction of the block editor in WordPress 5.0. Ongoing development of the block editor has made it a bit of a moving target for both theme and plugin developers.

Less than 8% of all themes in the WordPress.org repository currently support block editor styles (styles for core blocks), so adoption of the block editor (for theme developers at least) is slow-moving. And while StudioPress themes aren’t represented in the repo, they were among the first to roll out “Gutenberg-optimized” themes and did so within a week of the WordPress 5.0 release.

All of that to say, if you’re a theme developer, you’ll want to keep up with full site editing as it progresses, but there’s no pressure to start creating full site editing themes at the moment. Aside from watching the Gutenberg Github repository, some great resources for keeping up to date include:

Of course, you can tune in here on StudioPress.com for more resources, too.

Conclusion

This is an exciting time in WordPress history. As members of and contributors to the open-source WordPress project, we have a unique opportunity to help shape the future of theming with the block editor.

If you’d like to get involved, follow the Gutenberg + Themes weekly updates and weigh in on the issues!

Full Site Editing Update

Overview