WordPress Full Site Editing and block widgets, explained

WordPress Full Site Editing changed a fundamental idea that had existed since the early years of WordPress: the theme controls the site’s structure, while the editor controls the content inside it.

With a modern block theme, that boundary is much less rigid.

You can use blocks not only inside posts and pages, but also to edit parts of the site that traditionally belonged almost entirely to theme files, including:

• headers;
• footers;
• navigation;
• single-post layouts;
• archive layouts;
• 404 pages;
• search-result templates;
• global typography;
• site-wide colors;
• reusable design sections.

This collection of capabilities was originally widely described as Full Site Editing, often shortened to FSE.

That term is still useful when discussing the overall concept, but modern WordPress documentation usually refers more specifically to the Site Editor, block themes, templates, template parts, Styles and related block-based features.

At the same time, WordPress also introduced a block-based Widgets editor for classic themes. That created a second source of confusion because blocks can appear inside traditional widget areas even when a site is not using the Site Editor at all.

The result is that several WordPress concepts are frequently mixed together:

• the Block Editor;
• the Site Editor;
• Full Site Editing;
• block themes;
• block widgets;
• legacy widgets;
• templates;
• template parts.

They are related, but they are not the same thing.

This guide explains how the modern WordPress editing system fits together, what Full Site Editing actually means, how block themes work, what happened to traditional widgets and sidebars, and when a site still uses the older classic-theme architecture.

What does Full Site Editing mean in WordPress?

Full Site Editing describes the broader WordPress project that extended the block editing experience beyond post and page content and into the structure and design of the entire site.

The practical result is the Site Editor.

The official WordPress Site Editor documentation describes it as an interface that lets you design the entire site, including the header, footer and everything between them, using blocks.

You access it from:

Appearance → Editor

but only when the active theme supports the block-theme architecture.

The Block Editor and Site Editor are different interfaces

The Block Editor is primarily used to edit the content of an individual post, page or supported custom post type.

For example, a blog post may contain:

• Paragraph blocks;
• Heading blocks;
• Image blocks;
• Gallery blocks;
• Columns;
• Buttons;
• Quotes.

The Site Editor works at another level.

It can edit the templates that surround that content.

A simplified single-post page may therefore be thought of as:

• Header template part;
• Post template;
• Post title;
• Featured image;
• Post content;
• Post metadata;
• Footer template part.

The content editor controls the actual post content.

The Site Editor can control the surrounding layout.

Full Site Editing requires a block theme

The Site Editor is not automatically available on every WordPress website.

The active theme matters.

The official WordPress block-theme documentation defines a block theme as a theme that uses blocks for areas such as navigation, headers, content and footers.

If you use a compatible block theme, you normally see:

Appearance → Editor

If you use a traditional classic theme, the Appearance menu may instead include familiar interfaces such as:

• Customize;
• Widgets;
• Menus;
• Theme File Editor.

The exact screens depend on the active theme and installed plugins.

Block themes vs classic WordPress themes

The easiest way to understand Full Site Editing is to compare block themes with classic themes.

Classic themes

A traditional WordPress theme normally builds its layout using PHP template files.

Examples may include:

• header.php;
• footer.php;
• single.php;
• page.php;
• archive.php;
• sidebar.php.

The theme developer determines much of the structure through those files.

Users generally edit content through WordPress and customize the theme through the controls that the theme exposes.

Those controls may include:

• Customizer settings;
• widget areas;
• menu locations;
• theme options;
• customizer panels;
• plugin-based page builders.

Block themes

A block theme moves much of the site’s structure into block-based HTML templates.

The current WordPress Theme Handbook describes a typical block theme structure with folders such as:

• /templates;
• /parts;
• /patterns;
• /styles.

A basic block theme may contain files such as:

style.css
theme.json

/templates/
    index.html
    single.html
    page.html
    archive.html
    404.html

/parts/
    header.html
    footer.html

/patterns/

/styles/

The most important difference is that the templates themselves contain block markup and can be visually edited through the Site Editor.

Block themes do not eliminate theme files

A common misunderstanding is that Full Site Editing means WordPress no longer uses themes or theme files.

That is incorrect.

A block theme is still a theme.

It still defines things such as:

• default templates;
• template parts;
• global styles;
• patterns;
• design settings;
• theme assets;
• PHP functionality when required.

The difference is that far more of the presentation layer can be represented with blocks and exposed visually in WordPress.

Templates and template parts explained

Templates are one of the most important concepts in the Site Editor.

The WordPress Theme Handbook documentation on templates explains that templates define the overall document structure used to display content on the front end.

A template controls a type of page

Typical templates include:

• Single Posts;
• Pages;
• Archives;
• Search Results;
• 404 pages;
• Front Page;
• Home/blog index.

A Single Post template might contain:

