Full-Site Editing allows users to customize their entire site using a visual builder.

This means you can now change existing pages, or even add new pages to your site. All from within WordPress, and without having to install a plugin.

The key addition that Full-Site Editing brings is a tool called the Site Editor.



This site editor allows the users to modify the blocks that their theme is made up of.

So in order to use the feature, users will need to install and activate a block-based theme. These themes have been designed to work with Full Site Editing.

Since WordPress 5.9, Full-Site Editing is part of Core. All you need to is to activate a block theme.

Please consult this article on how to try full-site editing to get detailed installation instructions.

As of early 2021, there will be no migration available for existing themes.

This means that if you want your theme to be customizable through the Site Editor, you’ll have to build it from scratch as a block theme.

In full-site editing, users can add menus to a theme using the Navigation block. This is the only option to add, remove, or modify menus.
This is because Full-Site Editing removes the Menus screen as well as the Customizer from the admin on sites using a full-site editing theme.

Themes built for full-site editing do not have sidebars as we know them from current themes.

In PHP-based, “classic” themes, sidebars are the only place in which users can freely add content and functionality through widgets. The rest of the templates are static, and customization options therefore limited. With full-site editing, users can edit any part of a template. So there is no need for sidebars anymore.

All existing widgets in WordPress Core have been migrated to blocks. The functionality offered by these widgets will continue to be a part of WordPress.

WordPress 5.9 removed the Customizer and the widget submenu entries from the Appearance menu in the admin. Users can therefore no longer access these screens when a full-site editing theme is enabled.

Currently there is no good way to have translatable strings in a block template.

A workaround is to use a Block Pattern whenever translated text is needed. This allows the use of PHP to handle translations.

The Loop is the first part of WordPress that theme developers interact with.

The structure of The Loop is the following:
– A while loop runs as long as have_posts() returns true.
– the_post() is called at the top of each iteration, which sets the post related global variables.
– Template tags like the_title() or the_content() output the current post’s data.

Invisible to developers, the Main Query gets all the posts for a specific page based on its URL. So The Loop is only there to output the content, retrieving the content happens automatically. If additional content is needed, developers can use WP_Query to create an additional loop inside the template.

In a block-based theme, the query does need to be explicitly placed in the template using the Query block. Inside of the query, the Query Loop then handles looping over all the available posts. And the Post blocks handle outputting the post’s data.

To learn more, please read this in-depth guide to the Query block.

Currently the posts page handling is the same in full-site editing as it is in current themes.

Traditionally in WordPress, a blog archive is generated by creating an empty Page and selecting Settings > Reading and selecting that page as the posts page.

The full-site editing theme then just needs an index.html template with a loop that inherits the main query. You can consult this Gist to get an example of the required loop markup in a block theme.

The reading settings will be respected, and the posts page will show the blog archive using the index.html template. If you want to customize the blog archive template further, you can create a home.html template, and it will be selected as the current template when the blog is displayed.