Padrões de Blocos e Template Parts no WordPress FSE

Padrões de blocos no WordPress são conjuntos pré-configurados de blocos que você registra uma vez e reutiliza em qualquer parte do site. Parece simples. Mas quando você combina isso com Template Parts do Full Site Editing, o resultado é uma arquitetura de conteúdo que economiza horas de trabalho toda semana. Depois de configurar mais de 300 sites em WordPress, a equipe da Weboption aprendeu exatamente onde essa estrutura brilha e onde ela pode virar um pesadelo se você não entender as diferenças entre cada componente.

O que são padrões de blocos e por que eles importam no FSE

Padrões de blocos no WordPress são layouts compostos que o editor Gutenberg trata como uma unidade. Você insere o padrão, e ele explode em vários blocos individuais que podem ser editados livremente. É diferente de um bloco único: um padrão pode conter uma coluna de texto, uma imagem, um botão e um espaçador, todos juntos.

O WordPress 5.5 introduziu o sistema de padrões nativamente. Hoje, na versão 6.5, o diretório oficial lista mais de 1.200 padrões gratuitos. Mas o que realmente muda o jogo para agências é a capacidade de registrar padrões próprios diretamente no tema ou plugin.

No contexto do Full Site Editing, padrões funcionam tanto no editor de páginas quanto no editor de site. Isso significa que você pode criar um padrão de cabeçalho promocional e disponibilizá-lo tanto para o cliente editar em posts quanto como ponto de partida para template parts.

Como registrar padrões de blocos no WordPress

Registrar um padrão é direto. A função register_block_pattern() recebe um nome com namespace e um array de argumentos. O campo content aceita o HTML serializado dos blocos.

A forma mais limpa de fazer isso em um tema FSE é colocar arquivos .php na pasta /patterns do tema. O WordPress 6.0 passou a carregar esses arquivos automaticamente, sem precisar de chamada manual. Cada arquivo usa cabeçalhos de comentário para definir o título, as categorias e se o padrão é sincronizado.

Um detalhe que pega muita gente: o campo inserter controla se o padrão aparece no painel de inserção do editor. Se você criar padrões para uso programático, como templates de página que nunca devem aparecer para o cliente, defina inserter => false.

Na Weboption, organizamos os padrões em categorias personalizadas usando register_block_pattern_category(). Em projetos com 20 ou mais padrões, essa organização faz diferença real na experiência do cliente dentro do editor.

Padrões sincronizados versus padrões não sincronizados

Essa é a distinção que mais confunde desenvolvedores e clientes. A partir do WordPress 6.3, padrões podem ser sincronizados. Um padrão sincronizado funciona como um bloco reutilizável: altere em um lugar, a mudança reflete em todos os locais onde ele foi inserido. Um padrão não sincronizado é uma cópia. Inseriu, é seu. Edite à vontade sem afetar outras instâncias.

Quando usar cada um? Padrões sincronizados fazem sentido para elementos que precisam de consistência absoluta: rodapés de posts, banners de aviso, blocos de contato. Um estudo interno que fizemos em 2024 mostrou que sites com padrões sincronizados para elementos recorrentes reduzem o tempo de manutenção em cerca de 40% ao longo de seis meses.

Padrões não sincronizados são a escolha certa para layouts que servem como ponto de partida. O cliente pega o padrão, personaliza o texto e a imagem para aquela página específica, e pronto. Sem risco de alterar acidentalmente outras páginas.

O erro que vemos com frequência: equipes configurando tudo como sincronizado. O cliente edita o banner de uma landing page, sem perceber que está alterando o banner de todas as outras páginas do site. O resultado é uma ligação tensa e uma hora de trabalho para reverter.

Template Parts: cabeçalho, rodapé e sidebar no FSE

Template Parts são fragmentos de template que o FSE trata separadamente do template principal. O WordPress os armazena no banco de dados como posts do tipo wp_template_part, ou como arquivos HTML na pasta /parts do tema.

O cabeçalho e o rodapé são os casos mais óbvios. Em vez de repetir o mesmo HTML em cada template de página, você define um template part de cabeçalho e o referencia em todos os outros templates. A diretiva no HTML do template fica assim: <!-- wp:template-part {"slug":"header","theme":"meu-tema","tagName":"header"} /-->.