• Header;
• Post Title;
• Post Featured Image;
• Post Content;
• Post Author;
• Post Terms;
• Comments;
• Footer.

Changing the Single template can therefore affect many posts at once without changing the content stored inside each post.

Post Content is a dynamic block

This distinction matters.

When you edit a template and see the Post Content block, you are not directly editing the text of every post.

The block represents the location where WordPress will insert the current post’s actual content when that template is rendered.

Other theme-oriented blocks work similarly.

Examples include:

• Post Title;
• Post Featured Image;
• Post Author;
• Post Date;
• Post Terms.

Template parts are reusable sections

A template part is a reusable portion of one or more templates.

The official Template Parts documentation lists common examples such as:

• Header;
• Footer;
• Sidebar;
• Comments.

A header does not need to be manually recreated inside every template.

Instead, several templates can reference the same Header template part.

When that shared part changes, the change can propagate wherever the part is used.

This is similar in principle to the reusable PHP template parts traditionally used by classic themes, but the structure can now be edited through the block interface.

How Site Editor changes are stored

One subtle but extremely important detail is that visually editing a block theme does not necessarily rewrite the original theme files.

The WordPress Site Editing Templates architecture documentation explains how customized templates work.

A block theme may initially provide:

/templates/single.html

But when a user edits that template through the Site Editor, WordPress can save the customized version in the database using the wp_template post type.

Template parts can similarly be stored using wp_template_part.

The theme file remains the original source

This produces an important hierarchy.

The theme can provide a default template.

The user can then override that template through the Site Editor without modifying the theme package itself.

This is why updating a block theme does not automatically need to erase every visual template customization made through the editor.

Resetting a customization can restore the theme version

Because WordPress understands the distinction between the theme-provided template and the user customization, Site Editor interfaces can offer options to clear customizations and return to the theme’s original version where supported.

That is very different from manually editing the theme file itself.

Global Styles and theme.json

Full Site Editing is not only about moving blocks around.

Block themes also have a site-wide design system built around Global Styles and theme.json.

The WordPress Global Settings and Styles documentation describes theme.json as a configuration file that controls settings, styles and registrations used by a theme.

theme.json can define design defaults

A block theme can use theme.json to configure things such as:

• color palettes;
• typography;
• font sizes;
• spacing;
• layout widths;
• block-specific styles;
• template parts;
• editor capabilities.

A simplified example might look like:

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        {
          "slug": "primary",
          "color": "#111111",
          "name": "Primary"
        }
      ]
    }
  }
}

User styles can override theme defaults

The style system is hierarchical.

The WordPress documentation explains that theme settings can be overridden by higher-priority layers, including user changes made through the Site Editor.

This means a theme can define a default typography system while the site owner changes it visually through:

Appearance → Editor → Styles

without manually editing CSS.

Styles are global, block settings are local

This distinction prevents another common source of confusion.

If you select one Heading block and change its color, that is generally a local design change.

If you modify the default Heading styling through Global Styles, that can affect headings throughout the site according to the theme and style hierarchy.

For a related editor-design topic, see Customizing the WordPress Block Editor Theme Color.

What happened to WordPress widgets?

Widgets did not disappear from WordPress overnight.

Instead, WordPress now has different widget behavior depending largely on the type of theme being used.

Traditional widgets

Historically, a classic theme registered specific widget areas.

Typical examples included:

• Main Sidebar;
• Footer Column 1;
• Footer Column 2;
• Header Widget Area.

Users could then place widgets such as:

• Search;
• Recent Posts;
• Categories;
• Archives;
• Custom HTML;
• plugin-provided widgets.

The theme determined where those widget areas existed.

WordPress 5.8 introduced the block-based Widgets editor

WordPress 5.8 introduced the ability to use blocks inside traditional widget areas.

The current WordPress Widgets Block Editor documentation explains that the newer Widgets editor allows blocks and widgets to be inserted into widget areas and sidebars defined by a classic theme.

This means a classic theme can use:

Appearance → Widgets

with a block-based editing interface.

That does not mean the site is using Full Site Editing.

Block widgets and Full Site Editing are separate concepts

This is one of the most important distinctions in the guide.

A classic theme can support:

• traditional PHP templates;
• classic widget areas;
• a block-based Widgets editor.

It may still have no Site Editor at all.

Therefore:

Using blocks in Appearance → Widgets does not make a theme a block theme.

What happens to widgets in a block theme?

Block themes take a different approach.

The official WordPress block-theme documentation explains that block themes rely on blocks rather than traditional widgets and widget areas.

This is a major architectural change.

A sidebar no longer needs to be a registered widget area

In a classic theme, a sidebar might be created by:

• registering a sidebar in PHP;
• rendering that sidebar from a theme template;
• placing widgets inside it through Appearance → Widgets.

In a block theme, a sidebar-like section can simply be constructed from blocks inside a template or template part.

