Temas clássicos vs block themes (fse): O que escolher em 2026

Durante mais de uma década (2010-2020), o desenvolvimento de temas WordPress foi sempre igual: criava header.php, footer.php, um loop no index.php e estilos no style.css. A lógica vivia em PHP, a aparência em CSS, e os dois mundos raramente se cruzavam.

Com o WordPress 5.9 chegou o Full Site Editing (FSE), hoje chamado simplesmente editor do site (Site Editor), e em 2026 a pergunta é mais incisiva do que nunca: deve continuar a escrever temas em PHP ou passar por completo para blocos, templates HTML e theme.json? O que já chega no plugin Gutenberg, incluindo React 19 por omissão, está em Gutenberg 24.2: notas de margem e React 19.

Este guia explica o que são de facto os temas de blocos, em que diferem dos temas clássicos ao nível do código, quando ganha cada um e como planear uma migração entre eles. Cobre os modelos clássico, de blocos e híbrido.

Resposta curta: escolha um tema de blocos quando quiser gerir o site a partir do editor, reunir os design tokens num só ficheiro e alinhar-se com a direção em que o núcleo do WordPress está a ser desenvolvido. Mantenha um tema clássico quando o projeto ainda depende de templates PHP próprios, de controlo rigoroso do layout ou de um fluxo de trabalho assente em page builders. O modelo híbrido fica entre os dois e é aí que acaba uma boa parte dos projetos profissionais.

#O que é um tema de blocos no WordPress

Um tema de blocos é um tema WordPress construído inteiramente com blocos: os templates são ficheiros HTML com marcação de blocos em vez de ficheiros PHP, os design tokens vivem num único ficheiro theme.json, e cada parte do site (cabeçalho, rodapé, arquivos, 404) edita-se visualmente no editor do site. Full Site Editing é o nome genérico deste sistema, e convém definir as suas peças antes de comparar, porque vários subsistemas distintos foram introduzidos ao mesmo tempo.

O editor do site (Aparência > Editor) é uma interface visual para editar todas as partes de um site: templates, partes de template, estilos, padrões e navegação. Num tema clássico só editava o conteúdo de artigos e páginas no editor de blocos. Num tema de blocos, a mesma ecrã de blocos edita agora o cabeçalho, o rodapé, o template de artigo individual, o arquivo, o 404 e os resultados de pesquisa.

theme.json é um único ficheiro de configuração na raiz do tema que declara os design tokens e as definições do editor. Define a paleta de cores, a escala tipográfica, a escala de espaçamento, as larguras de layout e quais os controlos que aparecem no editor. O WordPress lê-o e gera variáveis CSS (custom properties) para o front end e para o editor, de modo que a vista de edição coincide com a página publicada.

Templates de blocos e partes de template são ficheiros HTML dentro de templates/ e parts/. Em vez de single.php entrega templates/single.html, e em vez de um rodapé fixo em footer.php entrega parts/footer.html. Estes ficheiros contêm marcação de blocos (comentários HTML como <!-- wp:post-title /-->), não PHP.

Estilos globais são a camada visível para o utilizador por cima do theme.json. Os proprietários do site podem ajustar cores, fontes e espaçamento a partir do painel Estilos sem tocar em código, e os temas podem incluir variações de estilo como ficheiros JSON adicionais numa pasta styles/.

Padrões de blocos são composições de blocos reutilizáveis e já desenhadas. Substituíram boa parte do que os page builders ofereciam: um hero, uma secção de preços, um apelo à ação, tudo editável como blocos nativos e registado a partir de uma pasta patterns/.

Perceber estas cinco peças é a maior parte do trabalho. Um tema de blocos é, no essencial, theme.json mais templates HTML mais padrões, editado através do editor do site.

#Ficheiros obrigatórios do tema clássico: style.css e index.php

Um tema clássico precisa de exatamente dois ficheiros para que o WordPress o liste e o deixe ativar: style.css, cujo comentário de cabeçalho contém o nome do tema e os restantes metadados, e index.php como template de último recurso. Tudo o resto que costuma ver, header.php, footer.php, functions.php, single.php, page.php, é opcional em sentido estrito e só se torna necessário quando quer que a hierarquia de templates se ramifique. Um tema de blocos troca o segundo ficheiro: style.css continua a ter o comentário de cabeçalho, mas o template de recurso é templates/index.html em vez de index.php. theme.json também não é formalmente obrigatório, embora um tema de blocos sem ele herde os valores por defeito do núcleo para cores, espaçamento e tipografia, o que quase nunca é o que pretende. Um tema filho acrescenta uma regra: a linha Template: no cabeçalho do seu style.css tem de indicar a pasta do tema pai.

