O Editor de Site à Prova de Cliente: Um Manual de theme.json

Resumo

Quando um cliente abre o Editor de Site do WordPress pela primeira vez, a capacidade de editar cada bloco, cor e layout pode parecer um recurso para ele — e uma ameaça para você. Este artigo explica como usar o theme.json para traçar uma linha clara entre edição de conteúdo e controle de design. Em vez de lutar contra o Editor de Site, você configura predefinições, padrões e limites que tornam seguro para clientes não técnicos atualizarem seu próprio site. Vamos ver o que bloquear, o que deixar aberto e por que o bloqueio excessivo é um risco real. A abordagem é construída em torno de tokens de design e restrições no nível do modelo, para que funcione de forma consistente em todos os sites de clientes que você mantém. Ao final, você terá um fluxo de trabalho repetível para entregar o Editor de Site sem entregar as chaves do seu sistema de design.

Qual é a primeira coisa que você faz quando um cliente envia um e-mail dizendo que "apenas tentou atualizar o título" e o espaçamento do site inteiro desmoronou?

Se você mantém mais de um site WordPress, provavelmente já recebeu essa mensagem de alguma forma. O Editor de Site deu ao seu cliente as chaves de um carro com cinco marchas e sem freio. Eles acham que estão fazendo uma simples alteração de texto e, de repente, a tipografia global está errada, a seção hero da página inicial tem uma cor neon que você não escolheu e dois blocos agora estão empilhados em vez de lado a lado.

Enquanto isso, você está pensando nos outros seis sites de clientes que você atende, e a última coisa que você precisa é de uma armadilha de manutenção em que cada edição "útil" do cliente exija uma restauração a partir do backup.

A resposta não é tirar o Editor de Site. É definir limites dentro dele usando o theme.json. De acordo com os Recursos para Desenvolvedores do WordPress, o theme.json é a fonte central da verdade para as configurações e estilos do editor de blocos — ele define as paletas de cores, tipografia e opções de layout que aparecem para o cliente. Isso significa que o mesmo arquivo que controla seu design também pode controlar o que seu cliente pode ou não editar.

Vamos analisar como pensar sobre isso, porque a maioria dos tutoriais foca no que o theme.json pode fazer pelos desenvolvedores. A pergunta para uma agência é diferente: como usar isso para tornar os clientes seguros sem fazer com que se sintam encurralados?

Por que o Editor de Site parece tão perigoso?

Seu cliente não está tentando quebrar o site. Eles estão tentando fazer o que você os treinou para fazer por anos no editor antigo: mudar um título, trocar uma imagem, talvez adicionar um parágrafo. O perigo não é a intenção deles — é que o Editor de Site exibe controles globais no mesmo lugar que os controles de conteúdo.

Aqui está um cenário comum. Um cliente abre um modelo no Editor de Site e vê um bloco de título. Ele muda a cor para combinar com o novo tom da marca. Mas como esse título está em um modelo, a alteração se aplica a todos os lugares em que o modelo é usado. Para o cliente, parecia uma única edição. Para o site, foi uma mudança global.

O princípio geral: quando você entrega a alguém um construtor de páginas, essa pessoa eventualmente encontrará as "configurações com proteções" e as desativará. Mas com o theme.json, você pode ocultar as próprias proteções. Em vez de dizer ao cliente "não toque nos estilos globais", você simplesmente não mostra a ele uma paleta de cores que possa produzir um resultado ruim. Você define uma paleta de cores aprovadas, uma escala de tamanhos de fonte e um conjunto de predefinições de espaçamento — e o cliente escolhe a partir delas, não do espectro completo do CSS.

Essa é a primeira mudança: pare de pensar em regras e comece a pensar em fábricas. O theme.json é a sua linha de produção. Você configura as opções que o cliente vê, e as restrições são impostas pela própria interface, não por um conjunto de instruções em um documento de transferência.

O que você deve realmente bloquear?

Não tudo. Se você bloquear a área de conteúdo com muita rigidez, o cliente ou vai ligar para você toda vez que precisar adicionar um parágrafo, ou vai encontrar uma maneira de contornar você — muitas vezes adicionando um plugin pontual ou copiando HTML do site antigo.

Aqui está uma tabela prática do que bloquear, o que deixar e por quê:

Área de edição	Bloquear?	Por quê?
Estrutura do modelo e layouts de blocos	Bloquear	Evita a remoção ou reordenação acidental de blocos de layout principais
Estilos globais (cores, fontes, predefinições de espaçamento)	Bloquear com predefinições	Os clientes escolhem a partir de um conjunto aprovado, não valores arbitrários
Texto e imagens de conteúdo	Deixar aberto	Este é o trabalho deles; deixe-os fazer sem pedir permissão
Espaçamento entre blocos	Bloquear parcialmente	Forneça predefinições de espaçamento para que possam ajustar o ritmo sem quebrar o alinhamento
Padrões de blocos curados	Deixar aberto se você os aprovou	Uma maneira segura de os clientes adicionarem novas seções sem construir do zero

A nuance importante é "bloquear com predefinições", não "bloquear completamente". Para estilos globais, você não está ocultando o painel de configurações; está reduzindo o número de escolhas a um conjunto selecionado. Para a estrutura do modelo, você pode bloquear certos blocos para que não possam ser removidos, mas ainda permitir que os clientes editem o texto dentro deles.

