Block themes move who controls layout, not just how templates are written

A writeup on dev.to poses the question most shops with a decade of `header.php` in version control keep deferring: if you are already comfortable building classic WordPress themes, is it worth moving to block themes in 2026 ^[1]. The author, whose own WordPress work has mostly been classic themes built from `header.php`, `single.php`, `archive.php` and `functions.php`, frames it as an exploration rather than a verdict ^[2][17], and the substance of the comparison lands on one axis: who gets to change the site's structure ^[11][12].

WordPress currently identifies two primary theme types, classic and block ^[3]. Per the official Theme Developer Handbook as cited in the piece, classic themes primarily use PHP, JavaScript and CSS and can make extensive use of WordPress functions, hooks and filters ^[4]. Block themes are built around block markup and HTML-based templates, and let users edit more areas of the site through the Site Editor ^[5]. The formal definition is mechanical: a block theme is one with an `index.html` template in the `templates` or `block-templates` directory, with templates built from block markup ^[6].

The two example file trees are the useful part. The classic tree lists ten files, including `functions.php`, `sidebar.php` and `404.php` ^[7]. The block tree lists seven: `style.css`, `theme.json`, three templates under `templates/`, and header and footer parts under `parts/` ^[8]. `functions.php` appears in the classic listing and not in the block one ^[9]. Inside the block `single.html` example, there is no traditional PHP Loop at all; the page is composed of a template-part reference plus post-title, post-featured-image and post-content blocks ^[10]. That is the architecture change, and no amount of describing it as a modernisation makes it a refresh.

Where the switch pays is client-side. In a classic theme the developer typically controls structure through PHP template files; with a block theme the Site Editor can edit the header, footer, navigation, templates, template parts, global styles and other block-based content ^[11]. The author's reading, and WordPress's own framing, is that the site owner gains significantly more control over structure without touching PHP, which WordPress lists among the major advantages of block themes ^[12]. For a client who keeps asking for layout changes, that is where the return shows up ^[13].

Where template PHP still wins is anything that depends on the tools the classic model exposes directly: PHP, the Loop, template files, hooks, filters, conditional tags and queries ^[15]. Classic themes are not obsolete on this account; WordPress continues to maintain documentation for classic theme development and treats them as a valid part of the platform ^[14]. The cheapest useful move for an existing codebase is also the least dramatic: `theme.json` defines global settings and styles, and it is not exclusive to block themes ^[16].

What to watch is what the source does not supply. The supplied text carries no figures on migration cost, rendering performance or plugin compatibility, and breaks off mid-sentence on `theme.json` ^[18]. Before committing, audit how much of your customisation lives in template files versus hooks and filters, because this material does not tell you how much of it survives the move ^[15][18].