Pare de reconstruir todos os sites WordPress

Resumo

A maioria das agências constrói todos os sites WordPress a partir de um tema em branco, mesmo quando uma fundação compartilhada cortaria semanas do cronograma. Este artigo argumenta que theme.json, padrões de bloco e blocos dinâmicos permitem padronizar a camada estrutural enquanto preservam o design distinto de cada cliente. Ele aborda diretamente as cinco objeções que impedem as equipes de mudar: ‘temos clientes diferentes’, ‘blocos personalizados são caros’, ‘o editor é confuso’, ‘perderemos nossos hooks e filtros’ e ‘FSE não está pronto para produção’. Cada objeção recebe um contra-argumento prático e um padrão concreto que você pode adotar incrementalmente. A recompensa é um processo de criação repetível que ainda honra o trabalho sob medida onde ele pertence. Aviso: nenhum botão de redefinição de um clique é prometido.

Quantos dos sites de seus clientes compartilham até mesmo uma linha de código? Não a linha de direitos autorais—código real. Se a resposta é "quase nenhum", você já sentiu a dor: a mesma seção hero reconstruída pela nona vez, a mesma marcação de grade de equipe copiada de um projeto para outro, os mesmos ajustes de pré-processamento referenciados entre meia dúzia de temas. Você também ouviu a defesa: "Cada cliente tem necessidades diferentes." Verdade. A conclusão que todos tiram, no entanto—que cada site precisa de uma base sob medida—é falsa. O ecossistema WordPress agora oferece uma maneira de padronizar as peças estruturais sem padronizar o design: theme.json para tokens de design, padrões de bloco para layout repetido e blocos dinâmicos para as poucas funcionalidades que precisam de lógica real no servidor. Este artigo é sobre as objeções que impedem as agências de dar esse passo e o que realmente funciona quando você as enfrenta.

A objeção "mas cada cliente é diferente"

O princípio subjacente: padronize a fundação, não a superfície. A razão para manter a estrutura em uma biblioteca compartilhada é exatamente deixar a camada visual livre. Um arquivo theme.json não é um design—é um conjunto de tokens de design. Cores, espaçamento e tipografia são valores, não marcação. Essa é a mudança crítica: você pode compartilhar a marcação enquanto um theme.json específico do site faz com que o site pareça completamente diferente para uma marca diferente.

Considere dois clientes: um escritório de advocacia e uma loja de artigos para atividades ao ar livre. Suas linguagens de design estão a quilômetros de distância. Mas ambos precisam de uma seção hero, uma grade de depoimentos, uma faixa de chamada para ação. Em vez de reconstruir a marcação para cada um, mantenha três padrões de bloco e deixe que o theme.json de cada cliente defina cores, fontes e espaçamento. A estrutura permanece idêntica; os tokens de design a transformam de uma marca para a outra. Quando a loja mudar sua paleta de cores na próxima primavera, você edita um arquivo no site deles—não a marcação em seis modelos.

Na prática, isso significa que sua equipe cria padrões como código, os registra em um plugin compartilhado e deixa que o theme.json de cada site de cliente cuide da pintura. Os nomes de classe do padrão se tornam sua arquitetura; os valores se tornam as variáveis. Você pode até ir além e estender o theme.json para incluir configurações personalizadas para tipos de post ou saída de plugins, embora em algum momento você esteja construindo uma interface de configuração em vez de um site—uma armadilha discutida em nossa análise sobre como estender o theme.json. Mantenha a camada compartilhada enxuta: ela deve conter apenas o que se repete entre clientes. No momento em que você se pega adicionando uma configuração "caso alguém queira um dia", você criou uma abstração que custará mais para manter do que economiza.

Ao configurar um novo cliente, os primeiros trinta minutos devem ser: clonar o plugin de padrões compartilhados, criar um novo theme.json com a paleta e a escala de fontes do cliente e registrar o logotipo e o rodapé. Isso não é uma construção personalizada; é uma tarefa de configuração. O trabalho restante específico do cliente vai para conteúdo, estrutura e quaisquer recursos genuinamente sob medida. Essa é a diferença entre construir cada casa do zero e ter um conjunto de plantas baixas pré-fabricadas que você pode repintar e repapelar. A analogia é frouxa, mas o princípio é válido: quanto mais você coloca nos valores do theme.json, menos você precisa mexer na marcação.

Uma das vitórias mais simples é realmente observar como os padrões de bloco funcionam. Um padrão é apenas uma coleção de blocos com conteúdo e estilo predefinidos. Você pode salvar qualquer configuração de bloco como um padrão, e então um cliente pode inseri-lo sem precisar saber como foi construído. Isso significa que o padrão se torna um 'ponto de entrada' para usuários não técnicos. Quando sua equipe mantém o padrão subjacente em código, o cliente obtém uma biblioteca consistente sem tocar em uma única tag PHP.