Uma palavra de cautela: bloquear um bloco em um modelo é diferente de bloqueá-lo em uma página específica. Os bloqueios de modelo afetam todo o conteúdo que usa o modelo. Se você precisar de diferentes níveis de bloqueio em páginas diferentes, precisará trabalhar no nível do bloco dentro do editor, o que é mais frágil. Para o trabalho repetível de agência, projete seus modelos para que as áreas bloqueadas sejam consistentes.

Como definir limites sem fazer o editor parecer uma armadilha?

A técnica é definir seus tokens de design no theme.json e depois resistir a fazer qualquer outra coisa em CSS.

Por exemplo, em vez de deixar o cliente definir uma cor arbitrária em um botão, você define um estilo de botão no theme.json que usa uma cor específica da sua paleta. O cliente ainda pode selecionar o botão e alterar o texto, mas o seletor de cores mostra apenas as amostras aprovadas. O mesmo vale para tamanhos de fonte, alturas de linha e espaçamento.

O mesmo princípio se aplica aos modelos. Você pode usar o recurso "bloquear" em blocos específicos dentro de um modelo — por exemplo, bloqueando a estrutura de colunas de um bloco de depoimento para que o cliente possa alterar o texto da citação, mas não transformar três colunas em duas. Se você ainda não usou o bloqueio de blocos, ele está disponível na barra de ferramentas do editor; ao bloquear um bloco, você pode escolher se o cliente pode editar o conteúdo, movê-lo ou ambos. Você pode até aplicar isso no theme.json para padrões no nível do bloco.

O que você busca é um editor em que o cliente nunca veja um controle que possa quebrar o design. Isso não significa que ele não possa fazer nada errado; significa que a pior coisa errada que ele pode fazer é mudar a redação de um título, não a aparência do site inteiro.

Se você estiver usando tipos de conteúdo personalizados, os mesmos princípios se aplicam além dos modelos padrão — veja nosso guia sobre estender o theme.json para tipos de conteúdo personalizados e saída de plugins.

O que acontece quando você bloqueia demais?

Aqui está o ponto contraditório: o bloqueio excessivo é tão prejudicial quanto o bloqueio insuficiente. Um cliente que não consegue redimensionar um título ou adicionar um espaço entre seções acabará pedindo que você "apenas deixe com a aparência certa" — e então você volta a fazer pequenas edições de graça. Pior, eles podem decidir que o Editor de Site é inútil e voltar para um construtor de páginas de terceiros, que lhes dá controle demais novamente.

O trade-off é real. Editores com bloqueios rígidos geram menos chamadas de emergência, mas também geram mais pedidos como "você pode mover este botão cinco pixels para cima?". Editores abertos geram o oposto. Seu trabalho é encontrar o ponto de equilíbrio para cada cliente, não aplicar uma configuração universalmente.

Uma boa heurística inicial: bloqueie tudo o que afeta todas as instâncias de algo (estilos globais, estrutura de modelos) e deixe aberto tudo o que afeta uma instância (o texto e as imagens de uma única página). Se um cliente quebrar uma única página, é um conserto de 5 minutos. Se ele quebrar um estilo global, é um conserto de 20 minutos e uma preocupação de segurança.

Como tornar isso repetível entre clientes?

É aqui que o fluxo de trabalho da agência entra em ação. Você deve ter um theme.json base que define seus tokens de design — a paleta de cores, a escala tipográfica e as predefinições de espaçamento — e depois um arquivo de substituição por cliente que estende ou altera valores específicos.

Comece criando um tema de blocos "inicial". Aqui está como construir um tema de blocos personalizado com o theme.json — depois que você o desenvolveu e documentou, copiá-lo para um novo cliente é uma questão de trocar as cores e fontes da marca. Você não está reinventando a roda; está trocando tokens. Isso é exatamente a mentalidade de parar de reconstruir cada site WordPress, mas aplicada ao editor em vez do backend.

Como o theme.json é um único arquivo, também é fácil fazer controle de versão e implantação em vários ambientes. Você pode revisar alterações, ver o que um cliente modificou nos estilos globais e comparar essas mudanças com seu arquivo base. Isso fornece uma trilha de auditoria sólida para solicitações de suporte.

Se você mantém vários sites e ainda não configurou um tema base, esta é a sua chance. É a única parte do trabalho personalizado com WordPress que se paga toda vez que um cliente abre o editor.

E os clientes que continuam pedindo "mais uma cor"?

Sua paleta é uma promessa. Se você define cinco cores da marca e um cliente pede uma sexta, a resposta não é "não" — é "sim, mas ela chega como uma adição deliberada à paleta, não como um código hex único em um título". Quando você adiciona uma cor ao theme.json, ela fica disponível de forma consistente em todo o site. Essa é a maneira certa de lidar com esses pedidos.

É também aqui que você precisa se comunicar com o cliente. Explique que o Editor de Site mostra a ele apenas as cores e fontes que correspondem aos padrões da marca. Se eles quiserem expandir esses padrões, você cuidará disso no sistema de design, e então cada nova cor estará disponível em todos os lugares — inclusive em páginas futuras que ainda não foram construídas. Essa é uma resposta muito melhor do que "não fazemos isso".

Ao mesmo tempo, não acumule uma paleta de quarenta cores. Revise-a trimestralmente e remova qualquer coisa que tenha sido um acidente pontual. O objetivo é um conjunto pequeno e intencional de opções.

Se você bloquear o layout, mas deixar o conteúdo, e fizer da paleta uma parte viva do seu relacionamento com o cliente, o Editor de Site deixa de ser uma ameaça. Ele se torna uma maneira de dar aos seus clientes autonomia real sem sacrificar os padrões de design que você é pago para proteger.