If you learned WordPress theming with header.php, functions.php, and the Customizer, Full Site Editing (FSE) can feel like a different platform wearing the same name. It is a genuine architectural shift, not just a new editor coat of paint. Here's what actually changed, and what it means for building and maintaining sites today.
From PHP Templates to Block Templates
Classic themes assemble pages from PHP template files (header.php, single.php, footer.php) using template tags like the_title() and the_content(). Block themes replace these with HTML files made of block markup, stored under templates/ and parts/:
<!-- templates/single.html -->
<!-- wp:template-part {"slug":"header"} /-->
<!-- wp:post-title /-->
<!-- wp:post-content /-->
<!-- wp:template-part {"slug":"footer"} /-->
Every part of the page — header, footer, post content, sidebar, comments — is a block, and every block is editable in the same Site Editor interface that previously only handled post content. There's no PHP required to build a complete theme; a style.css header and a set of HTML template files is a valid, functioning block theme.
theme.json Replaces Scattered Configuration
Before FSE, theme configuration was spread across functions.php (add_theme_support() calls), the Customizer, and inline styles. Block themes centralize this in a single theme.json file:
{
"version": 2,
"settings": {
"color": {
"palette": [
{ "slug": "primary", "color": "#1a1a1a", "name": "Primary" },
{ "slug": "accent", "color": "#0073aa", "name": "Accent" }
]
},
"typography": {
"fontSizes": [
{ "slug": "small", "size": "14px", "name": "Small" },
{ "slug": "large", "size": "24px", "name": "Large" }
]
}
},
"styles": {
"color": { "background": "var(--wp--preset--color--primary)" }
}
}
This one file controls the color palette, typography scale, spacing units, and layout constraints available in the editor — and generates the corresponding CSS custom properties automatically. It's declarative configuration instead of imperative PHP calls, which makes themes far more predictable to audit and override.
The Site Editor Is Now the Customizer's Replacement
The Customizer handled a narrow set of options — site title, a few widgets, sometimes colors — through a live-preview sidebar. The Site Editor (Appearance → Editor in a block theme) exposes the entire site: templates, template parts, global styles, navigation menus, and the style book, all editable directly and visually, with changes applied immediately rather than through a separate "publish" step buried in a panel.
This also means design decisions that used to require a developer — rearranging the header layout, changing global spacing, swapping a template for a specific post type — are now achievable by a site owner without touching code, for better and for worse depending on how much you want to lock down.
Patterns and Template Parts Change How You Reuse Markup
Classic themes reused markup through get_template_part() calls scattered through PHP. Block themes use two related concepts:
- Template parts — reusable structural pieces (header, footer, sidebar) registered as their own editable areas.
- Patterns — reusable arrangements of blocks (a call-to-action section, a pricing table) that users can insert anywhere and then customize per-instance.
register_block_pattern(
'acme-theme/cta-banner',
[
'title' => __( 'CTA Banner', 'acme-theme' ),
'categories' => [ 'call-to-action' ],
'content' => '<!-- wp:group {"backgroundColor":"accent"} -->...',
]
);
Patterns are a much more content-editor-friendly abstraction than PHP partials, since they live and are edited directly in the block editor's own vocabulary.
Global Styles Give You a Single Source of Truth
The "Styles" panel in the Site Editor lets you adjust colors, typography, and spacing site-wide, with per-block overrides layered on top — all backed by theme.json and stored, when customized, as user-generated global styles in the database. This resolves a long-standing classic-theme problem: styling logic spread across a theme stylesheet, inline styles, Customizer CSS, and page-builder-injected CSS, with no clear precedence.
Backward Compatibility: Hybrid and Classic Themes Still Work
You don't have to convert overnight. WordPress supports three theme types side by side:
- Classic themes — traditional PHP templates, no
theme.json, full backward compatibility. - Hybrid themes — classic PHP templates plus a
theme.jsonfor editor settings and global styles, without full-site block templates. - Block themes — fully block-based templates and template parts.
A hybrid theme is often the pragmatic middle ground: you keep existing PHP template logic and page-builder or ACF-based workflows, while gaining the design-token benefits of theme.json and better block-editor color/typography controls.
What This Means for Developers
- Custom template tags and complex conditional PHP logic in templates need rethinking as block markup or dynamic blocks (PHP-rendered blocks registered with
render_callback). - Client work increasingly means building custom blocks and patterns rather than page-builder-specific components — more portable, less lock-in.
- Theme.json literacy is now a core skill, similar to how
functions.phpfluency was in the classic era. - Heavy customizations that relied on filtering Customizer output or deeply hooking into
wp_headmay need block-editor-native equivalents (block filters,render_blockhooks) to stay compatible long-term.
Should You Switch?
If you're starting a new project, building on a block theme (or at minimum a hybrid theme with a solid theme.json) is the safer long-term bet — it's where core development effort is concentrated. For an existing, heavily customized classic site that works well, there's no urgency to rip it out; classic themes remain fully supported. The migration path that works best in practice is incremental: adopt theme.json for design tokens first, then move individual templates to block markup as you touch them anyway.