For example, it might contain:

• Search block;
• Latest Posts block;
• Categories block;
• Tag Cloud block;
• Heading block;
• Image block.

No traditional widget area is required for that layout.

Blocks can be placed much more freely

Traditional widgets were constrained to locations registered by the theme.

Block themes make the layout itself editable.

The same Search block could potentially appear:

• in a header;
• inside a footer;
• beside post content;
• inside a custom template;
• inside a pattern.

This is a much more flexible model than the original widget-area architecture.

What about old third-party widgets?

The transition to blocks did not instantly convert every third-party WordPress widget into a native block.

For classic themes using the block-based Widgets editor, WordPress includes a compatibility mechanism.

The official Block-based Widgets Editor documentation explains that older widgets can continue to work through the Legacy Widget block.

Legacy Widget preserves compatibility

If a plugin registered a traditional widget but never created an equivalent native block, it may still be manageable within a classic theme’s block-based widget interface.

This allows WordPress to modernize the editing UI without requiring every historical widget plugin to be rewritten immediately.

Legacy Widget is not the future architecture of block themes

For new block-theme development, native blocks are generally the more natural integration model.

A plugin designed specifically for modern block-based WordPress will often expose functionality as a block rather than expecting the theme to register a traditional widget area.

Theme blocks make Site Editing possible

The Site Editor includes ordinary content blocks, but it also relies on blocks that represent dynamic parts of a WordPress site.

These are often called theme blocks.

Important examples include:

• Site Logo;
• Site Title;
• Navigation;
• Post Title;
• Post Content;
• Post Featured Image;
• Post Author;
• Post Date;
• Post Terms;
• Query Loop;
• Template Part.

The Navigation block replaces much of the traditional menu workflow

In classic themes, navigation was traditionally built around registered menu locations and the Appearance → Menus screen.

Block themes use the Navigation block as a central part of the modern navigation system.

The current WordPress Navigation block documentation describes it as the container for blocks that let visitors navigate around a site.

It can contain navigation links, submenu items and related navigation structures inside a block-based layout.

Query Loop replaces many hard-coded post loops

The Query Loop block is another important Site Editing component.

The WordPress Query Loop documentation describes it as an advanced block for displaying posts or other post types according to query parameters and visual configurations.

It can be used to build layouts such as:

• blog archives;
• category listings;
• featured-post sections;
• custom post grids;
• latest-content sections.

This means layouts that previously required significant theme PHP can often be assembled visually from blocks.

Patterns, templates and synced patterns are not the same

Because WordPress now contains several types of reusable structures, they are easy to confuse.

Templates define page structure

A template determines the overall layout used for a particular type of request.

Examples include Single, Archive and 404.

Template parts define reusable structural sections

Headers and footers are the most common examples.

They are intended to be reused inside templates.

Patterns are predefined block layouts

A pattern is a predefined arrangement of one or more blocks.

Patterns are useful for quickly inserting layouts such as:

• hero sections;
• pricing tables;
• calls to action;
• testimonial sections;
• contact sections.

After insertion, an ordinary unsynced pattern becomes part of the local content and can be edited independently.

Synced patterns stay connected

A synced pattern represents reusable content that can update across multiple locations where that synced pattern is used.

This makes it useful for recurring elements such as:

• promotional banners;
• calls to action;
• standard legal notices;
• repeated contact sections.

The purpose differs from a template part even though both can create reusable structures.

Should you use a block theme?

Block themes provide significant flexibility, but that does not mean every WordPress project must immediately migrate to one.

A block theme makes sense when

• you want clients or editors to control headers and footers visually;
• you want to build templates without relying entirely on PHP;
• you want a consistent block-based design system;
• you rely heavily on patterns and Global Styles;
• you are starting a new project around modern WordPress architecture;
• you want site structure and content editing to share a similar interface.

A classic theme may still make sense when

• the site has a mature custom theme that works well;
• templates are deliberately controlled in code;
• client users should not edit structural templates;
• the project depends heavily on classic theme APIs;
• the migration cost would exceed the practical benefit;
• a page builder already controls the site’s design architecture.

There is no technical prize for converting a stable custom WordPress project to a block theme merely because block themes are newer.

The architecture should fit the project.

For a broader editor comparison, see Block Editor vs. Classic Editor: Which Fits Your Site?.

What happens when switching themes?

Changing from a classic theme to a block theme is more significant than simply changing the visual skin of the editor.

The two theme types can use different systems for:

• headers;
• footers;
• menus;
• sidebars;
• widgets;
• templates;
• global design settings.

Your post content remains separate

Posts and pages created with the Block Editor generally remain stored as post content regardless of the theme.

Changing the theme changes how that content is presented, not necessarily the content itself.

For more on that distinction, see Does Switching WordPress Editors Affect Your Content?.

Theme-specific layout structures may not transfer directly