Agora, a ressalva à qual sempre volto: não centralize demais. Um theme.json com uma configuração para cada nuance concebível é um pântano de manutenção. Padrões compartilhados devem ter opinião, não ser onipotentes. Se um cliente precisa de um layout radicalmente diferente—digamos, uma página inicial de revista com uma grande grade em destaque—ele pode não se encaixar na sua biblioteca de padrões padrão. Tudo bem. Padronização significa que você vence nos 80% dos projetos que são semelhantes, não que força cada site a entrar no mesmo molde.

A objeção de que "blocos personalizados estouram o orçamento"

Aqui está um contraprincípio que parece chato, mas economiza dinheiro: a maioria das coisas que você acha que precisam de um bloco personalizado não precisa. Blocos nativos mais um padrão podem cobrir a grande maioria dos layouts. O bloco personalizado é o último recurso, não a primeira intenção.

O exemplo clássico é a grade de equipe. Se for uma única vez, use os blocos nativos "colunas" e "grupo" e deixe o cliente adicionar um avatar manualmente. Se três clientes pedirem a mesma grade com a mesma estrutura de "links sociais abaixo do nome", você agora tem um candidato a padrão de bloco. Quando esse padrão começa a acumular novas opções—efeitos de hover, ordenação, estrelas de avaliação—o padrão se torna uma sacola incontrolável, e então é hora de escrever um bloco personalizado. O erro que machuca o orçamento é pular direto para o bloco personalizado no primeiro pedido.

Um cenário mais insidioso: o cliente pede um "carrossel de estudos de caso". O primeiro instinto é pensar: "Preciso de um bloco de carrossel." Mas será que ele precisa de um carrossel? Talvez precise de um grupo de posts com rolagem horizontal, que os blocos nativos podem lidar com um bloco "grupo" e algum CSS. Ou talvez precise de uma lista dinâmica de estudos de caso recentes, que é um bloco dinâmico que consulta o CPT. A pergunta não é "qual recurso o cliente quer?" mas "de quais dados isso depende?" Se os dados são estáticos e editáveis pelo cliente, um padrão resolve. Se os dados vêm de uma consulta ao banco de dados, um bloco dinâmico é justificado. Se os dados precisam ser atualizados em tempo real de uma API, talvez você esteja olhando para uma integração REST API—isso cruza para um tipo diferente de criação.

Quando você construir um bloco, block.json é seu amigo. É a fonte única de verdade para atributos, scripts e estilos, o que torna o bloco portável entre projetos. Ele também permite declarar dependências e traduções de forma limpa, o que é essencial quando você distribui uma biblioteca em muitos sites de clientes. Para conteúdo que depende de dados ao vivo, um bloco dinâmico renderiza no servidor, então você não precisa enviar um bundle JavaScript em cada visualização de página. E se o seu bloco evoluir, você pode lidar com depreciações graciosamente para que o conteúdo existente não quebre—nosso guia para depreciação de blocos mostra o padrão exato.

Antes de construir qualquer coisa, avalie a decisão por esta grade:

Abordagem	Melhor para	Evite quando
Bloco nativo	Conteúdo único, páginas simples	O layout se repete em muitos clientes e precisa de opções ricas
Padrão de bloco	Layouts repetíveis sem lógica	O layout precisa de condicionais, dados dinâmicos ou interações complexas
Bloco personalizado	Comportamento repetido, orientado a dados ou altamente específico	O único motivo é uma seção única que pode ser tratada com uma classe

Você também vai querer pensar na nomenclatura de blocos desde o primeiro dia. Um nome de bloco é essencialmente um contrato com seu conteúdo. Se você o chamar de wagent/team-grid e depois renomeá-lo para wagent/team-carousel, você quebrará o conteúdo existente, a menos que forneça um caminho de depreciação. Escolha nomes genéricos e baseados em propósito que não se tornem propaganda enganosa conforme o bloco evolui. Isso é um sabor da disciplina de nomenclatura que todos aprendemos com prefixos de plugins, e se aplica tanto a nomes de blocos.

A visão contrária aqui é a coisa mais útil que posso dizer: o bloco personalizado que você constrói porque um cliente pediu "apenas uma peça" é quase sempre um erro. Diga não educadamente, entregue um bloco nativo com uma classe e economize as horas. Você terá mais respeito do cliente—e uma linha menor no orçamento de manutenção.

A objeção de que "os clientes quebrarão o editor"

Essa objeção está meio certa. O editor de blocos em si não é o problema; o problema é dar aos clientes muita corda. O theme.json pode restringir o que é editável: desativar o editor de modelos, restringir os blocos permitidos e definir estilos padrão para que uma coluna mal posicionada cause menos danos. Alguns clientes ainda conseguirão quebrar as coisas, mas você pode restaurar uma página para um padrão salvo em um clique—algo que o editor clássico não podia oferecer.

