Snippets WordPress: onde guardar código e limpar revisões em vários sites

Você atualiza o tema pela manhã e, à tarde, o site do cliente perdeu o botão de WhatsApp, o filtro do WooCommerce e aquele ajuste de checkout. O código estava no functions.php do tema pai. Snippets WordPress guardados no lugar errado não são um problema de organização: são uma promessa de que a próxima atualização vai apagar o que você escreveu. E quando isso acontece em um site só, é chato; quando acontece em dez, é uma tarde inteira reconstruindo o que já estava funcionando.

Este artigo trata das duas pontas que se cruzam na manutenção de vários sites: onde cada snippet deve morar e o que fazer com as revisões que se acumulam no banco. A ordem de decisão importa mais que a ferramenta.

Onde cada snippet deve morar

Antes de escolher o plugin, responda a uma pergunta: esse código é do site ou do cliente? A resposta define o lugar.

Existem três lugares possíveis para código solto no WordPress, e cada um tem um comportamento diferente diante de atualizações:

Na prática, a divisão que funciona é esta: código que só faz sentido com aquele tema (tamanhos de imagem, remover suporte a blocos, ajustar um template) vai no child theme. Código que é regra do site (redirecionamento, filtro de preço, integração com CRM, ajuste de checkout) vai em um plugin de snippets. Código de infraestrutura, que precisa ser idêntico em todos os sites, também vai em plugin de snippets, porque assim ele sobrevive à troca de tema.

O motivo é simples: o child theme depende do tema pai. Se o cliente decide trocar de tema no ano que vem, o child theme inteiro é descartado, e o snippet vai embora com ele. O plugin de snippets não tem essa dependência.

Snippets WordPress que precisam ser idênticos em todos os sites

Quem administra vários sites costuma repetir um conjunto de snippets em todos eles. Alguns exemplos comuns: desabilitar a edição de arquivos pelo painel, limitar revisões, desativar XML-RPC, remover a meta generator, ajustar o intervalo do WP-Cron.

Esse conjunto é o seu padrão de infraestrutura. Ele deve ser versionado fora do WordPress, em um repositório ou em um arquivo de texto com o código e a data da última alteração. Se um snippet de infraestrutura muda, ele muda em todos os sites ao mesmo tempo, ou você vai ter dez versões diferentes do mesmo comportamento e nenhuma forma de saber qual está correta.

Já o snippet específico do cliente (o botão de WhatsApp com o número dele, o cálculo de frete daquela loja, o campo extra daquele formulário) não deve ser replicado. Ele mora só naquele site. Misturar os dois tipos no mesmo plugin é o que faz uma migração de site levar o código de outro cliente junto.

Uma forma de separar sem complicar: use dois plugins de snippets, um chamado de “infra” e outro de “cliente”. O de infra recebe as mesmas regras em todos os sites. O de cliente muda de site para site. Quando você clona um site para outro servidor, sabe exatamente qual dos dois precisa ser revisado. Esse cuidado aparece também em clonar site WordPress para outro servidor sem erro de URL, porque o clone leva o banco junto, e o banco leva os snippets.

O que fazer com as revisões acumuladas

Enquanto você organiza o código, o banco acumula revisões. Cada vez que alguém salva um post no editor, o WordPress grava uma cópia em wp_posts com o status inherit. Em sites com muitos editores, isso vira milhares de linhas em pouco tempo.

O problema não é só o tamanho do banco. Revisões demais deixam consultas mais lentas, backups maiores e restaurações mais demoradas. Porém, apagar todas as revisões é um erro comum: você perde a capacidade de comparar versões antes de um rollback. Se um post foi alterado por engano, a revisão é o que permite voltar ao texto anterior sem restaurar o backup inteiro.

A política que costuma funcionar é podar, não zerar. Mantenha as últimas revisões de cada post e descarte as mais antigas. O WordPress permite limitar isso no wp-config.php com a constante WP_POST_REVISIONS. Definir um número (por exemplo, 5) faz o WordPress manter apenas as últimas cinco revisões de cada post e descartar automaticamente as anteriores. Definir como false desliga as revisões por completo, e isso você não quer em site de cliente.

Vale conferir a documentação oficial sobre constantes do wp-config.php antes de mexer, porque a constante precisa ser declarada antes da linha que pede o wp-settings.php.

Se o site já tem milhares de revisões acumuladas, limitar a constante não apaga o que já existe. Nesse caso, é preciso uma limpeza pontual. Faça backup do banco antes. A limpeza pode ser feita por plugin ou por SQL, sempre com o site em manutenção e sem editores conectados.

Como diagnosticar o que está solto no site

Antes de mover qualquer coisa, descubra o que já existe. O roteiro abaixo serve para um site e pode ser repetido nos outros.

