WordPress Full Site Editing: The Complete 2026 Developer Guide (Updated)

WordPress Full Site Editing has matured past the point of being a “new” paradigm. With WordPress 6.8 shipping in April 2026, FSE now includes Pattern Overrides, a Connectors API alpha, expanded posttypes meta support for wp_template registration, and a Site Editor that handles real content management workflows. This guide covers the full developer picture for 2026: theme.json evolution, the template registration system, Pattern Overrides implementation, what the Connectors API means for data-driven themes, and the site editor changes you need to know.

If you are coming from a classic PHP theme background and want the full architectural picture, start with the sections on block theme structure and template registration. If you are already building block themes and want the 2026-specific additions, jump to the Pattern Overrides, Connectors API, and posttypes meta sections.

What FSE Is in 2026: A Clear Definition

Full Site Editing is the collection of features that extends the Gutenberg block editor to the entire site structure, not just post content. In 2026, FSE is not experimental and not optional for serious theme development. It is the standard.

FSE consists of four integrated layers:

• Site Editor, Visual interface for editing all templates, template parts, patterns, and navigation (Appearance > Editor)
• Block Themes, Themes built with HTML templates and theme.json instead of PHP template files
• Global Styles, Centralized design token system backed by theme.json and overridable through the editor UI
• theme.json, Configuration file declaring settings, styles, supported features, and template structure

The practical difference from classic themes: block themes make every site element editable through the block editor without code. Theme developers define what can be customized and what stays locked. Users get visual control; developers retain design integrity.

Block Themes vs. Classic Themes: 2026 Comparison

Block Theme Structure: Minimum Viable to Production

A minimal block theme needs three files. A production theme needs more, but understanding the minimum helps you see how FSE’s file system maps to classic WordPress template logic.

my-fse-theme/
├── style.css                  # Theme metadata (required)
├── theme.json                 # Theme configuration (required)
├── templates/
│   ├── index.html             # Main fallback template (required)
│   ├── single.html            # Single post template
│   ├── page.html              # Page template
│   ├── archive.html           # Archive template
│   ├── 404.html               # 404 error template
│   ├── search.html            # Search results template
│   └── home.html              # Blog posts page
├── parts/
│   ├── header.html            # Header template part
│   ├── footer.html            # Footer template part
│   └── sidebar.html           # Sidebar template part
└── patterns/
    ├── hero-section.php       # Block pattern (auto-registered from header comments)
    └── cta-banner.php         # Call-to-action pattern

The file naming follows the classic WordPress template hierarchy exactly. single.html maps to single.php, archive.html maps to archive.php. The hierarchy applies the same specificity rules: single-product.html takes priority over single.html for the “product” post type.

template.json and posttypes Meta: wp_template Registration

One of the most-searched topics in 2026 FSE development is the posttypes meta key on wp_template posts. This is the mechanism that controls which post types a custom template applies to, and it powers how the Site Editor exposes templates to editors.

How posttypes Meta Works on wp_template

Every template stored in the WordPress database (the wp_template custom post type) carries a wp_theme taxonomy term (identifying which theme owns it) and a posttypes post meta value. The posttypes meta is an array of post type slugs that the template applies to. When a user opens a post in the editor, WordPress checks this meta to determine which templates are available to assign.

// Querying wp_template posts filtered by posttypes meta
$templates = get_posts( [
    'post_type'  => 'wp_template',
    'meta_query' => [
        [
            'key'     => 'posttypes',
            'value'   => 'product',   // WooCommerce product post type
            'compare' => 'LIKE',
        ],
    ],
] );

// Reading posttypes meta from a template
$post_id  = 1234; // wp_template post ID
$posttypes = get_post_meta( $post_id, 'posttypes', true );
// Returns: array( 'post', 'page' ) or a serialized equivalent

Registering Custom Templates with posttypes in theme.json

