WordPress Full Site Editing – A Complete Guide to FSE: theme.json, Templates, and Block Themes
Published: March 27, 2026 · Author: Marcin Szewczyk-Wilgan
WordPress Full Site Editing (FSE) is the most significant architectural change in WordPress history since the introduction of the Gutenberg editor in 2018. With Full Site Editing, the entire website – from the header, through page and post templates, to the footer – is built with blocks and managed visually from a single editor. No more scattered Customizer, PHP code in template files, or manually writing CSS for every layout change. WordPress FSE eliminates the need for third-party page builders in many scenarios and standardizes the way themes are built. In this article, we explain what WordPress Full Site Editing is, how it works technically, what the structure of a block theme looks like, what the theme.json file is, how to create templates and template parts in FSE, and when it is worth switching to Full Site Editing – and when it is better to stay with a classic theme.
What Is WordPress Full Site Editing?
WordPress Full Site Editing is a set of features introduced in WordPress 5.9 (January 2022) that extend the block editor (Gutenberg) to the entire site. Before FSE, blocks were used solely for building post and page content – the header, footer, sidebar, and templates remained under the control of PHP theme files. Full Site Editing changes this paradigm entirely.
In practice, WordPress Full Site Editing means that the header, footer, and navigation are built with blocks – just like page content. Templates defining the layout of pages, posts, archives, and 404 pages are HTML files containing blocks, not PHP files. Global Styles – colors, typography, margins, spacing – are configured centrally in the theme.json file and are visually accessible in the editor. Patterns (block patterns) are ready-made, reusable section layouts – hero sections, pricing tables, testimonials – that users insert with a single click.
FSE does not require the user to know code. At the same time, it gives developers full control over what users can change and what remains locked – through configuration in theme.json. You access the Full Site Editing editor via Appearance → Editor in the WordPress dashboard – provided the active theme is a block theme.
WordPress FSE vs. Classic Theme – Key Differences
A block theme compatible with Full Site Editing and a classic theme are two fundamentally different approaches to building a WordPress site. Understanding the differences is crucial before making a choice or migration decision.
single.php, page.php, archive.php) with WordPress functions like get_header(), the_content(). FSE block theme: HTML files in the /templates/ directory containing block markup.
style.css file, often spanning thousands of lines, with style overrides in child themes. FSE theme: theme.json file defines color palettes, typography, spacing, and generates CSS variables automatically.
Appearance → Customize). FSE theme: the Customizer is replaced by the Site Editor (Appearance → Editor), where everything is edited visually in Full Site Editing.
register_sidebar() in functions.php, widgets added separately. FSE theme: widgets and sidebars do not exist as separate elements – their role is fulfilled by blocks inserted directly into templates and template parts.
wp_nav_menu() with PHP, registering menu locations in functions.php. FSE theme: Navigation block, configured visually in the Site Editor.
Block Theme Structure in WordPress Full Site Editing
A WordPress block theme compatible with Full Site Editing has a precisely defined directory structure. Here is the minimal yet complete structure of a production FSE theme:
template-part block.
theme.json.
add_theme_support() for features controlled by theme.json.
The theme.json File – The Heart of a WordPress FSE Theme
The theme.json file is the central configuration element of every Full Site Editing theme. It replaces scattered add_theme_support() calls, CSS style overrides, and manual CSS variable creation. WordPress reads theme.json and uses it to generate CSS variables, configure the FSE editor interface, and define default block styles.
The current specification version is version 3 (from WordPress 6.6+). Here is an example of a complete theme.json with a color palette, typography, and layout configuration:
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 3,
"settings": {
"appearanceTools": true,
"color": {
"palette": [
{ "slug": "primary", "color": "#d97b3a", "name": "Primary" },
{ "slug": "secondary", "color": "#3d3d3a", "name": "Secondary" },
{ "slug": "background", "color": "#faf9f5", "name": "Background" },
{ "slug": "surface", "color": "#ffffff", "name": "Surface" },
{ "slug": "muted", "color": "#6b5e4f", "name": "Muted" }
],
"defaultPalette": false,
"defaultGradients": false
},
"typography": {
"fontFamilies": [
{
"fontFamily": "ui-monospace, SFMono-Regular, 'SF Mono', Menlo, Consolas, monospace",
"slug": "mono",
"name": "Monospace"
},
{
"fontFamily": "'Inter', -apple-system, BlinkMacSystemFont, sans-serif",
"slug": "sans",
"name": "Sans Serif"
}
],
"fontSizes": [
{ "slug": "small", "size": "0.875rem", "name": "Small" },
{ "slug": "medium", "size": "1rem", "name": "Medium" },
{ "slug": "large", "size": "1.25rem", "name": "Large" },
{ "slug": "x-large", "size": "1.75rem", "name": "Extra Large" },
{ "slug": "xx-large", "size": "2.5rem", "name": "2XL" }
],
"fluid": true
},
"layout": {
"contentSize": "720px",
"wideSize": "1100px"
},
"spacing": {
"units": ["rem", "px", "%"]
}
},
"styles": {
"color": {
"background": "var(--wp--preset--color--background)",
"text": "var(--wp--preset--color--secondary)"
},
"typography": {
"fontFamily": "var(--wp--preset--font-family--mono)",
"fontSize": "var(--wp--preset--font-size--medium)",
"lineHeight": "1.6"
},
"elements": {
"link": {
"color": { "text": "var(--wp--preset--color--primary)" }
},
"heading": {
"typography": { "fontWeight": "700" }
}
},
"blocks": {
"core/button": {
"color": {
"background": "var(--wp--preset--color--primary)",
"text": "var(--wp--preset--color--surface)"
},
"border": { "radius": "4px" }
}
}
},
"templateParts": [
{ "name": "header", "title": "Header", "area": "header" },
{ "name": "footer", "title": "Footer", "area": "footer" }
],
"customTemplates": [
{ "name": "blank", "title": "Blank", "postTypes": ["page"] },
{ "name": "full-width", "title": "Full Width", "postTypes": ["page", "post"] }
]
}What this file does in the context of WordPress Full Site Editing:
--wp--preset--color--primary, --wp--preset--color--secondary, etc. Setting defaultPalette: false hides WordPress’s default colors.
fluid: true flag enables fluid typography – sizes scale automatically between viewports.
contentSize (content width) and wideSize (width for “wide” blocks). Controls content centering and maximum width in the FSE editor.
Templates and Template Parts in WordPress FSE
Templates in a Full Site Editing block theme are HTML files containing block markup – WordPress block tags in HTML comment format. Here is an example of a minimal templates/single.html template – a single post template in FSE:
<!-- wp:template-part {"slug":"header","area":"header"} /-->
<!-- wp:group {"tagName":"main","layout":{"type":"constrained"}} -->
<main class="wp-block-group">
<!-- wp:post-title {"level":1} /-->
<!-- wp:post-date {"format":"j F Y"} /-->
<!-- wp:post-content {"layout":{"type":"constrained"}} /-->
<!-- wp:spacer {"height":"2rem"} -->
<div style="height:2rem" class="wp-block-spacer"></div>
<!-- /wp:spacer -->
<!-- wp:post-terms {"term":"category","prefix":"Categories: "} /-->
<!-- wp:post-terms {"term":"post_tag","prefix":"Tags: "} /-->
</main>
<!-- /wp:group -->
<!-- wp:template-part {"slug":"footer","area":"footer"} /-->And here is an example of a template part in FSE – the parts/header.html file:
<!-- wp:group {"tagName":"header","style":{"spacing":{"padding":{"top":"1rem","bottom":"1rem"}}},"layout":{"type":"constrained"}} -->
<header class="wp-block-group" style="padding-top:1rem;padding-bottom:1rem;">
<!-- wp:group {"layout":{"type":"flex","justifyContent":"space-between"}} -->
<div class="wp-block-group">
<!-- wp:site-title {"level":0} /-->
<!-- wp:navigation {"layout":{"type":"flex","justifyContent":"right"}} /-->
</div>
<!-- /wp:group -->
</header>
<!-- /wp:group -->Key dynamic blocks used in WordPress Full Site Editing templates:
slug attribute points to a file in /parts/. This is the foundation of FSE’s modular architecture.
while (have_posts()) loop. Allows displaying a list of posts with filters – one of the most powerful blocks in Full Site Editing.
wp_nav_menu() function.
Block Patterns in Full Site Editing
Block patterns are ready-made, predefined section layouts that users insert from the block inserter in the Full Site Editing editor. In the context of FSE, patterns are a powerful tool – they allow delivering ready-made hero sections, pricing tables, testimonials, and galleries without building them from scratch.
In an FSE block theme, patterns are registered as PHP files in the /patterns/ directory. WordPress automatically detects them and makes them available in the Full Site Editing editor. Here is an example of a hero section pattern:
<?php
/**
* Title: Hero Section
* Slug: my-fse-theme/hero-section
* Categories: featured
* Keywords: hero, banner, header
*/
?>
<!-- wp:cover {"dimRatio":50,"overlayColor":"secondary","minHeight":500,
"isDark":true,"layout":{"type":"constrained"}} -->
<div class="wp-block-cover is-dark" style="min-height:500px;">
<span class="wp-block-cover__background has-secondary-background-color
has-background-dim-50 has-background-dim"></span>
<div class="wp-block-cover__inner-container">
<!-- wp:heading {"textAlign":"center","level":1,
"style":{"typography":{"fontSize":"2.5rem"}}} -->
<h1 class="wp-block-heading has-text-align-center"
style="font-size:2.5rem;">Your Hero Heading</h1>
<!-- /wp:heading -->
<!-- wp:paragraph {"align":"center"} -->
<p class="has-text-align-center">A short description of your value proposition,
service, or offer. Two sentences maximum.</p>
<!-- /wp:paragraph -->
<!-- wp:buttons {"layout":{"type":"flex","justifyContent":"center"}} -->
<div class="wp-block-buttons">
<!-- wp:button -->
<div class="wp-block-button"><a class="wp-block-button__link
wp-element-button">Learn More</a></div>
<!-- /wp:button -->
</div>
<!-- /wp:buttons -->
</div>
</div>
<!-- /wp:cover -->Since WordPress 6.3, synced patterns are available (previously called reusable blocks). A change in one place propagates to all instances of the pattern across the site. Unsynced patterns are copied on insertion and can be edited independently. In the context of WordPress FSE, synced patterns work perfectly for CTA headers, promotional banners, and elements reused across multiple templates.
Global Styles – Styling Your Site in WordPress FSE
Global Styles is the interface in the WordPress FSE Site Editor that allows users to visually change colors, typography, spacing, and block styles for the entire site – without touching code. Behind the scenes, Global Styles saves user changes as overrides of values from theme.json.
The style hierarchy in WordPress Full Site Editing:
/styles/ directory.
This hierarchy works analogously to the CSS cascade – each subsequent level overrides the previous one. The developer defines solid defaults in theme.json, and the user has the ability to customize them within the boundaries the developer set in the settings section. This is one of the key mechanisms of WordPress Full Site Editing – control without limiting flexibility.
Example: if you set settings.color.custom: false in theme.json, the user will not be able to pick a custom color outside the defined palette. If you set settings.typography.customFontSize: false – the user will only be able to choose from predefined font sizes. This gives the developer full control over visual consistency of the site in FSE.
Style Book – Previewing the Design System in FSE
WordPress (from version 6.2+) offers the Style Book tool, available in the Full Site Editing Site Editor. Style Book displays a preview of all blocks with currently applied styles – in a single view. Typography, colors, buttons, forms, headings, lists, quotes – all visible on one screen.
Style Book allows you to verify the consistency of the FSE theme’s design system before publishing. If you change the global font or color palette in Global Styles, Style Book immediately shows how the change affects every block in WordPress Full Site Editing. It is the equivalent of a “living style guide” known from front-end design systems – but natively built into WordPress.
For FSE theme developers, Style Book is an invaluable tool for verifying that theme.json generates a consistent design system – before the theme reaches the end user.
Custom Blocks in WordPress FSE – Building with Code
Full Site Editing is not limited to built-in blocks. Developers can create custom blocks that integrate with the FSE editor and use the theme.json styling system. Block registration in WordPress Full Site Editing is done via the block.json file:
{
"$schema": "https://schemas.wp.org/trunk/block.json",
"apiVersion": 3,
"name": "my-theme/cta-box",
"title": "CTA Box",
"category": "design",
"icon": "megaphone",
"description": "A call-to-action block with heading, description, and button.",
"supports": {
"html": false,
"color": {
"background": true,
"text": true
},
"spacing": {
"padding": true,
"margin": true
},
"typography": {
"fontSize": true
}
},
"textdomain": "my-theme",
"editorScript": "file:./index.js",
"style": "file:./style.css",
"render": "file:./render.php"
}The block.json file defines the block name, icon, category, and – most importantly – the supports section. It is the supports section that determines which controls from theme.json will be available for this block in the FSE editor: colors, spacing, typography. WordPress automatically generates appropriate CSS classes and variables for the block, maintaining consistency with the global Full Site Editing style system.
Custom blocks combined with theme.json and patterns create a complete design system where the developer controls the architecture, and the user controls content and visual personalization within WordPress FSE.
Migrating to WordPress Full Site Editing – Key Steps
Transitioning from a classic theme to a Full Site Editing block theme is not a trivial task, but it is fully achievable – even on a live production site. Here are the key stages of migrating to WordPress FSE:
Audit the current theme
Identify all elements: which templates are in use, which widgets, which menu locations, which custom styles. Create a list of functions from functions.php that will need to be migrated or replaced in the new FSE theme.
Backup and staging
Migration to Full Site Editing always takes place on a staging environment, never directly on production. A full backup of the database and files is the absolute minimum before starting work.
Build theme.json
Transfer the color palette, typography, layout, and editor settings from style.css and functions.php to theme.json. This is the most challenging stage of FSE migration, requiring precise mapping of existing styles to JSON format.
Convert templates to FSE
Transform PHP templates (header.php, footer.php, single.php) into HTML files with block markup in the /templates/ and /parts/ directories. Dynamic elements are replaced with corresponding Full Site Editing blocks.
Patterns and widgets
Sections that were previously widgets or hardcoded in PHP become block patterns or template parts in the new FSE theme.
Testing
Check all content types (pages, posts, archives, search, 404), responsiveness, performance, and plugin compatibility with Full Site Editing. Pay special attention to plugins that use the Customizer.
WordPress FSE Performance vs. Page Builders
One of the key advantages of WordPress Full Site Editing is performance. Classic page builders (Elementor, Divi, WPBakery) load their own CSS and JavaScript frameworks – often hundreds of kilobytes of additional code – regardless of which blocks the user actually uses. WordPress FSE works differently.
Block themes compatible with Full Site Editing use WordPress’s native rendering system. Styles are generated from theme.json as CSS variables, and only styles for blocks actually used on the page are loaded. WordPress automatically inserts inline styles for specific blocks, eliminating unused CSS. There is no additional JS framework on the frontend (except for interactive blocks using the Interactivity API).
When to Choose Full Site Editing, and When a Classic Theme?
WordPress Full Site Editing is not a solution for every project. Here are practical guidelines for choosing between FSE and the classic approach:
theme.json even in classic themes. You can gradually introduce Full Site Editing elements – e.g., color and typography configuration – without a full migration to an FSE block theme. This is a good transitional strategy.
Summary – The Future of WordPress Is Full Site Editing
WordPress Full Site Editing is not just another plugin or trend – it is a fundamental architectural change that defines the future of WordPress. The theme.json file replaces scattered configuration in PHP and CSS, HTML templates with block markup replace PHP templates, and the Site Editor gives users visual control over the entire site within FSE. Full Site Editing eliminates the need for page builders in many scenarios, improves performance, and standardizes how themes are built.
Switching to WordPress FSE requires an investment of time to learn the new architecture – but it pays off quickly: faster sites, easier maintenance, less code, and greater independence from third-party tools. With WordPress 7.0 and subsequent releases, Full Site Editing will only gain in functionality and maturity.
At WebOptimo, we build and maintain WordPress sites on both classic themes and Full Site Editing block themes. If you are considering migrating to FSE, need a block theme built from scratch, or want to consult whether WordPress Full Site Editing is right for your project – get in touch or check our WordPress development services.
Frequently Asked Questions About WordPress Full Site Editing
WordPress Full Site Editing is a set of features that allow editing the entire website – header, footer, templates, navigation, and global styles – from the block editor. FSE replaces the Customizer and traditional PHP templates, giving users full visual control over the site without writing code.
Yes. To use all WordPress FSE features, you need a block theme. Classic themes can use some FSE elements (e.g., theme.json), but full site editing requires a theme designed for FSE – such as Twenty Twenty-Four or Twenty Twenty-Five.
Full Site Editing offers a native, performant alternative to page builders. It does not require additional plugins, does not load external frameworks, and is built into WordPress core. For new projects, FSE is often a better choice in terms of performance and maintenance. Existing sites with deep page builder integrations may, however, stay with their current solution.
theme.json is the central configuration file of a WordPress FSE block theme. It defines color palettes, typography, layout settings, editor controls, default block styles, and structural elements of the theme. WordPress generates CSS variables from it and configures the Site Editor interface.
Partially. Since WordPress 5.8, the theme.json file also works in classic themes – allowing configuration of colors, typography, and block editor settings. However, the full Site Editor (editing header, footer, templates) requires an FSE block theme.
Yes. FSE has been a stable part of WordPress core since version 5.9 (January 2022). With each subsequent release – 6.x and the upcoming 7.0 – Full Site Editing functionality is being expanded and stabilized. FSE block themes run on production sites worldwide.
Simply install and activate a block theme – e.g., Twenty Twenty-Five. After activating a block theme, the Appearance → Editor option will appear in the WordPress dashboard, giving access to the full site editor with the ability to edit templates, template parts, navigation, and global styles.
Page builders (Elementor, Divi, WPBakery) are third-party plugins with their own CSS/JS frameworks that often bloat the site. WordPress Full Site Editing is a native WordPress core feature – it requires no additional plugins, generates less code, is faster, and provides full content portability between FSE block themes.