Deixe-me pintar um cenário. Um cliente liga e diz: "Movi uma seção e agora a página inteira parece errada." Com um tema clássico, você faria login, inspecionaria o CSS e provavelmente gastaria uma hora corrigindo o layout. Com uma configuração de blocos, você pode abrir a página, selecionar a área de conteúdo e redefini-la para o padrão salvo. O padrão é a linha de base; as alterações do cliente são a sobreposição. Quando a sobreposição dá errado, você a remove. Isso não é apenas um fluxo de trabalho melhor; é um editor fundamentalmente mais tolerante.

Agora a nuance: a maioria dos clientes não quer editar muito. Eles querem mudar texto, trocar fotos e talvez reordenar uma seção. O padrão de bloco oferece exatamente isso sem expor toda a estrutura do site. Nesse sentido, o editor não é um brinquedo; é um visor. Seu trabalho é calibrar o que os clientes podem ver. Isso significa que você pode desativar as configurações de "Modelos", limitar o inseridor de blocos a uma lista selecionada e até pré-preencher padrões vazios com trabalho de espaço reservado. O editor se torna um formulário de entrada de conteúdo em vez de uma tela de design web.

No lado da acessibilidade, o gerenciamento de foco e o suporte a teclado do editor de blocos são geralmente melhores do que os campos de modelo do editor clássico. Mas você ainda precisa garantir que os padrões tenham hierarquia de títulos adequada e nomes acessíveis. Como o padrão é compartilhado entre clientes, você corrige esses problemas apenas uma vez, o que é outra vitória oculta da padronização.

A parte genuinamente difícil é interna. Para sua equipe, aprender a prototipar com blocos exige desaprender o hábito de "fazer em PHP". Isso é um custo real, mas é um custo único por pessoa. Não é uma razão para evitar a abordagem; é uma razão para começar com uma biblioteca de padrões e um cliente tolerante antes de implementar em todos os lugares. Não deixe o refrão "meus clientes não sabem lidar com blocos" esconder o fato de que você ainda não configurou uma configuração de blocos para encontrá-los no meio do caminho.

A objeção de que "já temos hooks e filtros"

O princípio aqui é: você não está descartando hooks; está adicionando uma camada por cima. Blocos são a fronteira de apresentação; hooks ainda são como você injeta lógica. O callback de renderização de um bloco dinâmico roda em PHP, o que significa que você pode chamar as mesmas funções e aplicar os mesmos filtros em que já confia.

Imagine um plugin que permite adicionar um campo de "produto em destaque" a qualquer post usando um filtro. Com um bloco dinâmico, você pode incluir um bloco renderizado no servidor que executa esse filtro e imprime a saída dentro do wrapper do bloco. O cliente insere o bloco; a lógica PHP existente faz o trabalho pesado. Nada é jogado fora. Para um exemplo ainda mais concreto, considere um bloco personalizado que lista posts de projetos recentes. Em seu callback de renderização, você chama get_posts(), depois loop e aplica the_title() e the_permalink()—as mesmas tags de modelo que você usa há anos.

Este também é o lugar para ser honesto sobre o que não se traduz. Alguns temas antigos inteligentes usam template-parts com condicionais intrincadas que recebem argumentos com base no contexto da página. Recriar isso como um bloco pode ser confuso. Mas você não precisa recriar tudo de uma vez. O caminho incremental é manter a lógica PHP, envolvê-la em um bloco dinâmico e mover a marcação para o modelo do bloco. Muitas vezes, você descobrirá que seus padrões de filtro existentes podem lidar com a nova saída. E se a lógica estiver fortemente acoplada a uma hierarquia de modelos (por exemplo, "em resultados de pesquisa, mostre isso de forma diferente"), você ainda pode usar o modelo clássico para essas visualizações específicas enquanto usa blocos para páginas regulares.

A REST API também abre uma porta diferente: você pode construir blocos que buscam dados de outros sites WordPress ou serviços de terceiros. Um bloco dinâmico pode chamar wp_remote_get() para buscar JSON e renderizá-lo no front-end. Esse é um padrão poderoso para criações de agência em que os clientes querem mostrar feeds sociais, listagens de produtos ou dados internos sem gerenciar uma integração separada. A compensação é cache e tratamento de erros—se a API remota for lenta, sua página será lenta. Mantenha blocos baseados em API fora do conteúdo crítico acima da dobra, ou use renderização do lado do cliente com um estado de carregamento adequado.