The recommended way to declare which post types a custom template supports is through the customTemplates field in theme.json. WordPress syncs this declaration to the posttypes meta on the corresponding wp_template post when the theme is activated:

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "customTemplates": [
    {
      "name": "single-product",
      "title": "Single Product",
      "postTypes": [ "product" ]
    },
    {
      "name": "landing-page",
      "title": "Landing Page",
      "postTypes": [ "page" ]
    },
    {
      "name": "author-bio",
      "title": "Author Bio Page",
      "postTypes": [ "page", "post" ]
    }
  ]
}

Each entry in customTemplates corresponds to an HTML file in your theme’s templates/ directory. The postTypes array maps directly to the posttypes meta that WordPress stores on the wp_template post. If you need to register a template for a post type that is not part of your theme (like a plugin’s CPT), use the init hook instead:

// Register a template for a CPT defined by a plugin (not your theme)
add_filter( 'theme_templates', function( $templates, $theme, $post, $post_type ) {
    if ( 'product' === $post_type ) {
        $templates['single-product'] = __( 'Single Product Template', 'my-theme' );
    }
    return $templates;
}, 10, 4 );

// Or use the REST API approach for programmatic template creation:
// POST /wp/v2/templates with { slug, theme, type, content, wp_id, title, posttypes }

posttypes Meta in the REST API

When querying the WordPress REST API for templates, the posttypes field is exposed as a top-level field on the template object. This is critical for headless WordPress setups that need to serve the correct template data per post type:

// GET /wp/v2/templates?per_page=100
// Each template object includes:
{
  "id": "my-theme//single-product",
  "slug": "single-product",
  "theme": "my-theme",
  "type": "wp_template",
  "source": "theme",
  "origin": "theme",
  "title": { "raw": "Single Product", "rendered": "Single Product" },
  "posttypes": [ "product" ]
}

// Filter templates by post type via REST:
// GET /wp/v2/templates?post_type=product

The ?post_type=product query parameter filters templates to those with product in their posttypes meta. This was inconsistently supported before WordPress 6.7; the 6.8 REST API improvements standardized this filtering across all post types.

theme.json in 2026: Version 3 Deep Dive

Theme.json version 3 shipped in WordPress 6.6 and is the required format for 7.0-compatible themes. The schema changes from version 2 are mostly additive, but several version 3 features are significant for production themes.

What Changed from Version 2 to Version 3

• Longhand/shorthand CSS property mapping, version 3 normalizes how border, margin, and padding properties resolve when both longhand and shorthand values are present in styles. Version 2 had inconsistent behavior.
• Block style variations as first-class objects, version 3 formalizes block style variation registration in theme.json under styles.blocks.{blockName}.variations, replacing the PHP-only register_block_style() approach for most use cases.
• Fluid typography improvements, version 3 added fluidTypography.minFontSize and fluidTypography.maxFontSize at the global level, controlling the responsive range for all fluid font sizes without per-size overrides.
• Shadow presets, settings.shadow.presets and settings.shadow.defaultPresets added to manage reusable shadow tokens.

