Skip to content
WordPress7 min read

Modern Block Theme Development with Full Site Editing

Block themes replace PHP templates with HTML, patterns and theme.json. What changes in practice, and how to build one that editors and developers both trust.

Full Site Editing is the biggest change to WordPress theming since themes existed: headers, footers and templates become editable block structures rather than PHP files, and the design system moves into configuration. The early versions were rough, and plenty of developers wrote the whole direction off. Recent releases have matured into something we now use for production client work, but building a good block theme means unlearning some classic-theme instincts.

The anatomy of a block theme

A block theme swaps the classic hierarchy of PHP files for a templates directory of HTML files containing block markup, a parts directory for reusable regions like the header, and theme.json describing settings and styles. There is still a functions.php for enqueueing assets and registering blocks and patterns, but presentation lives in block markup and configuration. The template hierarchy still applies, so single.html and archive.html resolve exactly as their PHP ancestors did, which makes the mental transition smaller than it first appears. The template files themselves are plain HTML built from block comment markup, so diffs stay readable and code review works exactly as before.

theme.json is where the design system lives

The single biggest shift is that colour palettes, type scales, spacing and layout widths are declared once, in theme.json, and flow everywhere: the editor UI, generated CSS custom properties, and every block's settings panel. Restricting options here is a feature, because every choice you remove is a way the design cannot be broken.

json
{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "ink", "color": "#101828", "name": "Ink" },
        { "slug": "sand", "color": "#f5f1ea", "name": "Sand" }
      ],
      "custom": false
    },
    "typography": { "fluid": true },
    "layout": { "contentSize": "42rem", "wideSize": "72rem" }
  }
}

Setting custom to false removes the freeform colour picker, so editors choose from the palette or nothing. Fluid typography, content widths and spacing presets follow the same pattern: declare the system, disable the escape hatches, and consistency stops depending on discipline.

Style variations extend the same idea: alternative theme.json files in a styles directory show up in the site editor as one-click looks, swapping palette and typography without touching a template. One well-built theme can ship several sanctioned appearances this way, which for agency work quietly replaces a whole category of near-duplicate themes.

Patterns are the real editorial interface

Editors do not want to assemble a pricing section from twelve raw blocks; they want to insert one designed by you and change the words. Patterns are how a block theme delivers that: pre-composed block arrangements registered by the theme, from a hero to a full page layout. In our builds, patterns carry most of the design value, and we lock down the structural parts with templateLock and locked attributes so the shape survives editing while the content stays free. Well-designed patterns are the difference between a block theme that feels like a design system and one that feels like a blank canvas nobody asked for. Patterns double as documentation, too: a new editor opening the inserter sees the site's entire visual vocabulary, named and previewed, which shortens onboarding more than any wiki page we have written.

What still belongs to developers

PHP has not gone anywhere for logic: custom blocks, REST integration, query modifications and performance work are unchanged. Version control needs one deliberate habit, because the site editor lets users edit templates in the database, and those edits override your files. Decide per project whether that is a feature for the client or a drift risk to disable, and use the Create Block Theme plugin during development to pull editor-made changes back into files, keeping the repository the source of truth. Semantics and accessibility remain human work as well; blocks compose the page, but heading order, landmark structure and alt text discipline still need someone who cares.

Block themes reward teams who think in systems rather than pages. Approached that way, Full Site Editing is not a compromise; it is the first time WordPress theming and design systems have genuinely pointed in the same direction.

Start your project

Have an idea? Let's ship it together.

Tell us what you're building — we'll reply within one business day with an honest take and a clear next step.