Ações e filtros ainda rodam em torno de salvar e renderizar; a arquitetura de hooks não desaparece quando você adota blocos, apenas se move para um novo contexto. Se você precisar renovar sua compreensão de onde ações e filtros se encontram nesse novo mundo de blocos, nossa análise aprofundada de hooks é um bom lembrete.

A objeção de que "FSE não está pronto para produção"

Justo, mas pergunte o que "arriscado" realmente significa. O Full Site Editing passou por vários lançamentos, e o theme.json se estabeleceu em um esquema estável. O risco não é que o editor "quebre de repente"—o risco é que o código personalizado da sua equipe possa depender de modelos PHP antigos que coexistem de forma estranha com modelos de blocos. Além disso, alguns plugins de terceiros ainda assumem o editor clássico ou o personalizador. Isso é uma decisão de compatibilidade, não uma razão para jogar fora todo o modelo.

Uma maneira útil de pensar sobre isso: sites simples e repetíveis com conteúdo escrito em blocos são os de menor risco. Clientes de alto risco são aqueles com temas clássicos profundamente personalizados ou plugins proprietários que renderizam seu próprio front-end. Essa é uma razão legítima para continuar com temas clássicos nesse pequeno nicho. O erro é fingir que "pronto para produção" é um único interruptor que está ligado ou desligado.

Antes de propor um tema de blocos a um cliente, percorra uma lista de verificação rápida:

• O cliente tem um tema altamente personalizado que exigiria migração?
• Os plugins essenciais suportam o Editor do Site e a REST API?
• O ambiente de hospedagem permite o acesso a arquivos que o tema de blocos espera?
• Você reservou tempo para o design de padrões, não apenas para o registro de blocos?
• A equipe do cliente tolerará as mudanças no editor, ou eles precisam de um modelo bloqueado?

Se alguma resposta for não, ajuste o escopo ou use uma abordagem híbrida. Isso não é um compromisso; é julgamento de engenharia. E se você estiver construindo algo híbrido, lembre-se da história de hooks e filtros acima—você ainda pode envolver a lógica antiga em blocos dinâmicos enquanto o theme.json cuida do visual global.

Versionar seu theme.json não é apenas uma preocupação teórica. Já vi a biblioteca de blocos personalizados de uma agência quebrar quando o cliente atualizou o WordPress e o arquivo style do bloco registrado com wp_register_style() sob um identificador alterado. A correção foi fácil, mas o pânico foi real. Um processo simples de teste—executar a atualização em uma cópia de staging do site, clicar nas páginas principais e depois lançar—resolve a maioria dessas surpresas.

A objeção que você ainda não fez a si mesmo

Aqui está a meta-objeção que impede as agências de padronizar: "É uma mudança grande, e não há tempo para fazê-la durante o trabalho com clientes." Isso é verdade—então não a faça durante o trabalho com clientes. Escolha um projeto interno ou um cliente pequeno e crie uma biblioteca de padrões. Use theme.json como sistema de tokens de design. Adicione um bloco personalizado apenas quando justificado. Envolva os hooks antigos onde eles ajudam. Itere.

Aqui está um primeiro mês aproximado:

1. Audite seus últimos cinco builds de clientes e liste as dez peças de layout mais repetidas.
2. Transforme essas dez peças em padrões de bloco, com um pequeno conjunto de classes CSS.
3. Crie um plugin compartilhado (ou mu-plugin) que registre esses padrões. Se você ainda não pensou na organização de plugins para isso, folheie este guia para construir plugins robustos primeiro.
4. Crie um theme.json que corresponda ao seu design de base; adicione valores específicos do cliente à medida que inicia projetos.
5. Escolha um pequeno projeto interno ou um cliente amigável e migre-o para a pilha.
6. Documente uma história de sucesso de um cliente que editou sua página inicial sem ligar para você.

No final desse experimento, você não terá um distintivo de "blocos primeiro" para pendurar na parede. Você terá uma equipe que pode criar um novo site de cliente a partir de uma base compartilhada sem se desculpar pelo cronograma. Você também estará em melhor posição para dizer não ao pedido do cliente por um 42º bloco personalizado—porque você sabe exatamente o que os blocos nativos podem fazer, ou porque pode mostrar por que um bloco dinâmico seria genuinamente mais rápido.

Você ainda construirá alguns sites sob medida? Sim. Alguns clientes sempre precisarão de um modelo personalizado, uma página sob medida ou uma integração proprietária que não vale a pena forçar no modelo compartilhado. O objetivo não é eliminar o trabalho sob medida—é torná-lo a exceção em vez do padrão.

A repetibilidade vem das partes chatas: um esquema theme.json sólido, uma biblioteca de padrões clara e a disciplina para manter a camada compartilhada enxuta. Essa não é a versão brilhante que você ouve em webinars. É a que vence a tristeza de segunda-feira de manhã com tema em branco.