Production theme.json Configuration

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "appearanceTools": true,
    "layout": {
      "contentSize": "800px",
      "wideSize": "1200px"
    },
    "color": {
      "palette": [
        { "slug": "primary",  "color": "#1e40af", "name": "Primary" },
        { "slug": "secondary","color": "#7c3aed", "name": "Secondary" },
        { "slug": "base",     "color": "#ffffff", "name": "Base" },
        { "slug": "contrast", "color": "#0f172a", "name": "Contrast" },
        { "slug": "neutral",  "color": "#f1f5f9", "name": "Neutral" }
      ]
    },
    "typography": {
      "fluid": true,
      "fluidTypography": {
        "minFontSize": "14px",
        "maxFontSize": "20px"
      },
      "fontFamilies": [
        {
          "slug": "heading",
          "name": "Heading",
          "fontFamily": "'Inter', sans-serif",
          "fontFace": [
            {
              "fontFamily": "Inter",
              "fontWeight": "700",
              "fontStyle": "normal",
              "src": [ "file:./assets/fonts/inter-bold.woff2" ]
            }
          ]
        },
        {
          "slug": "mono",
          "name": "Monospace",
          "fontFamily": "'JetBrains Mono', monospace",
          "fontFace": [
            {
              "fontFamily": "JetBrains Mono",
              "fontWeight": "400",
              "fontStyle": "normal",
              "src": [ "file:./assets/fonts/jetbrains-mono.woff2" ]
            }
          ]
        }
      ]
    },
    "shadow": {
      "presets": [
        { "slug": "sm", "shadow": "0 1px 3px rgba(0,0,0.12)", "name": "Small" },
        { "slug": "md", "shadow": "0 4px 6px rgba(0,0,0.1)",  "name": "Medium" },
        { "slug": "lg", "shadow": "0 10px 25px rgba(0,0,0.1)","name": "Large" }
      ]
    }
  },
  "styles": {
    "blocks": {
      "core/code": {
        "color": {
          "background": "#0f172a",
          "text":       "#e2e8f0"
        },
        "typography": {
          "fontFamily": "var(--wp--preset--font-family--mono)"
        },
        "variations": {
          "inline-dark": {
            "color": {
              "background": "#1e293b",
              "text":       "#94a3b8"
            }
          }
        }
      }
    }
  },
  "customTemplates": [
    { "name": "blank",        "title": "Blank",        "postTypes": [ "page", "post" ] },
    { "name": "landing-page", "title": "Landing Page", "postTypes": [ "page" ] }
  ],
  "templateParts": [
    { "name": "header", "title": "Header", "area": "header" },
    { "name": "footer", "title": "Footer", "area": "footer" }
  ]
}

Pattern Overrides: The 2026 Design Contract

Pattern Overrides shipped as stable in WordPress 6.8 and change how theme developers think about synced pattern design. The old model was binary: a synced pattern either locked everything or users detached it to customize. Pattern Overrides add a third state: locked structure, overridable content.

The Override Mechanism

A block inside a synced pattern becomes overridable by adding a core/pattern-overrides binding to the attribute. The block keeps its default value from the pattern definition but accepts per-instance customization:

<!-- wp:heading {
  "metadata": {
    "id": "hero-headline",
    "bindings": {
      "content": {
        "source": "core/pattern-overrides"
      }
    }
  }
} -->
<h2 class="wp-block-heading">Default Headline Text</h2>
<!-- /wp:heading -->

<!-- wp:paragraph {
  "metadata": {
    "id": "hero-body",
    "bindings": {
      "content": {
        "source": "core/pattern-overrides"
      }
    }
  }
} -->
<p>Default body text that editors can customize per page.</p>
<!-- /wp:paragraph -->

What Can Be Overridden

Pattern Overrides support these block attributes in WordPress 6.8:

• content, paragraph, heading, button text
• url, button link href
• alt, image alt text
• title, image title attribute

Styling attributes (colors, spacing, typography) are not overridable, they remain locked to the pattern definition. This is intentional: it preserves design integrity while giving editorial freedom.

Pattern Overrides with Connectors API

When the Connectors API reaches stable status in WordPress 7.0, overridable pattern attributes can be bound to external data sources rather than manual editor input. A product card pattern’s price and availability overrides could come from a WooCommerce product via the Connectors API binding, removing the manual editing step entirely.

Connectors API Preview: What It Means for FSE Developers

The Connectors API is in alpha as of WordPress 6.8. It is the next evolution of the Block Bindings architecture and the feature that will make FSE viable for data-driven template designs at scale.

Block Bindings API vs. Connectors API

For theme developers: implement Block Bindings now for dynamic template attributes. The Connectors API will layer an editor UI on top of your existing bindings when it stabilizes in 7.0.