A classic widget configuration does not automatically become a set of block-theme template parts.

Likewise, a classic menu location is not identical to the Navigation block architecture.

A migration should therefore review:

• navigation;
• sidebars;
• footer content;
• theme-specific shortcodes;
• widget-based plugin integrations;
• custom templates;
• CSS dependencies.

Full Site Editing and performance

Using the Site Editor does not automatically make a WordPress site faster or slower.

Performance depends on the blocks, theme, plugins, assets and queries used on the finished front end.

Blocks can load their own assets

Different blocks may require:

• CSS;
• JavaScript;
• fonts;
• server-side rendering;
• database queries.

A well-built block theme can be extremely efficient.

A poorly designed block-heavy page can still load unnecessary code.

The fact that a layout was created visually does not exempt it from normal front-end performance principles.

For how WordPress registers front-end assets properly, see wp_enqueue_scripts Explained.

Do not disable block assets blindly

Some optimization advice recommends removing Gutenberg or block CSS globally.

That can reduce unused CSS on a site that genuinely does not use blocks, but on a block theme those styles may be essential to the site’s actual design.

Optimization should be based on the active architecture rather than copied snippets.

How TheOneWP can help with the editor architecture

TheOneWP includes modules for sites that need more control over which WordPress editing experience is active.

Disable Gutenberg

Disable Gutenberg can be useful on projects intentionally built around the classic editing workflow.

This should be treated as an architectural choice, not a generic performance optimization.

If a site depends on block-theme editing, disabling the block editor indiscriminately would conflict with the way that site has been designed.

Remove Block Assets

Remove Block Assets addresses block-related front-end assets for sites where those resources are genuinely unnecessary.

Again, the important requirement is context.

A classic site that never renders blocks has different needs from a block theme whose front end is built from them.

The correct optimization is the one that matches the active site architecture.

Full Site Editing and block widgets checklist

• Full Site Editing is the broader concept behind editing site structure with blocks.
• The modern interface is called the Site Editor.
• The Site Editor is available with block themes.
• The Block Editor edits individual post and page content.
• The Site Editor can edit templates, template parts and global styles.
• A block theme is still a WordPress theme.
• Block themes generally use HTML block templates instead of traditional PHP templates for front-end structure.
• Templates define the overall structure of page types.
• Template parts define reusable structural sections such as headers and footers.
• User-edited templates can be stored in the WordPress database rather than overwriting theme files.
• theme.json provides settings and global style configuration.
• Global Styles can override theme design defaults.
• Classic themes can use the block-based Widgets editor.
• Using block widgets does not automatically mean the theme supports Full Site Editing.
• The block-based Widgets editor was introduced in WordPress 5.8.
• Legacy widgets can remain available through the Legacy Widget block in compatible classic-theme workflows.
• Block themes generally replace traditional widget areas with blocks in templates and template parts.
• The Navigation block handles modern block-based navigation.
• The Query Loop block can build dynamic post listings.
• Patterns, synced patterns, templates and template parts solve different problems.
• Switching to a block theme should be treated as an architectural migration, not merely an editor toggle.
• Do not remove block assets from a site that actually depends on them.

Related guides

• Block Editor vs. Classic Editor: Which Fits Your Site?
• How to Bring Back the Classic WordPress Editor
• Does Switching WordPress Editors Affect Your Content?
• Customizing the WordPress Block Editor Theme Color
• WordPress Block Editor CSS Explained
• wp_enqueue_scripts Explained
• px vs. em vs. rem CSS Units Explained
• WordPress Custom Post Types and SEO

Final thoughts

Full Site Editing is best understood as WordPress extending the block system from individual pieces of content to the architecture of the site itself.

With a block theme, blocks can define far more than paragraphs and images.

They can participate in:

• headers;
• footers;
• navigation;
• archives;
• single-post layouts;
• global styles;
• dynamic post listings;
• site-wide reusable structures.

The Site Editor is the interface that brings these systems together.

But it is important not to confuse every block-based interface in WordPress with Full Site Editing.

A classic theme can still use the block-based Widgets editor while continuing to rely on PHP templates, registered sidebars and the traditional theme architecture.

A block theme goes further: the theme’s templates and repeated structural sections themselves become block-based and editable through the Site Editor.

The modern WordPress model can therefore be summarized like this:

• Block Editor: edits the content of individual posts and pages.
• Widgets Block Editor: lets classic themes place blocks inside registered widget areas.
• Site Editor: lets block themes edit templates, template parts and site-wide design.
• Block theme: supplies the architecture that makes Site Editing possible.
• Global Styles and theme.json: define the site’s design system.

Once those distinctions are clear, Full Site Editing becomes much easier to understand.

It is not simply “Gutenberg for the whole website.” It is a different way of defining the relationship between WordPress content, theme structure and visual customization.