Tema de Blocos vs Tema Clássico no WordPress: a Comparação Honesta

Abra a pasta do seu tema. Se houver uma pasta templates com um index.html dentro, mais um theme.json na raiz, você tem um tema de blocos. Se houver index.php ao lado de arquivos como header.php e footer.php, e o menu lateral do painel mostrar Aparência e depois Personalizar, você tem um tema clássico.

Essa única diferença de estrutura define quem pode mudar o quê no seu site, onde essas mudanças ficam guardadas e qual metade do ecossistema de plugins do WordPress vai se comportar normalmente.

A identificação em 30 segundos

Sinal	Tema clássico	Tema de blocos
Arquivo de template raiz	index.php	templates/index.html
Cabeçalho e rodapé	header.php, footer.php	parts/header.html, parts/footer.html
Configuração global	functions.php	theme.json (mais functions.php opcional)
Menu do painel	Aparência > Personalizar	Aparência > Editor
Onde as edições são salvas	Arquivos em disco	Banco de dados, como posts wp_template
Tela de Widgets	Existe	Não existe

O WordPress decide procurando por templates/index.html. Um tema que entrega um theme.json mas mantém seus templates PHP continua sendo tratado como clássico — esse meio-termo é comum e tem nome, explicado mais adiante.

Se você tem acesso ao shell, um comando resolve:

wp eval 'var_dump( wp_is_block_theme() );'

WP-CLI é a verificação mais rápida em um site que não foi você quem construiu, principalmente quando um construtor de páginas escondeu os menus habituais do painel.

O que muda para quem edita o site

Em um tema clássico, o cabeçalho, o rodapé, a barra lateral, as cores e a logo ficam atrás do Personalizar, e você só tem os controles que o autor do tema decidiu construir. Se o tema não registrou um controle para o texto de copyright do rodapé, não existe controle. Você edita um arquivo PHP ou aceita como está.

Em um tema de blocos, o Editor do Site expõe a página inteira. Cabeçalho, rodapé, o loop, a página 404, o layout dos resultados de busca — tudo é bloco, tudo é editável por alguém que nunca viu PHP na vida. Esse é o grande recurso da história, e ele é realmente grande.

O custo é que tudo é editável por alguém que nunca viu PHP na vida. Um cliente pode apagar o título do site do cabeçalho às duas da manhã e não existe histórico de versões em disco para restaurar — só as revisões do próprio Editor do Site. Dá para travar as coisas com o bloqueio de blocos e restringindo quem chega ao editor, mas é um trabalho opcional que você precisa lembrar de fazer.

Duas perdas menores que incomodam na prática: temas de blocos não têm tela de Widgets (as áreas de widgets viram partes de template e blocos), e os menus clássicos são substituídos pelo bloco de Navegação, que guarda os itens como um tipo de conteúdo separado em vez de deixá-los na tela de Menus que todo mundo conhece.

O que muda para quem programa

Temas clássicos usam a hierarquia de templates PHP. O WordPress resolve uma requisição descendo uma cadeia conhecida — single-{post-type}.php, depois single.php, depois singular.php, depois index.php — e o seu arquivo roda, chama get_header(), executa o Loop e imprime a marcação que você controla caractere por caractere.

<?php get_header(); ?>
<main class="site-main">
  <?php while ( have_posts() ) : the_post(); ?>
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
  <?php endwhile; ?>
</main>
<?php get_footer(); ?>

Temas de blocos usam os mesmos nomes da hierarquia com extensão .html, mas o arquivo contém marcação de blocos — HTML com delimitadores de bloco em comentários — e não existem template tags:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

Três consequências que quem programa sente na hora:

get_header() e get_footer() nunca rodam. Qualquer coisa pendurada nessas actions, em um plugin ou em um tema filho antigo, simplesmente não faz nada. wp_head e wp_footer continuam disparando, então a maior parte do enfileiramento de scripts sobrevive, mas hooks específicos de cabeçalho não.

O banco de dados vence os seus arquivos. No instante em que alguém salva um template no Editor do Site, o WordPress guarda aquela versão como um post wp_template e passa a servi-la no lugar do seu arquivo. Você pode editar o arquivo HTML a tarde inteira e não ver mudança nenhuma no site. Limpar a personalização daquele template devolve a versão do arquivo. Esse é de longe o relato mais comum de “meu tema de blocos quebrou”, e não é bug.

A estilização vai para o theme.json. Cores, escala de espaçamento, tipografia e padrões por bloco são declarados como dados em vez de CSS, e o WordPress gera o CSS. É mais limpo e muito mais consistente — até você precisar de algo que o schema não expressa, e então você acaba escrevendo CSS mesmo e brigando com a especificidade das regras geradas.

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
      ]
    }
  }
}

Confira o valor de version contra a versão do WordPress que você usa — o schema já foi revisado mais de uma vez, e copiar um número de versão de um tutorial antigo produz configurações que são silenciosamente ignoradas.

Vale notar que o functions.php não some. Temas de blocos ainda o usam para enfileirar arquivos, registrar entradas de add_image_size, criar tipos de post personalizados e qualquer outra coisa em PHP. Você só faz muito menos templating ali.

O que você ganha de verdade, e o que perde de verdade

Ir para blocos te dá: controle editorial sobre a página inteira, consistência de design garantida pelo theme.json, menos arquivos para manter e estilos que batem entre o editor e o site com muito mais frequência do que os temas clássicos jamais conseguiram.

Ir para blocos te tira: controle direto da marcação de saída, personalização simples via hooks, compatibilidade com tudo que pressupõe templates PHP e a tranquilidade de ter a aparência do site versionada.

Essa última merece destaque. Em um tema clássico, o git log te conta o que mudou. Em um tema de blocos, uma parte relevante da aparência do site mora no banco de dados, onde sua esteira de deploy nem olha.

Quando o tema clássico ainda é a resposta certa

• Um construtor de páginas comanda o site. Elementor, Divi, Beaver Builder e similares assumem o templating por conta própria. Colocar um tema de blocos por baixo adiciona um segundo sistema de templates que não faz nada.
• A marcação precisa ser exata. Bibliotecas de componentes sob medida, marcação com acessibilidade rigorosa, requisitos incomuns de schema — a saída dos blocos é limitada pelo que os blocos emitem, e brigar com isso custa mais do que escrever PHP.
• Muito templating vindo de plugins. Plugins de área de membros, LMS, diretórios e extensões de comércio mais antigas costumam entregar sobrescritas de template em PHP. Muitos já têm equivalente em blocos; muitos não têm.
• O site está pronto e funcionando. Um tema com cinco anos de personalizações acumuladas não tem caminho de atualização para blocos, só reconstrução. “É a abordagem mais nova” não é motivo de negócio.
• Ninguém além de você vai editar. O benefício principal do Editor do Site é entregar controle a quem não programa. Se não existe ninguém assim no projeto, você está pagando o custo de um benefício que ninguém usa.

O meio-termo híbrido

Um tema clássico pode adicionar um theme.json e ganhar o sistema de estilos globais, as predefinições de cor e espaçamento e a estilização consistente no editor — mantendo seus templates PHP e o Personalizar. O WordPress não chama isso de tema de blocos, e o Editor do Site continua indisponível, mas você fica com a maior parte do benefício de design system por uma fração do trabalho.

Para um site existente que funciona bem, esse costuma ser o primeiro passo certo. Adicione o theme.json, defina sua paleta e seu espaçamento, apague o CSS que ele substitui e veja se você ainda quer o resto.