What Is WordPress Full Site Editing (FSE)?

Full Site Editing lets you design an entire WordPress site, headers, footers, archive templates, and all, visually with blocks, instead of writing PHP theme files by hand. Introduced incrementally starting with WordPress 5.9 in early 2022, FSE extends the block editor (Gutenberg) beyond post content into every part of a "block theme," turning template design into the same drag-and-drop, block-based experience editors already use for writing posts.

This guide covers what actually changed with FSE, how block themes differ structurally from classic PHP themes, the Site Editor interface, theme.json, and template parts, plus how this affects decisions like whether to build a custom theme or go headless.

Classic Themes vs. Block Themes

Before FSE, a WordPress theme's layout was defined almost entirely in PHP, following the Template Hierarchy: header.php and footer.php for the parts every page shares, single.php for a single post, archive.php for a list of posts, and so on, each file containing PHP template tags (the_title(), the_content(), wp_head()) mixed with HTML.

A block theme replaces those PHP template files with HTML files containing block markup, stored in a templates/ folder, plus a theme.json file that defines global styles and settings. A minimal block theme's single.html template might look like this:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title /-->
  <!-- wp:post-featured-image /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Every piece is a block: wp:post-title renders the current post's title, wp:post-content renders its content, wp:template-part pulls in a reusable header or footer defined elsewhere. None of this is PHP; it's the same block markup format the block editor writes for post content, just applied to page structure instead.

The Site Editor

FSE's main interface is the Site Editor, found under Appearance → Editor on any site running a block theme (it doesn't appear at all on classic PHP themes, since there's nothing for it to edit). From there, you can:

• Edit templates (the layout for a single post, an archive, the front page) directly, dragging blocks around exactly as you would in a post.
• Edit template parts (a header, a footer, a sidebar) once, with changes reflected everywhere that part is used.
• Adjust global styles, colors, typography, and spacing, applied site-wide, with live preview.
• Manage navigation menus as a block (wp:navigation) rather than through the older Menus screen.

This is the practical difference FSE makes for a site owner: template and layout changes that used to require editing PHP files (or hiring a developer to do it) can now happen through the same visual, block-based interface used for writing content.

theme.json: Centralized Design Tokens

theme.json is the configuration file at the root of a block theme that defines what design options are available in the editor and what the site's default styles are, colors, font sizes, spacing scale, layout widths, all declared as data rather than scattered across style.css and various add_theme_support() calls in functions.php.

A minimal example defining a color palette and a couple of typography defaults:

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 2,
  "settings": {
    "color": {
      "palette": [
        { "slug": "primary", "color": "#1e3a8a", "name": "Primary" },
        { "slug": "secondary", "color": "#f59e0b", "name": "Secondary" },
        { "slug": "base", "color": "#ffffff", "name": "Base" },
        { "slug": "contrast", "color": "#111111", "name": "Contrast" }
      ]
    },
    "typography": {
      "fontSizes": [
        { "slug": "small", "size": "14px", "name": "Small" },
        { "slug": "medium", "size": "18px", "name": "Medium" },
        { "slug": "large", "size": "32px", "name": "Large" }
      ]
    }
  },
  "styles": {
    "color": {
      "background": "var(--wp--preset--color--base)",
      "text": "var(--wp--preset--color--contrast)"
    }
  }
}

WordPress reads this file and does two things with it: it generates the corresponding options in the block editor's UI (the color palette above appears as swatches in every block's color picker), and it generates CSS custom properties (--wp--preset--color--primary, and so on) that both the editor and the front end use, keeping design tokens defined in exactly one place. This is covered in much more depth, including spacing, layout, and block-specific settings, in how to customize a block theme with theme.json.

Template Parts and Patterns

Two related concepts worth understanding clearly:

• Template parts are reusable pieces of a template, most commonly a header or footer, stored as their own HTML files under parts/ and inserted into templates with the wp:template-part block. Editing a template part once updates it everywhere it's used.
• Patterns are pre-arranged groups of blocks (a call-to-action section, a three-column feature grid) that a user inserts into a page as a starting point, then customizes freely. Unlike template parts, a pattern isn't a shared, synced reference by default, inserting one just copies its blocks in, though "synced patterns" (formerly called reusable blocks) behave more like template parts, updating everywhere at once when the source pattern changes.