#1. Ficheiros de template num tema clássico e num tema de blocos

Esta é a diferença mais fundamental, e a que inquieta muitos programadores com anos de experiência.

#Tema clássico

Baseado em ficheiros PHP. Quando o WordPress carrega uma página, percorre a hierarquia de templates (por exemplo single-product.php, depois single.php, depois index.php) e o motor PHP monta o cabeçalho, o loop e o rodapé no momento do pedido.

• Estrutura: header.php, page.php, single.php, archive.php, sidebar.php, functions.php.
• Lógica: pode misturar livremente PHP com HTML, por exemplo if ( is_user_logged_in() ) ou um loop WP_Query totalmente personalizado.
• Vantagem: controlo total sobre a marcação e facilidade em injetar lógica de negócio, chamadas a APIs externas ou vistas condicionais.
• Desvantagem: o proprietário do site não consegue mexer no cabeçalho, no rodapé ou no layout sem editar código ou pedir a um programador.

#Tema de blocos

Baseado em ficheiros de template HTML com marcação de blocos. Não há PHP nos próprios ficheiros de template.

• Estrutura: templates/index.html, templates/single.html, parts/header.html, parts/footer.html, theme.json.
• Lógica: nenhuma no ficheiro de template. Os templates são marcação de blocos estática, e toda a saída dinâmica vem de blocos como <!-- wp:post-title /-->, o bloco Query Loop ou o bloco Conteúdo do artigo.
• Vantagem: o proprietário pode editar o site inteiro, incluindo cabeçalho e rodapé, numa única vista visual.
• Desvantagem: a lógica personalizada do lado do servidor tem de passar para um bloco próprio, uma variação de bloco, a Block Bindings API ou um shortcode, em vez de ficar diretamente no template.

A mudança de mentalidade é que a lógica de apresentação sai do ficheiro de template. Onde um tema clássico coloca uma condição diretamente em single.php, um tema de blocos exprime a mesma intenção através do contexto do bloco, de block bindings ou de um bloco criado para o efeito e registado num plugin ou no functions.php do tema.

#2. O que o theme.json substitui no functions.php

Na era clássica, o functions.php era o sítio para tudo: registar menus, sidebars, tamanhos de imagem, carregar folhas de estilo e scripts e definir flags de add_theme_support(). As decisões de design ficavam espalhadas entre PHP e um ou mais ficheiros CSS.

Na era dos blocos, o theme.json centraliza a configuração. Controla:

1. Paleta de cores: as cores com nome oferecidas aos editores, emitidas como variáveis CSS.
2. Tipografia: tamanhos de letra, famílias tipográficas, altura de linha e tipografia fluida.
3. Espaçamento: uma escala de espaçamento e o espaço entre blocos (block gap), usados de forma consistente.
4. Layout: largura de conteúdo e largura ampla (contentSize, wideSize), que determinam o alinhamento.
5. Controlos e disponibilidade: appearanceTools, definições por bloco e a possibilidade de desativar controlos em que os editores não devem mexer.

Exemplo de theme.json em 2026:

{
  "version": 3,
  "settings": {
    "appearanceTools": true,
    "layout": { "contentSize": "720px", "wideSize": "1200px" },
    "color": {
      "palette": [
        { "slug": "primary", "color": "#0055FF", "name": "Azul da marca" }
      ]
    },
    "typography": {
      "fluid": true,
      "fontSizes": [
        { "slug": "small", "size": "14px", "name": "Pequeno" }
      ]
    }
  }
}

Em vez de manter centenas de linhas de CSS mais registo em PHP, declara os tokens uma única vez em JSON. Como organizar esses tokens num sistema de design partilhado entre projetos está explicado no guia sobre sistemas de design escaláveis com Gutenberg. O WordPress gera CSS otimizado e variáveis CSS para o front end e para o editor, e é por isso que a pré-visualização no editor finalmente coincide com o resultado publicado. O functions.php continua a existir num tema de blocos, mas fica pequeno: carregar uma fonte, registar uma categoria de padrões, adicionar flags de suporte do editor e pouco mais.

