← Back to Blog

Classic Themes vs Block Themes

WordPress supports two principal theme architectures: classic themes and block themes.

Veyra Admin

5 min read

  • Guide
  • Beginner
  • 6 minutes read
  • Reviewed August 5, 2026
  • WordPress themes and templates

WordPress supports two principal theme architectures: classic themes and block themes.

Both can produce professional websites, but they organize templates, styles and customization differently. Choosing between them affects the files developers work with and the tools site administrators use to edit the website.

Classic Themes

Classic themes are the original WordPress theme model. They primarily use PHP template files, CSS, JavaScript and WordPress template functions.

Common files include:

  • index.php as the final template fallback.
  • single.php for individual posts.
  • page.php for pages.
  • archive.php for archives.
  • header.php and footer.php for repeated regions.
  • functions.php for setup and theme-specific code.
  • style.css for theme metadata and styles.

Classic themes often expose design settings through the Customizer, widget areas, menu screens or proprietary options panels.

They remain fully supported and are widely used, especially on established websites and projects with mature PHP template systems.

Block Themes

Block themes use blocks for the full site structure, not only for post content.

Their templates are primarily HTML files containing block markup. Repeated regions are represented by block template parts, while theme.json defines settings and styles. Authorized users can edit these elements through the Site Editor.

A block theme commonly contains:

  • A templates directory.
  • A parts directory.
  • theme.json.
  • style.css.
  • Optional patterns, styles, PHP and assets.

Block themes make headers, footers, archives and other template-level layouts editable with the same block system used for content.

The Main Difference Is the Editing Model

The difference is not simply that one theme is old and the other is new.

Classic themes usually place more layout authority in theme files and developer-defined controls. Block themes expose more of the site structure through the Site Editor.

That can make block themes faster for visual iteration, but it also requires governance. A team may need roles, review processes and design restrictions to prevent accidental changes to global templates.

Classic themes can offer tighter file-based control, but a poorly designed classic theme may depend on proprietary panels or page builders just as heavily as any other system.

Hybrid Themes

Some classic themes adopt selected block features such as theme.json, block template parts, appearance tools or the Template Editor.

These are commonly called hybrid themes. The term is useful descriptively, but WordPress still treats them as classic themes technically.

Hybrid approaches can provide a gradual migration path. They can also produce confusing interfaces when users are unsure whether a setting belongs in the Customizer, Site Editor, post editor or a theme options page.

Feature Comparison

Templates

Classic themes use PHP templates. Block themes use block HTML templates, with PHP still available for supporting code.

Global design

Classic themes generally rely on CSS, the Customizer and theme options. Block themes use Global Styles and theme.json as central design systems.

Site editing

The full Site Editor requires a block theme. A classic theme may enable the narrower Template Editor or selected block features.

Portability

Both types can be portable when they follow WordPress standards. Portability problems usually come from proprietary blocks, shortcodes, bundled content models or theme-specific data.

Development workflow

Classic themes fit established PHP workflows. Block themes allow more layout work in HTML block markup and JSON configuration, while still benefiting from version control and build tools.

Which Type Should You Choose?

Choose based on the project, not on novelty.

A block theme is a strong option when:

  • Editors need controlled access to templates and styles.
  • The design can be represented effectively with blocks.
  • The team wants native full-site editing.
  • The project is starting without legacy theme dependencies.

A classic or hybrid theme may be appropriate when:

  • The project already has a reliable custom PHP theme.
  • Complex server-rendered templates are central to the design.
  • Existing plugins or workflows depend on classic interfaces.
  • The team needs a gradual transition rather than a rebuild.

Frequently Asked Questions

Are classic themes deprecated?

No. Classic themes remain supported. WordPress continues to provide classic theme APIs and compatibility.

Can a classic theme use theme.json?

Yes. theme.json works with classic themes as well as block themes, although the full editing experience differs.

Is a block theme automatically faster?

No. Performance depends on implementation, assets, plugins, hosting and content. Theme architecture alone does not guarantee speed.

Applying Classic Themes vs Block Themes in a Real WordPress Project

Separate content, presentation and permanent functionality. Test the editing workflow as well as the public output, because a theme decision affects templates, design controls, accessibility, performance and future redesign work.

A connected concept is The Customizer, Widgets and Legacy Theme Features. Reading the two together helps separate the immediate task from the wider WordPress responsibility.

A useful implementation begins by writing down the current state, the intended outcome and the evidence that will prove the change worked. This prevents a configuration screen, plugin recommendation or code snippet from becoming the entire strategy.

Decision Matrix

| Question | Classic Themes | Block Themes | |—|—|—| | Primary responsibility | Identify what this option owns | Identify what this option owns | | Data and portability | Review what remains if the option changes | Review what remains if the option changes | | Editing workflow | Test the interface with real users | Test the interface with real users | | Maintenance | Check updates, compatibility and support | Check updates, compatibility and support | | Exit path | Define migration or replacement steps | Define migration or replacement steps |

How to Make the Decision

Do not choose from a demo or feature list alone. Build a short requirements list, test the highest-risk workflow and compare the complete operating cost. The correct choice is the one the team can maintain while preserving the required data and user experience.

Review Editor and Frontend Behaviour

A block feature has at least two user experiences: the editor used to create it and the frontend used to consume it. Dynamic data, responsive behaviour and accessibility can differ between the two.

Test insertion, selection, keyboard operation, saved markup, server rendering, theme styles and backward compatibility with previously saved content.

Official Reference Context

The Block Editor Handbook is the primary version-specific reference for this topic. Use the current documentation to verify interface labels, supported APIs and behaviour before applying instructions to a production site.

How to Verify the Result

  • Test representative templates on mobile and desktop.
  • Check keyboard navigation, headings, contrast and focus.
  • Switch editing contexts and confirm that the team knows where each design decision is stored.

Sources and Further Reading

Continue Learning