Edição completa do site WordPress: guia de produção 2026
Resumo
A edição completa do site WordPress consolidou-se em 2026: 68% das novas instalações usam block themes por defeito. Este folio cobre a anatomia mínima de um block theme, o editor de site do WP 6.9, os Pattern Overrides como ferramenta de entrega a clientes, o bloco Query Loop e a lista honesta do que ainda falha em produção com WordPress 6.8 e 6.9.
A edicao completa do site WordPress atingiu um ponto de inflexão em 2026. No WordPress 6.9, 68% das novas instalações utilizam por defeito a arquitetura baseada em blocos. Para freelancers e agências que ainda entregam temas PHP clássicos, a questão já não é se adoptar o Full Site Editing (FSE), mas como fazê-lo sem quebrar os fluxos de trabalho existentes. Este folio cobre a mecânica real, testada em sites de clientes com WordPress 6.8 e 6.9, sem a retórica de marketing.
O que o FSE substitui, e o que conserva
O Full Site Editing não eliminou o PHP. Eliminou a necessidade de escrever PHP para controlar a estrutura da página. O que antes era um loop personalizado em functions.php, hoje é um bloco Query Loop configurado no editor visual.
O que permanece: as regras de prioridade de templates do WordPress, a hierarquia functions.php + theme.json, e os hooks de plugin. O que muda é a camada de renderização, que passa de PHP para blocos.
Para o praticante, a distinção importa. Um block theme com dois ficheiros -- style.css com cabeçalho de tema e templates/index.html -- é válido para o WordPress. Não é completo, mas é suficiente para o editor reconhecer o tema.
A anatomia mínima de um block theme
Três ficheiros bastam para um block theme funcional:
style.css-- com o cabeçalho de tema (Theme Name,Version, etc.)templates/index.html-- o template base em marcação de blocostheme.json-- a folha de configuração de design
O theme.json na versão 3, introduzida no WordPress 6.7, unifica paleta de cores, tipografia, espaçamentos e suporte a funcionalidades num único ficheiro declarativo. Não é CSS: é a camada de intenção de design que o motor de blocos traduz em CSS.
A diferença prática entre um block theme de produção e uma prova de conceito está nesta hierarquia: theme.json define os limites; os templates definem a estrutura; os blocos preenchem o conteúdo.
O Editor de Site no WordPress 6.9: cinco áreas, uma hierarquia
O Editor de Site organiza-se em cinco áreas principais: Templates (a estrutura das páginas), Template Parts (fragmentos reutilizáveis como cabeçalho e rodapé), Padrões (blocos compostos guardados), Estilos (a variação visual do tema) e Navegação (gestão de menus integrada no editor).
A hierarquia é linear: um Template usa Template Parts; um Template Part pode conter Padrões; os Estilos aplicam-se ao conjunto. Não existe sobreposição automática entre camadas -- uma alteração de estilo global não sobrescreve os estilos em linha definidos em blocos individuais.
À prática, este comportamento é a maior fonte de fricção para equipas novas no FSE. Antes de tocar num tema de cliente, vale rever a hierarquia de especificidade do block editor.
Template parts: a abstração certa, usada de forma errada
Os template parts foram concebidos para fragmentos estruturais: cabeçalho, rodapé, barra lateral. O erro comum é transformá-los em repositórios de conteúdo editorial -- blocos de texto que deveriam estar em padrões ou directamente no conteúdo da publicação.
O problema aparece em produção: as alterações a template parts propagam-se a todos os templates que os incluem. Um cliente que edite o cabeçalho sem saber isto pode alterar a estrutura de dezenas de páginas ao mesmo tempo.
A solução é editorial antes de ser técnica: documentar claramente, para cada entrega, o que é um template part (estrutura global) versus um padrão (bloco reutilizável mas localizado).
Uma boa prática de entrega: incluir um documento de uma página que explique ao cliente a diferença entre editar um template part e editar o conteúdo de uma página. Esse documento poupa horas de suporte nos meses seguintes.
O bloco Query Loop: o seu loop PHP, sem PHP
O bloco Query Loop reproduz o comportamento de WP_Query sem uma linha de PHP. Filtra por tipo de publicação, taxonomia, autor, data e campos personalizados -- directamente no editor.
Para projectos com tipos de publicação personalizados, o bloco aceita parâmetros via variações de bloco registadas no block.json. Esta extensibilidade é o ponto em que o FSE começa a fazer sentido em projectos mais complexos: a lógica de consulta vive no PHP (registo do bloco), mas a composição visual é feita pelo editor.
theme.json: o que controla, o que delega
O theme.json v3 controla a paleta de cores e gradientes globais, a escala tipográfica com font-size em clamp, os espaçamentos e dimensões (padding, margin, gap), as sombras e raios de canto globais, e o suporte a funcionalidades do editor.
O que o theme.json não controla: a lógica de PHP, os estilos de plugin que carregam fora da folha de estilos do tema, e os estilos em linha aplicados directamente nos blocos no editor.
Esta delimitação é importante para auditorias de tema. Quando um estilo não se comporta como esperado, o primeiro passo é verificar se a sua origem é o theme.json, um plugin, ou um override em linha no bloco. A resposta a essa pergunta orienta o diagnóstico em três direcções completamente diferentes.
Pattern Overrides: estrutura bloqueada, conteúdo editável
Os Pattern Overrides, introduzidos no WordPress 6.8 via Block Bindings API com a fonte core/pattern-overrides, resolvem um problema real de entrega a clientes: como dar flexibilidade de edição sem permitir que a estrutura do design seja alterada.
O mecanismo é preciso: um padrão sincronizado pode marcar blocos específicos como editáveis. O cliente edita o texto ou a imagem desses blocos, mas não pode mover, apagar ou adicionar blocos à volta deles. A estrutura é do designer; o conteúdo é do cliente.
Para freelancers que entregam sites a clientes não-técnicos, este é o recurso de maior impacto do ciclo WordPress 6.8 e 6.9. A implementação usa o atributo metadata.bindings no block.json do padrão. Convém testar o comportamento do editor com o utilizador final antes da entrega: a interface de overrides ainda apresenta alguma fricção para quem nunca usou o editor de blocos.
O que ainda falha em produção
Honestidade sobre os limites é mais útil do que o entusiasmo. Em 2026, o FSE tem três pontos de fricção persistentes em produção real.
O primeiro é a sobrescrita de templates na base de dados. Quando um utilizador guarda alterações a um template no editor, o WordPress persiste essa versão na base de dados (tabela wp_posts, tipo wp_template). O ficheiro no sistema de ficheiros deixa de ser a fonte de verdade. Em actualizações de tema, as versões da base de dados prevalecem. Para agências que actualizam temas de clientes, isto exige um processo de revisão explícito antes de cada actualização.
O segundo é o suporte RTL. Os block themes com margens e padding definidos em theme.json nem sempre espelham correctamente em layouts da direita para a esquerda. O trabalho RTL no FSE exige testes em árabe ou hebraico com conteúdo real, não apenas a activação do atributo dir="rtl".
O terceiro é a profundidade do DOM. A estrutura de blocos aninhados gera uma árvore DOM significativamente mais profunda do que um tema clássico equivalente. Em páginas complexas, isto tem impacto mensurável na performance de renderização. A recomendação prática é auditar a estrutura de blocos com as ferramentas de acessibilidade do navegador antes da entrega final. Blocos Group aninhados desnecessariamente são o culpado mais frequente: aplanar a estrutura onde possível reduz o DOM sem afectar o layout visual.
FAQ
O Full Site Editing é estável para produção em 2026? Sim, com condições. O FSE é estável para a maioria dos projectos de sites de conteúdo. Para lojas WooCommerce complexas ou projectos com muito PHP personalizado, a migração exige planeamento cuidadoso.
Preciso de saber PHP para trabalhar com block themes? Não é obrigatório para a maioria dos projectos. O PHP continua relevante para registar tipos de publicação personalizados, variações de bloco e hooks de plugin -- mas a camada de apresentação pode ser gerida inteiramente em blocos.
O theme.json substitui o style.css?
Não. O theme.json define as configurações de design; o style.css permanece necessário como cabeçalho de tema e para CSS específico que o theme.json não cobre. Os dois coexistem e cumprem funções distintas.
Os Pattern Overrides funcionam apenas com o plugin Gutenberg ou também com o core? Os Pattern Overrides foram introduzidos no core no WordPress 6.8. Não é necessário o plugin Gutenberg para os usar, embora as versões mais recentes do plugin possam incluir melhorias ainda não integradas no core.
Como se compara o editor de site nativo com o Elementor para entrega a clientes? O editor de site nativo tem menor curva de aprendizagem para clientes que já conhecem o editor de blocos. Para projectos que exigem interface visual rica sem código, o Elementor continua a ter vantagem em controlo granular. A escolha depende do perfil do cliente e dos requisitos do projecto.
O que acontece aos temas clássicos quando migro para FSE?
Os temas clássicos continuam a funcionar. O WordPress não obriga à migração. Para uma abordagem progressiva, é possível activar funcionalidades FSE individualmente via theme.json e templates de bloco sem abandonar o tema clássico de imediato.
O colofão deste folio: teste os Pattern Overrides com um utilizador real antes de qualquer entrega. A diferença entre uma demo em ambiente de desenvolvimento e o comportamento em produção com um cliente não-técnico é onde os problemas aparecem.