// Register a binding source for template meta fields
register_block_bindings_source(
    'my-theme/template-meta',
    [
        'label'              => __( 'Template Meta', 'my-theme' ),
        'get_value_callback' => function( $source_args, $block_instance ) {
            $key     = $source_args['key'] ?? '';
            $post_id = $block_instance->context['postId'] ?? get_the_ID();
            return get_post_meta( $post_id, sanitize_key( $key ), true );
        },
        'uses_context' => [ 'postId' ],
    ]
);

// Usage in a template (binds the heading to a custom meta field):
// <!-- wp:heading {
//   "metadata": {
//     "bindings": {
//       "content": {
//         "source": "my-theme/template-meta",
//         "args": { "key": "_page_hero_headline" }
//       }
//     }
//   }
// } -->

Site Editor Changes in WordPress 6.8

The Site Editor (Appearance > Editor) received several workflow improvements in WordPress 6.8 that affect how developers build and QA block themes.

Improved Data Views

The Data Views interface introduced in 6.5 for managing templates and patterns now includes persistent filter state, improved column sorting, and keyboard navigation. For themes with large pattern libraries (50+ patterns), this makes the Site Editor viable as a day-to-day pattern management tool.

Template Preview on Hover

The template list in the Site Editor shows a live preview thumbnail on hover in 6.8. For QA workflows reviewing multiple template variants, this eliminates the click-through cycle for visual verification.

Pattern Override Editing UI

When a synced pattern contains overridable blocks, the 6.8 Site Editor shows a new “Override” indicator on those blocks. Clicking the indicator opens an inline edit panel showing the current override value and the pattern default. This is the editor-facing implementation of the Pattern Overrides feature.

Style Book Updates

The Style Book (the preview panel for Global Styles) now includes interactive states: hover, focus, and active states for buttons, links, and form elements. Theme developers can verify these states without leaving the editor or writing test HTML.

Building Templates with the Site Editor

Templates in FSE follow the same hierarchy as classic PHP templates. The Site Editor stores customized templates as wp_template posts in the database; your theme’s HTML files are the fallback source.

Single Post Template

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

<!-- wp:group {"tagName":"main","layout":{"type":"constrained"}} -->
<main class="wp-block-group">

  <!-- wp:group {"style":{"spacing":{"padding":{"top":"var:preset|spacing|50","bottom":"var:preset|spacing|30"}}}} -->
  <div class="wp-block-group">
    <!-- wp:post-title {"level":1} /-->
    <!-- wp:group {"layout":{"type":"flex","flexWrap":"nowrap"},"style":{"spacing":{"blockGap":"1rem"}}} -->
    <div class="wp-block-group">
      <!-- wp:post-date /-->
      <!-- wp:post-author {"showAvatar":false} /-->
      <!-- wp:post-terms {"term":"category"} /-->
    </div>
    <!-- /wp:group -->
  </div>
  <!-- /wp:group -->

  <!-- wp:post-featured-image {"aspectRatio":"16/9","style":{"border":{"radius":"8px"}}} /-->

  <!-- wp:post-content {"layout":{"type":"constrained"}} /-->

  <!-- wp:post-terms {"term":"post_tag","prefix":"Tags: "} /-->

  <!-- wp:comments /-->

</main>
<!-- /wp:group -->

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

Query Loop for Archive Templates

<!-- wp:query {"queryId":1,"query":{"perPage":12,"postType":"post","order":"desc","orderBy":"date","inherit":false},"displayLayout":{"type":"flex","columns":3}} -->
<div class="wp-block-query">

  <!-- wp:post-template {"layout":{"type":"grid","columnCount":3}} -->
    <!-- wp:post-featured-image {"isLink":true,"aspectRatio":"16/9","style":{"border":{"radius":"6px"}}} /-->
    <!-- wp:post-title {"isLink":true,"level":3} /-->
    <!-- wp:post-excerpt {"excerptLength":20} /-->
    <!-- wp:post-date {"textColor":"neutral"} /-->
  <!-- /wp:post-template -->

  <!-- wp:query-pagination {"layout":{"type":"flex","justifyContent":"center"}} -->
    <!-- wp:query-pagination-previous /-->
    <!-- wp:query-pagination-numbers /-->
    <!-- wp:query-pagination-next /-->
  <!-- /wp:query-pagination -->

