Reference guide · wordpress · Published 2026-08-16 · 3 min read
Block themes vs classic themes in WordPress
Block themes vs classic themes: block themes use the Site Editor and template parts in the database, classic themes keep templates in the file system.
- ·How block themes differ
- ·Where templates live
- ·Choosing a theme type
What a block theme changes
A classic WordPress theme defines the page structure with PHP template files such as header.php, index.php and footer.php, then relies on a mix of PHP, template tags and hooks to assemble the HTML. A block theme turns that model inside out. The entire site, from the header to the footer to individual templates, is composed of blocks. Theme files become a lightweight wrapper, and most of the layout lives as block markup that you can rearrange visually in the Site Editor under Appearance > Editor.
The single most important file in a block theme is theme.json. It centralises global settings and styles, which means color, typography, spacing and layout defaults are declared in one place instead of being scattered across many CSS files and hard-coded PHP values. That makes a block theme more predictable for a developer and, importantly, much easier for a non-technical editor to control safely without breaking the layout. If you are troubleshooting why a theme looks one way rather than another, the WordPress troubleshooting order article explains the order in which to inspect theme, plugin and configuration layers.
Where the templates live
The key technical difference is storage. In a classic theme, header.php and footer.php are files, so a change means editing PHP on disk through the file manager, FTP or a child theme. In a block theme, templates and template parts are stored partly in the file system as .html files and partly in the database once an editor saves a change. A template part such as a header that you modify in the Site Editor becomes a database entry that overrides the shipped file.
That override model has consequences worth planning for:
- A saved Site Editor edit takes precedence over the theme file, so resetting a theme does not always restore the original markup if database values remain.
- Version control is cleaner while you keep edits to files, because file-based template parts are plain text you can commit.
- A staging to live deploy cannot just copy files when editorial changes live in the database; the staging to live article covers syncing that content and configuration.
Choosing between them
There is no single correct answer, but the decision usually follows who maintains the site and how the layout is expected to change.
| Consideration | Classic theme | Block theme |
|---|---|---|
| Editing model | PHP templates + Customizer | Blocks + Site Editor |
| Editor control | Limited without a page builder | Native and direct |
| Version control | Clean, all files | Mostly files, plus DB overrides |
| Performance | Depends on how it is built | theme.json gives consistent baseline |
| Learning curve | PHP + hooks | Block markup + theme.json |
Choose a classic theme when the project needs a specific established codebase, tight PHP-level customisation or compatibility with older plugins and workflows. Choose a block theme for a new site where the editor will manage the layout, a parent theme plus the child theme pattern keeps custom code safe, and you want a stable, modern baseline. If you inherit a site that mixes both, treat the override behaviour above as the likely cause of unexpected layout drift, then confirm how the theme is stored before editing it.