WordPress Full Site Editing (FSE) has fundamentally changed how developers and designers build WordPress themes. Introduced in WordPress 5.9 and matured through subsequent releases, FSE gives you template-level control using the block editor — replacing the traditional PHP template hierarchy with a JSON and HTML block-based approach. In 2026, FSE is no longer a feature to “watch” — it’s the standard for modern WordPress theme development, and understanding it deeply is essential for anyone building custom WordPress themes today.

What Is WordPress Full Site Editing?

Full Site Editing extends the Gutenberg block editor beyond post and page content to cover every part of a WordPress website: headers, footers, sidebars, archive pages, single post templates, 404 pages, and more. Every area of the site becomes editable through a visual interface powered by blocks.

The technical foundation of FSE rests on three pillars:

  • Block Themes — themes that use block templates instead of PHP templates
  • Theme.json — a configuration file that defines design tokens (colors, typography, spacing, layout) for the entire site
  • Template Parts — reusable block-based components like headers and footers

Block Themes vs. Classic Themes: The Key Differences

Classic WordPress themes use PHP template files (header.php, single.php, archive.php) that mix HTML, PHP logic, and WordPress template tags. Block themes replace these with HTML files containing block markup, stored in the /templates and /parts directories.

Here’s what changes:

  • No more functions.php overload — many settings move to theme.json
  • Styles are tokens, not CSS overrides — define once in theme.json, apply everywhere
  • Templates are editable in the UI — non-developers can modify templates without touching code
  • Block patterns replace page builders — curated, reusable layout compositions

Understanding theme.json in 2026

The theme.json file is the most important new concept in FSE development. It’s a JSON configuration file at the root of your theme that controls the global design system. A solid theme.json covers:

Settings

Define what capabilities are available to users in the editor. You can enable or disable custom colors, custom font sizes, spacing controls, and more. You can register named color palettes, font families, and custom spacing scale values that appear as options in the editor sidebar.

{
  "settings": {
    "color": {
      "palette": [
        { "slug": "primary", "color": "#1a1a2e", "name": "Primary" },
        { "slug": "accent", "color": "#e94560", "name": "Accent" }
      ]
    },
    "typography": {
      "fontFamilies": [
        {
          "fontFamily": "Inter, sans-serif",
          "slug": "inter",
          "name": "Inter"
        }
      ]
    }
  }
}

Styles

The styles section in theme.json applies default values to elements and blocks. You can style headings, links, buttons, and individual blocks like the Query Loop or Navigation block — all without writing a single line of CSS. Global styles cascade down, and per-block styles override them precisely.

Building Block Templates

Block templates live in the /templates directory of your theme. The default template hierarchy still applies — WordPress looks for templates in a specific order:

  1. single-{post-type}-{slug}.html
  2. single-{post-type}.html
  3. single.html
  4. singular.html
  5. index.html

Templates contain serialized block markup — the same format you see when you copy blocks in the editor. The key blocks for templating are:

  • Post Title (core/post-title) — outputs the current post/page title
  • Post Content (core/post-content) — renders the post’s block content
  • Query Loop (core/query) — builds archive, blog, and filtered post lists
  • Template Part (core/template-part) — embeds reusable parts like header or footer

Block Patterns: The Modern Alternative to Page Builders

Block patterns are pre-designed combinations of blocks that users can insert from the pattern library. As a theme developer, you register patterns that match your design system, giving content editors a curated set of layout options without opening the door to design chaos.

In 2026, patterns are registered in the /patterns directory using PHP files with a header comment syntax. You can include full page layouts, hero sections, pricing tables, testimonial grids, and more — all built from core blocks.

Custom Blocks vs. Block Patterns vs. Block Variations

One of the most common questions in FSE development is when to build a custom block vs. a pattern vs. a block variation. Here’s a practical framework:

  • Custom block — when you need unique data, custom attributes, or external API integration. Best for dynamic data or highly specific UI not achievable with core blocks.
  • Block pattern — when you have a common layout that combines core blocks. No code overhead for the user, easy to update globally.
  • Block variation — when you want a pre-configured version of an existing block with specific default attributes. Useful for creating a “Featured Post Card” variation of the Group block.

Performance Considerations for Block Themes

FSE themes can be extremely lightweight — no jQuery dependency, no unnecessary PHP, minimal CSS. But performance is never automatic. Key practices:

  • Use theme.json styles instead of custom CSS files where possible — WordPress scopes them more efficiently
  • Avoid loading block styles globally — use enqueue_block_assets conditionally
  • Keep your block pattern count reasonable — unused pattern PHP files still load
  • Use the Interactivity API for dynamic front-end behavior instead of loading full JavaScript frameworks

The Future of FSE Development

WordPress FSE continues to evolve. The Interactivity API — stable since WordPress 6.5 — enables reactive, state-driven block behavior without external JavaScript frameworks. Dataviews is maturing into a standard interface component. Block Bindings API allows blocks to pull data from custom fields, post meta, or external sources without custom code.

For teams investing in WordPress development, mastering FSE is now a baseline requirement. The paradigm shift is significant, but the result is a more maintainable, performant, and editable codebase — which is ultimately better for both developers and clients.

If you’re migrating an existing classic theme to a block theme or starting a new WordPress project from scratch, the architectural decisions you make early have long-term implications. A structured approach to theme.json design tokens, template hierarchy, and pattern architecture will save significant refactoring time as the project scales.