Do You Still Need PHP for a Block Theme?

Less than you'd think, but not zero. A functional minimal block theme needs only a style.css header (for theme metadata), a theme.json, and a templates/index.html file, no PHP required at all. In practice, most real-world block themes still include a functions.php for things blocks and theme.json don't cover: registering custom block patterns programmatically, enqueueing additional stylesheets, adding support for specific features, or defining custom Gutenberg blocks (see how to create a custom Gutenberg block) that extend beyond what core blocks provide.

Style Variations

A block theme can ship multiple style variations, alternate theme.json files (stored under a styles/ folder) that swap out colors, fonts, or spacing without changing the underlying templates at all. WordPress surfaces these in the Site Editor's "Browse styles" panel, letting a site owner switch between, say, a light, warm palette and a darker, high-contrast one, with a single click and no code changes.

A minimal style variation file, styles/dark.json, might override just the color settings from the main theme.json:

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 2,
  "title": "Dark",
  "settings": {
    "color": {
      "palette": [
        { "slug": "base", "color": "#111111", "name": "Base" },
        { "slug": "contrast", "color": "#f5f5f5", "name": "Contrast" }
      ]
    }
  }
}

This is one of the more understated but genuinely useful FSE features for theme authors: it turns what used to require a separate child theme, or a "light/dark" settings toggle built entirely in custom PHP, into a handful of JSON files following a known schema.

Block-Based Widgets and the Legacy Widgets Screen

FSE also changed how widget areas work. Classic themes register named "sidebars" (a term left over from when widget areas were almost always literal page sidebars) via register_sidebar(), and the old Widgets screen lets you drag classic widgets into them. Block themes replace this with the Widgets editor built from the same block interface as everything else, and template parts can embed a wp:widget-area wherever a theme's design calls for one, styled and configured with the same blocks used everywhere else in the Site Editor. Plugins that register classic widgets generally still work, appearing as a "Legacy Widget" block that wraps the old widget for backward compatibility.

How This Changes the Custom Theme Decision

FSE doesn't replace classic PHP themes, both approaches remain fully supported, and plenty of well-maintained classic themes are still actively developed. But it does change the calculus for a new project:

• A block theme is generally the better starting point when a site's design can be expressed largely through core blocks, theme.json styling, and patterns, since it means far less custom PHP to write and maintain, and gives non-developer editors real control over layout without touching code.
• A classic PHP theme, whether built from scratch or as a child theme of an existing one, still makes sense when you need complex, code-driven logic in your templates (heavy conditional layouts, tight integration with a custom plugin's data) that would be awkward or impossible to express purely in blocks and theme.json.
• Headless WordPress is a separate axis entirely, see what is headless WordPress, and remains relevant regardless of whether the underlying theme is block-based or classic, since a headless setup typically doesn't use the theme's rendering at all.

Frequently Asked Questions (FAQ) About WordPress Full Site Editing

Conclusion

Full Site Editing moved WordPress theme design from PHP template files into the same block-based, visual editing experience already familiar from writing post content. Block themes replace header.php, footer.php, and the rest of the Template Hierarchy with HTML block markup and a centralized theme.json for design tokens, and the Site Editor gives site owners direct, visual control over templates, template parts, and global styles without touching code.

This doesn't retire classic PHP themes, both remain fully supported paths, and the right choice still depends on how much custom, code-driven logic your site's templates genuinely need. What it does mean is that a much larger share of WordPress sites can now get real layout flexibility without a developer writing PHP for every structural change. From here, the natural next steps are learning theme.json in depth and, if your design needs go beyond core blocks, building a custom Gutenberg block.

A few additional resources if you want to go deeper:

• WordPress Block Editor Handbook: Full Site Editing — the official developer documentation for FSE concepts and templates.
• WordPress Block Editor Handbook: theme.json — the full theme.json schema reference.
• Make WordPress Core: Full Site Editing — ongoing development updates from the WordPress core team.