#3. Como funcionam os estilos globais e as variações de estilo

O theme.json define os valores por defeito; os estilos globais permitem ao proprietário do site sobrepô-los sem código. A partir do painel Estilos, um editor pode mudar a fonte do texto, ajustar a paleta ou alterar o espaçamento, e essas escolhas ficam guardadas por site.

Os temas também podem incluir variações de estilo: ficheiros JSON adicionais numa pasta styles/ que apresentam o site inteiro com outro aspeto, por exemplo uma variação escura ou uma de alto contraste, selecionáveis com um clique. É uma capacidade que os temas clássicos nunca tiveram de forma nativa, e um dos argumentos mais fortes a favor dos temas de blocos em projetos com marca flexível.

O reverso é a governação. Dar acesso total aos estilos globais a um editor sem formação pode resultar em tipografia inconsistente ou contraste partido. Os temas de blocos respondem com bloqueio de blocos (block locking) e com a desativação de controlos concretos no theme.json, mas o programador tem de definir essas barreiras de forma deliberada.

#4. O que acontece aos widgets e menus num tema de blocos

Nos temas de blocos não há, por defeito, ecrã de Widgets nem o ecrã clássico de Menus em Aparência.

• Em vez de widgets, tem partes de template (template parts). O rodapé é uma parte de template HTML que edita na mesma ecrã de blocos que qualquer artigo.
• Em vez do editor de menus clássico, tem o bloco de Navegação, editado diretamente no cabeçalho, com o menu guardado como uma entidade reutilizável do tipo wp_navigation.

Para clientes habituados ao WordPress antigo, isto é um verdadeiro choque cultural. Os itens familiares “Widgets” e “Menus” desaparecem, substituídos por blocos. Alguns plugins que registavam widgets passaram a fornecer blocos, e uns poucos mais antigos expõem o seu widget apenas através do bloco Widget antigo, como ponte de compatibilidade. Auditar a compatibilidade dos plugins é, por isso, um passo real antes de comprometer um cliente com um tema de blocos.

#5. Comparação de funcionalidades entre tema de blocos e tema clássico

A tabela resume onde os dois modelos divergem no trabalho do dia a dia.

Leia a tabela como apoio à decisão, não como um placar. Nenhuma coluna é sempre melhor; a escolha certa depende de quem edita o site e de quanta lógica de servidor própria os templates transportam.

#6. Os temas de blocos são mais rápidos do que os clássicos

Durante anos a resposta foi um sim claro, e desde o WordPress 6.9 a diferença é muito menor.

1. Estilos dos blocos do núcleo: os temas de blocos carregam o CSS dos blocos do núcleo em separado e apenas para os blocos que são renderizados, porque _add_default_theme_supports() ativa should_load_separate_core_block_assets e should_load_block_assets_on_demand. Os temas clássicos recebiam antes a folha agrupada wp-block-library em todas as páginas. Desde a 6.9, wp_load_classic_theme_block_styles_on_demand() ativa esses mesmos dois filtros para os temas clássicos e acrescenta um buffer de saída que sobe para o head os estilos impressos tarde. O buffer tem um custo: impede o streaming da resposta, por isso o tempo até ao primeiro byte pode subir ligeiramente. Um tema que precise de streaming pode desligá-lo com o filtro wp_should_output_buffer_template_for_enhancement.
2. Design tokens em vez de folhas de estilo: o theme.json emite variáveis CSS em vez de uma cascata pesada. Um tema clássico obtém os mesmos tokens assim que passa a ter um ficheiro theme.json.
3. A folha de estilo do próprio tema: aqui continua a haver uma diferença real. Um tema clássico traz muitas vezes um style.css grande com todos os componentes, enquanto um tema de blocos mantém a maior parte do estilo no theme.json e em estilos por bloco.
4. Marcação mais limpa, com uma ressalva: a saída do FSE costuma ser arrumada, mas blocos de layout aninhados podem gerar div envolventes a mais (“div-itis”) se os padrões forem construídos sem cuidado.

Um tema não tem pontuação no Lighthouse; uma página tem. Num site real, o resultado depende muito mais do banner de consentimento, dos mapas e formulários incorporados, dos ficheiros de fontes e do tamanho das imagens do que do tipo de tema. Meça as suas próprias páginas; o guia de Core Web Vitals explica como.