</div>
<!-- /wp:query -->

Block Patterns in 2026: Auto-Registration and Synced Patterns

Block patterns are auto-registered from PHP files in the patterns/ directory using header comments. This approach, introduced in WordPress 6.0, is the standard for 2026 themes:

<?php
/**
 * Title: Hero with Pattern Override
 * Slug: my-theme/hero-override
 * Description: Hero pattern with overridable headline and CTA text.
 * Categories: featured, banner
 * Keywords: hero, override, cta
 * Viewport Width: 1200
 * Block Types: core/group
 * Inserter: true
 */
?>

<!-- wp:group {"align":"full","style":{"spacing":{"padding":{"top":"5rem","bottom":"5rem"}}},"backgroundColor":"contrast","textColor":"base","layout":{"type":"constrained"}} -->
<div class="wp-block-group alignfull has-base-color has-contrast-background-color">

  <!-- wp:heading {
    "textAlign":"center","level":1,
    "metadata":{
      "id":"hero-title",
      "bindings":{"content":{"source":"core/pattern-overrides"}}
    }
  } -->
  <h1 class="wp-block-heading has-text-align-center">Your Headline Here</h1>
  <!-- /wp:heading -->

  <!-- wp:paragraph {
    "align":"center",
    "metadata":{
      "id":"hero-body",
      "bindings":{"content":{"source":"core/pattern-overrides"}}
    }
  } -->
  <p class="has-text-align-center">Your subheadline that editors can customize.</p>
  <!-- /wp:paragraph -->

  <!-- wp:buttons {"layout":{"type":"flex","justifyContent":"center"}} -->
  <div class="wp-block-buttons">
    <!-- wp:button {"backgroundColor":"primary"} -->
    <div class="wp-block-button"><a class="wp-block-button__link has-primary-background-color has-background wp-element-button">Get Started</a></div>
    <!-- /wp:button -->
  </div>
  <!-- /wp:buttons -->

</div>
<!-- /wp:group -->

Synced Patterns: When to Use Them

Synced patterns maintain a single source of truth: every instance updates when the source changes. Use synced patterns for elements that must stay consistent across the entire site: site-wide promotional banners, newsletter signup forms, footer CTA sections.

Do not use synced patterns for content that varies per page. That is Pattern Overrides territory. The decision tree:

• Content is the same everywhere and locked: synced pattern with no overrides
• Structure is the same but content varies per page: synced pattern with Pattern Overrides
• Each instance is fully independent: regular (non-synced) pattern

Advanced FSE Techniques for 2026

Block Style Variations via theme.json (Version 3)

In theme.json version 3, block style variations are registered directly in the config rather than through PHP:

{
  "styles": {
    "blocks": {
      "core/button": {
        "variations": {
          "gradient-cta": {
            "color": {
              "background": "linear-gradient(135deg, #1e40af, #7c3aed)",
              "text": "#ffffff"
            },
            "border": { "radius": "50px" },
            "typography": { "fontWeight": "700", "textTransform": "uppercase" }
          }
        }
      }
    }
  }
}

Custom Template Hierarchy for CPTs

FSE template hierarchy mirrors PHP exactly. Create specific templates for post types, taxonomies, and individual posts:

• templates/single-product.html, single posts of the “product” CPT
• templates/taxonomy-genre.html, “genre” custom taxonomy archive
• templates/page-about.html, the specific page with slug “about”
• templates/category-tutorials.html, the “tutorials” category archive
• templates/author.html, all author archive pages