1. Abra o functions.php do tema ativo e do child theme. Anote todo trecho que não veio do tema original.
2. Liste os plugins de snippets instalados e veja quais estão ativos. Snippet em plugin desativado não roda.
3. Procure por código no wp-config.php que não seja credencial de banco ou constante padrão.
4. Verifique se há um mu-plugins com arquivos próprios. Esse diretório carrega antes de tudo e é fácil de esquecer.
5. Conte as revisões do banco para saber se o problema é real ou imaginário.

Para contar revisões sem instalar nada, uma consulta simples no banco resolve:

SELECT post_type, COUNT(*) FROM wp_posts WHERE post_type = 'revision' GROUP BY post_type;

Se o número for baixo, não há o que limpar. Se for alto, você tem uma decisão a tomar. Em sites com muitos plugins, essa investigação se parece com o que se faz em profiler de plugins WordPress: medir antes de mexer, para não atribuir ao snippet um problema que é de outra coisa.

Passo a passo para organizar snippets em vários sites

A ordem abaixo evita que você perca código no meio do caminho.

1. Faça backup completo do site (arquivos e banco). Sem isso, não comece.
2. Instale um plugin de snippets e crie duas categorias: infra e cliente.
3. Copie para o plugin de snippets todo código de regra de negócio que hoje está no functions.php.
4. Deixe no child theme apenas o que é visual ou depende do tema.
5. Teste o site em uma janela anônima e, se possível, em um ambiente de staging.
6. Ative os snippets um a um, não todos de uma vez. Se o site cair, você sabe qual foi o culpado.
7. Registre em um documento o que cada snippet faz e em quais sites ele está ativo.
8. Defina WP_POST_REVISIONS como um número (5 é um ponto de partida razoável) em todos os sites.
9. Faça a limpeza pontual das revisões antigas nos sites que já acumularam muitas.

O passo 6 é o mais ignorado e o mais importante. Snippet que derruba o site geralmente tem erro de sintaxe ou conflito com outro snippet. Ativar um por vez transforma um site fora do ar em um snippet desativado.

Quando NÃO usar plugin de snippets

Plugin de snippets não é resposta para tudo. Existem casos em que ele atrapalha:

• Código que precisa rodar antes do WordPress carregar (mu-plugins é o lugar certo).
• Alteração estrutural de tema, como registrar um tipo de post ou um tamanho de imagem que o tema usa. Isso pertence ao child theme.
• Site com restrição de plugins por política de segurança. Nesse caso, o child theme é o caminho, mesmo com a desvantagem de depender do tema.
• Código que só faz sentido durante uma migração e será removido depois. Colocar em plugin e esquecer é como criar dívida técnica.

Por isso, a pergunta não é “qual é o melhor lugar”, e sim “o que precisa sobreviver à próxima atualização e o que precisa ser removido depois”.

Erros comuns

Os tropeços que mais aparecem na manutenção de vários sites:

• Editar o functions.php do tema pai e perder tudo na atualização seguinte.
• Apagar todas as revisões e descobrir depois que não há como comparar versões.
• Replicar snippet de cliente para todos os sites por engano.
• Ativar vários snippets novos de uma vez e não saber qual quebrou o site.
• Não versionar os snippets de infraestrutura, deixando cada site com uma versão diferente.
• Confundir lentidão causada por revisões com lentidão causada por plugin pesado.

Prevenção

Duas rotinas resolvem a maior parte do problema. A primeira é revisar os snippets a cada atualização de tema ou de plugin relevante: um snippet que funcionava pode conflitar com a nova versão. A segunda é manter um inventário do que está ativo em cada site, com data e responsável.

Se você administra muitos sites, esse inventário manual não escala. É aí que um painel de gestão ajuda: o 100% WP centraliza atualizações, backups e monitoramento, e evita que você descubra um snippet quebrado só quando o cliente reclama. Vale lembrar que a limpeza de revisões mexe no banco: antes de rodar em vários sites, garanta que o backup está em dia, como se faz em como manter vários sites WordPress atualizados.

Quando chamar alguém

Se o snippet mexe em checkout, área de membros, permissões de usuário ou qualquer fluxo que envolva dinheiro, e você não tem certeza do que ele faz, chame quem escreveu o código ou um desenvolvedor. O risco de um snippet mal colocado em site de cliente não é o site cair por uma hora: é uma transação perdida ou um dado vazado sem ninguém perceber.

O mesmo vale para limpeza de revisões em banco grande. Se o site tem anos de conteúdo e não há backup recente, a limpeza pode virar uma restauração de emergência. Nesse cenário, o caminho mais seguro é contratar alguém para fazer a limpeza com o site em manutenção e backup validado.