A experiência de desenvolvimento é mais matizada e depende da equipa. O desenvolvimento de temas de blocos assenta em configuração JSON, marcação de blocos e JavaScript para blocos próprios (block.json, register_block_type, a cadeia de ferramentas @wordpress/scripts). Equipas com raízes profundas em PHP, mas pouca experiência com React ou ferramentas de blocos, enfrentam uma curva de aprendizagem real. O desenvolvimento clássico é imediatamente familiar a qualquer programador PHP, mas não dá ao cliente edição visual nem um sistema de design tokens sem trabalho extra. Na prática, o caminho mais rápido para uma equipa forte em PHP é o tema híbrido: primeiro theme.json e padrões, depois blocos próprios de forma gradual.

#7. Migrar de um tema clássico para um tema de blocos

A migração raramente é um único interruptor. O conteúdo da base de dados (artigos, páginas, multimédia) não é afetado, mas a camada de apresentação tem de ser reconstruída.

Considerações práticas:

• Templates: cada template PHP precisa de um template de blocos equivalente. Templates condicionais complexos podem ter de ser divididos em padrões mais block bindings.
• Menus: os menus existentes não são convertidos automaticamente; reconstrói-os como blocos de Navegação, embora os itens do menu costumem recriar-se depressa.
• Widgets: as áreas de widgets não existem num tema de blocos, por isso os widgets da sidebar e do rodapé passam a ser partes de template ou blocos.
• Definições do Personalizador: as opções definidas no Personalizador (logótipo, cores, CSS personalizado) passam para o theme.json e para os estilos globais. O CSS personalizado pode ser mantido no campo de CSS adicional dos estilos globais durante a transição.
• Saída dos plugins: confirme que cada plugin ativo fornece blocos ou shortcodes em vez de depender de widgets ou de hooks de template que um tema de blocos já não dispara da mesma forma.

Um caminho seguro é incremental: primeiro converta o tema clássico num tema híbrido, acrescentando theme.json e suporte para padrões de blocos, valide os design tokens e a experiência de edição, e depois substitua os templates PHP por templates de blocos, um de cada vez. Assim evita uma reescrita arriscada de uma só vez e pode testar cada template com conteúdo real e com os Core Web Vitals antes de avançar.

Atualização de 27 de outubro de 2026. Numa loja WooCommerce, a saída dos plugins pede um teste próprio. Muitos plugins para WooCommerce imprimem botões e etiquetas a partir dos hooks do loop clássico da loja. Num tema de blocos, uma grelha de produtos é o bloco Product Collection e, quando esse bloco não segue a consulta da loja, como uma grelha de produtos na página inicial, esses hooks não correm ali. A saída do plugin desaparece sem qualquer aviso, e a folha de estilos do plugin pode nem sequer carregar nessa página. Antes de passar a sua loja para um tema de blocos, coloque um Product Collection na página inicial, abra a página da loja feita com blocos e verifique cada plugin nas duas: a saída está lá e a folha de estilos carrega nessa página? Os nossos plugins funcionam nos dois sítios: as etiquetas do Marks, o botão de comparação do Versus e o botão de compra rápida do Swift aparecem nas grelhas Product Collection e na página da loja feita com blocos.

#8. Quando manter um tema clássico

Um tema clássico continua a ser a escolha certa quando:

• O projeto transporta muita lógica PHP própria nas vistas, como condições de apresentação avançadas, loops personalizados ou substituições profundas de templates do WooCommerce.
• O cliente não se sente à vontade com a edição completa e é preciso evitar alterações acidentais ao layout do cabeçalho ou do rodapé.
• O site depende de um page builder como o Elementor ou o Divi, que ainda pressupõem uma estrutura clássica e em grande parte contornam o FSE.
• Mantém um site maduro em que o custo da migração supera claramente o benefício.
• A equipa é sobretudo de PHP e tem pouca margem para investir agora em ferramentas de blocos.

#9. Quando usar um tema de blocos

Um tema de blocos é a escolha mais forte quando:

• O site é orientado para conteúdo: um site institucional, um blog, uma publicação ou um portefólio.
• O proprietário quer editar cabeçalhos, rodapés e templates sem um programador a cada alteração.
• Quer design tokens e estilos por bloco por defeito, em vez de uma folha de estilo grande do tema.
• A flexibilidade da marca importa e as variações de estilo trazem valor real.
• Quer alinhar-se com a direção do núcleo do WordPress, que concentra agora o desenvolvimento na experiência de blocos e no FSE.