Register CPT-specific templates in theme.json’s customTemplates array with the CPT slug in postTypes. This syncs the posttypes meta on the corresponding wp_template database record.

wp_enqueue_block_style() for Conditional CSS

WordPress only loads block CSS for blocks actually used on a given page (since 6.5). For custom block styles, use wp_enqueue_block_style() to follow the same pattern:

// Load CSS only when core/code block is present on the page
add_action( 'init', function() {
    wp_enqueue_block_style(
        'core/code',
        [
            'handle' => 'my-theme-code-block',
            'src'    => get_theme_file_uri( 'assets/css/code-block.css' ),
            'path'   => get_theme_file_path( 'assets/css/code-block.css' ),
        ]
    );
} );

Global Styles and Style Variations

Global Styles is the editor UI for theme.json. Changes made through Global Styles are stored as a wp_global_styles post in the database and override the theme’s theme.json defaults. This separation means users can customize the design without modifying theme files, and theme updates do not overwrite user customizations.

Style variations are alternative theme.json configurations stored as JSON files in the styles/ directory:

my-fse-theme/
└── styles/
    ├── dark-mode.json      # Dark color scheme variation
    ├── high-contrast.json  # Accessibility-focused variation
    └── compact.json        # Reduced spacing variation

Each variation file contains only the settings and styles that differ from the base theme.json. WordPress merges them at runtime. Users switch between variations through Global Styles > Browse Styles in the Site Editor.

Migrating from Classic Themes to FSE

Migration is a phased process. WordPress supports hybrid themes (mixing PHP and HTML templates), which means you can convert one template at a time without breaking the site.

Migration Sequence

1. Add theme.json, create a theme.json with your existing design tokens (colors, fonts, spacing). This works in classic themes and starts the FSE adoption without breaking anything.
2. Convert simple templates first, start with 404.html, search.html, and home.html. These are the simplest PHP-to-HTML conversions with no dynamic logic.
3. Convert header and footer to template parts, replace get_header() and get_footer() patterns with parts/header.html and parts/footer.html.
4. Replace widget areas with template parts, each register_sidebar() area becomes a template part with the equivalent blocks.
5. Convert single and archive templates, these are the most complex because they replicate PHP loop logic with Query Loop and Post Template blocks.
6. Register custom templates via theme.json, update customTemplates to reflect all templates and their supported post types (posttypes meta).

Performance Best Practices for Block Themes

1. Use theme.json for all styling, theme.json generates optimized CSS custom properties. Avoid large custom CSS files for things theme.json can handle declaratively.
2. Self-host fonts via fontFace in theme.json, eliminates external DNS lookups, improves GDPR compliance, and reduces render-blocking requests.
3. Use wp_enqueue_block_style() for block-specific CSS, only loads when the block is present on the page.
4. Keep pattern block hierarchies shallow, deeply nested patterns generate deep DOM trees. Flatten layouts where the nesting is structural (not functional).
5. Audit autoloaded options, WordPress 6.8 continued the 6.7 work on autoload reduction. Check Site Health for autoloaded options bloat, especially if your theme registers options on activation.

Troubleshooting Common FSE Issues in 2026

• Template not appearing for a CPT, verify the posttypes meta on the wp_template post includes your CPT slug. Check theme.json’s customTemplates[].postTypes array and flush rewrite rules after theme activation.
• Pattern Override not saving, confirm the overridable block has a unique metadata.id value within the pattern. Duplicate IDs cause the override system to discard one value.
• Global Styles changes not persisting, Global Styles write to a wp_global_styles CPT record. If a caching plugin caches the REST API, style changes may appear to not save. Exclude /wp/v2/global-styles from your cache.
• theme.json version 3 styles not applying, validate your JSON against the $schema URL. A missing comma in a deeply nested object breaks the entire styles tree silently. Use a JSON linter before pushing.
• Navigation block losing items, the Navigation block references a wp_navigation post. If the post is deleted or becomes an orphan (theme switch), the block shows empty. Re-assign or re-create the navigation post via Appearance > Editor > Navigation.
• Font file path errors, all fontFace.src paths must use the file:./ prefix relative to the theme root. file:./assets/fonts/font.woff2 is correct; /assets/fonts/font.woff2 without the prefix fails silently.