O atributo area define como o WordPress classifica o template part: header, footer ou uncategorized. Isso afeta onde ele aparece na interface do editor de site. Template parts com area header aparecem na seção de cabeçalhos do editor. Parece detalhe, mas organiza muito a experiência para o cliente.

Sidebars no FSE funcionam diferente do WordPress clássico. Não existe mais o conceito de widget area registrada via PHP. A sidebar agora é um template part como qualquer outro, inserido no template de página com o bloco de colunas ou com o bloco de grupo. Quem migra de temas clássicos para FSE precisa entender essa mudança de paradigma antes de começar a construir.

Blocos reutilizáveis versus padrões: qual usar

Blocos reutilizáveis existem desde o WordPress 5.0. Padrões chegaram no 5.5. Muita gente usa os dois sem saber a diferença real.

Blocos reutilizáveis são sempre sincronizados por definição. Você cria um bloco de chamada para ação, salva como reutilizável, e ele aparece igual em todo lugar onde foi inserido. A sincronização é automática e não pode ser desativada. No editor, eles aparecem com uma borda azul indicando que são instâncias de um bloco centralizado.

Padrões com sincronização são tecnicamente a evolução dos blocos reutilizáveis. A partir do WordPress 6.3, a interface do editor unificou os dois sob o menu de padrões. Blocos reutilizáveis antigos foram migrados para a nova nomenclatura. Mas o comportamento central permanece: sincronizados se propagam, não sincronizados são cópias independentes.

A nossa recomendação prática: use padrões para tudo novo. Blocos reutilizáveis ainda funcionam, mas a interface de gerenciamento de padrões no WordPress 6.4 e 6.5 é muito superior. Você filtra por categoria, pré-visualiza antes de inserir, e o gerenciamento via editor de site é mais intuitivo.

Erro comum que vemos em agências

O problema mais frequente que encontramos em auditorias de sites: padrões registrados com conteúdo hardcoded em português, sem suporte a internacionalização. Parece irrelevante para um site monolíngue. Mas quando o cliente decide criar uma versão em inglês ou espanhol, todo o trabalho de tradução dos padrões precisa ser refeito do zero.

A solução é simples e leva menos de dez minutos por padrão: envolva strings textuais em funções de tradução antes de serializar o HTML. O processo de serialização do Gutenberg preserva as chamadas de função quando você gera o conteúdo via PHP antes de registrar.

Outro erro: misturar padrões de tema com padrões de plugin sem planejamento. Quando o cliente troca de tema, padrões registrados pelo tema somem do editor. Se o padrão precisa persistir independente do tema ativo, registre via plugin.

Perguntas frequentes

Padrões de blocos no WordPress substituem os blocos reutilizáveis?

Funcionalmente, sim. O WordPress 6.3 unificou a interface, e padrões sincronizados fazem o mesmo trabalho que blocos reutilizáveis. Blocos reutilizáveis ainda existem e funcionam, mas a gestão via sistema de padrões é mais completa e organizada.

Template parts funcionam em temas clássicos?

Não. Template parts são uma funcionalidade exclusiva do Full Site Editing, que exige um tema com suporte a block-templates declarado no theme.json. Em temas clássicos, você usa a função get_template_part() do PHP, que é um conceito diferente.

Como compartilhar padrões entre múltiplos sites WordPress?

A forma mais eficiente é criar um plugin de padrões dedicado. Você registra todos os padrões no plugin, instala em cada site, e gerencia atualizações de um ponto central. Algumas equipes usam o WordPress.com Pattern Directory para distribuição pública, mas para uso privado entre sites de clientes, um plugin próprio é a solução mais segura.

Padrões sincronizados afetam a performance do site?

O impacto é mínimo. O WordPress armazena padrões sincronizados como posts no banco de dados e os renderiza normalmente. A diferença de performance em relação a conteúdo inline é negligenciável. O que pode afetar performance é o conteúdo dentro do padrão, não a sincronização em si.

Quanto custa implementar um sistema de padrões personalizado?

Depende da complexidade. Para um site com 10 a 15 padrões customizados e template parts básicos de cabeçalho e rodapé, estamos falando de 8 a 12 horas de desenvolvimento, o que na Weboption representa entre R$ 1.600 e R$ 2.400. Projetos maiores com categorias, padrões internacionalizados e documentação para o cliente podem chegar a R$ 5.000 ou mais.