#10. Tema de blocos ou clássico para WooCommerce, blogs e LMS

• Pequena empresa ou site institucional: tema de blocos. Os editores ganham controlo seguro sobre todo o layout.
• Blog ou publicação: tema de blocos. O bloco Query Loop, os padrões e a marcação limpa encaixam bem em fluxos editoriais.
• Portefólio ou site de apresentação: tema de blocos, muitas vezes com algumas variações de estilo para aspetos sazonais.
• Loja WooCommerce: depende. O carrinho e o checkout modernos baseados em blocos encaixam num tema de blocos, mas lojas com muitos templates de produto próprios em PHP podem ficar no clássico ou no híbrido.
• Área de membros, LMS ou aplicação complexa: clássico ou híbrido. A lógica de vista pesada e as integrações externas controlam-se mais facilmente em templates PHP.
• Site gerido por page builder: clássico. O builder já controla o layout, por isso o FSE acrescenta pouco.

#O que é um tema híbrido no WordPress

O modelo híbrido é o meio-termo pragmático. É um tema PHP clássico que acrescenta theme.json (para a paleta de cores, a tipografia e os tokens de espaçamento no editor) e suporte para padrões de blocos, mantendo templates PHP selecionados como header.php ou single.php para controlo estrutural. Muitos projetos profissionais em 2026 são entregues exatamente assim: edição por blocos onde ajuda, PHP onde importa.

#Que funcionalidades do editor do site funcionam com temas clássicos, por versão do WordPress

A fronteira entre os dois tipos de tema mudou em quase todas as versões. O Theme Handbook descreve os temas híbridos como “temas clássicos que adotaram algumas funcionalidades modernas relacionadas com blocos” e nota que híbrido não é um tipo de tema oficial (What is a theme, tradução própria). A tabela mostra o que chegou aos temas clássicos e quando, com datas do arquivo de versões do WordPress.

No núcleo atual, wp-admin/menu.php dá a um tema clássico a entrada completa Design no editor do site quando o tema inclui theme.json ou declara suporte para editor-styles, e apenas a entrada Padrões caso contrário. Um tema de blocos recebe a entrada Editor. Por isso, em 2026 a pergunta prática raramente é “clássico ou de blocos” em abstrato. É que funcionalidades um projeto adota, por que ordem, e se vale a pena dar o último passo, acrescentar templates/index.html.

#Tema de blocos ou tema clássico no WordPress: qual escolher em 2026

A decisão depende de três fatores: complexidade do projeto, competências técnicas do cliente e requisitos de manutenção a longo prazo.

Escolha um tema de blocos quando:

• O cliente precisa de editar cabeçalhos, rodapés e templates sem ajuda do programador
• Os editores devem alterar templates e estilos globais sem uma implementação
• Quer usar theme.json para design tokens (cores, tipografia, espaçamento) em vez de CSS disperso
• O projeto é novo e não tem código antigo para manter

Escolha um tema clássico quando:

• Precisa de lógica PHP complexa nos templates (loops personalizados, layouts condicionais, substituições do WooCommerce)
• O projeto depende de widgets, menus clássicos ou do Personalizador
• A equipa tem muita experiência em PHP, mas pouca em desenvolvimento de blocos Gutenberg
• Mantém um site existente e o custo da migração supera o benefício

A abordagem híbrida: muitos projetos WordPress profissionais em 2026 usam um tema clássico com suporte seletivo de blocos. Registe padrões e templates de blocos onde acrescentam valor e mantenha templates PHP onde dão mais controlo. O WordPress não obriga a uma escolha de tudo ou nada.

O WordPress 7.0 saiu a 20 de maio de 2026 e o 7.1 a 19 de agosto de 2026; a versão atual é a 7.1.3, de 6 de outubro de 2026. A Abilities API chegou antes, na 6.9, e funciona da mesma forma com os dois tipos de tema, por isso não é um argumento a favor de nenhuma das arquiteturas.

#Resumo

O mundo WordPress dividiu-se em dois campos. Não lute contra isso. Aprenda a sintaxe do theme.json, é uma competência tão importante em 2026 como saber CSS era em 2015.

Escolher entre tema clássico e tema de blocos define quem vai poder editar o site sem abrir o código, e isso raramente se decide bem à pressa. Ajudamos nessa decisão e depois na implementação, em construção de temas de blocos em WordPress.