What FSE Looks Like in WordPress 7.0

WordPress 7.0 completes Phase 3 of the Gutenberg roadmap, and FSE is the primary beneficiary. For a full 7.0 overview including beta and RC timeline, see our complete WordPress 7.0 roadmap guide. The FSE-specific changes in 7.0:

• Real-time co-editing in the Site Editor, multiple editors on the same template simultaneously, with presence indicators and block-level locking
• Connectors API stable, plugin data sources appear in the block attribute binding UI without code, enabling no-code dynamic templates
• Pattern Overrides extended, additional attribute types (layout, colors with permission flags) expected to become overridable in the 7.0 window
• Template revision history, block-aware revision comparison for templates, not just post content
• Admin redesign stable, the incremental admin UI updates from 6.7 and 6.8 reach a complete, stable state in 7.0

Frequently Asked Questions

What is posttypes meta on wp_template?

The posttypes post meta on a wp_template post is an array of post type slugs that controls which post types the template applies to. WordPress uses it to populate the “Template” dropdown when editing a post or page. You set it via the customTemplates[].postTypes array in theme.json, or directly via the REST API when creating templates programmatically.

What are Pattern Overrides and how are they different from synced patterns?

Synced patterns keep all instances synchronized with the source pattern. Pattern Overrides (stable in WordPress 6.8) let specific blocks inside a synced pattern be customized per instance without detaching. You declare overridable blocks using the core/pattern-overrides binding source on the attribute you want to unlock. Structure stays locked; designated content attributes become editable per-use.

What is the Connectors API?

The Connectors API is a new editor UI layer (alpha in WordPress 6.8, targeting stable in 7.0) that makes the Block Bindings API discoverable to non-developers. Plugins register data sources through the API; users connect those sources to block attributes through a point-and-click interface in the editor, without writing code or editing block markup directly.

Do I need PHP to build a block theme?

The minimum viable block theme (style.css, theme.json, templates/index.html) requires zero PHP. PHP remains valuable for block pattern registration (via PHP file headers, which is PHP but minimal), functions.php for enqueuing block styles, and custom Block Bindings registration. For complex data-driven themes, PHP is necessary for the server-side binding callbacks.

Is FSE production-ready in 2026?

Yes. FSE has been stable since WordPress 6.2. The ecosystem has adapted: the default theme (Twenty Twenty-Five) is a block theme, major hosting companies test specifically against block themes, and the pattern library ecosystem has matured. Pattern Overrides and the Connectors API add new capabilities, but the core FSE features are production-stable.

How does theme.json version 3 differ from version 2?

Version 3 normalizes longhand/shorthand CSS property resolution, formalizes block style variations as first-class objects in the config, adds shadow presets, and improves fluid typography range control with global min/max settings. All themes targeting WordPress 6.6+ should use version 3 as the schema version.

FSE in 2026 is not the experimental surface it was in 5.9. The posttypes meta system gives you fine-grained template assignment for any CPT. Pattern Overrides give your patterns the design flexibility they needed. The Connectors API alpha is the preview of how data-driven templates will work in 7.0. Build your block themes against version 3 of theme.json, implement Block Bindings for your dynamic attributes, and test the Connectors API alpha against the Gutenberg plugin. By the time 7.0 ships, your theme will already be compatible.

If you are comparing block themes versus staying on classic PHP templates, the WordPress Block Theme vs Classic Developer Guide covers the architectural tradeoffs and migration decisions in depth. For the full picture of what WordPress 7.0 will add on top of today’s FSE foundation, including the Connectors API stable release and collaborative editing in the Site Editor, see the WordPress 7.0 complete roadmap guide.