{"id":862,"date":"2026-09-19T17:00:44","date_gmt":"2026-09-19T17:00:44","guid":{"rendered":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/cms\/snippets-wordpress-guardar-codigo-limpar-revisoes-varios-sites\/"},"modified":"2026-09-19T17:00:45","modified_gmt":"2026-09-19T17:00:45","slug":"snippets-wordpress-guardar-codigo-limpar-revisoes-varios-sites","status":"publish","type":"post","link":"https:\/\/100porcentowp.com.br\/central-de-ajuda\/manutencao\/snippets-wordpress-guardar-codigo-limpar-revisoes-varios-sites\/","title":{"rendered":"Snippets WordPress: onde guardar c\u00f3digo e limpar revis\u00f5es em v\u00e1rios sites"},"content":{"rendered":"

Voc\u00ea atualiza o tema pela manh\u00e3 e, \u00e0 tarde, o site do cliente perdeu o bot\u00e3o de WhatsApp, o filtro do WooCommerce e aquele ajuste de checkout. O c\u00f3digo estava no functions.php<\/code> do tema pai. Snippets WordPress guardados no lugar errado n\u00e3o s\u00e3o um problema de organiza\u00e7\u00e3o: s\u00e3o uma promessa de que a pr\u00f3xima atualiza\u00e7\u00e3o vai apagar o que voc\u00ea escreveu. E quando isso acontece em um site s\u00f3, \u00e9 chato; quando acontece em dez, \u00e9 uma tarde inteira reconstruindo o que j\u00e1 estava funcionando.<\/p>\n

Este artigo trata das duas pontas que se cruzam na manuten\u00e7\u00e3o de v\u00e1rios sites: onde cada snippet deve morar e o que fazer com as revis\u00f5es que se acumulam no banco. A ordem de decis\u00e3o importa mais que a ferramenta.<\/p>\n

Onde cada snippet deve morar<\/h2>\n

Antes de escolher o plugin, responda a uma pergunta: esse c\u00f3digo \u00e9 do site ou do cliente? A resposta define o lugar.<\/p>\n

Existem tr\u00eas lugares poss\u00edveis para c\u00f3digo solto no WordPress, e cada um tem um comportamento diferente diante de atualiza\u00e7\u00f5es:<\/p>\n\n\n\n\n\n\n\n
Local<\/th>\nSobrevive \u00e0 atualiza\u00e7\u00e3o do tema?<\/th>\nIdeal para<\/th>\nRisco principal<\/th>\n<\/tr>\n<\/thead>\n
functions.php<\/code> do tema pai<\/td>\nN\u00e3o, \u00e9 sobrescrito<\/td>\nNada em produ\u00e7\u00e3o<\/td>\nPerda de c\u00f3digo e de funcionalidade<\/td>\n<\/tr>\n
functions.php<\/code> do child theme<\/td>\nSim<\/td>\nC\u00f3digo ligado \u00e0 apresenta\u00e7\u00e3o e ao tema<\/td>\nSe o child theme for trocado, o c\u00f3digo vai junto<\/td>\n<\/tr>\n
Plugin de snippets<\/td>\nSim, independente do tema<\/td>\nRegras de neg\u00f3cio, integra\u00e7\u00f5es, ajustes de plugin<\/td>\nErro de sintaxe pode derrubar o site inteiro<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Na pr\u00e1tica, a divis\u00e3o que funciona \u00e9 esta: c\u00f3digo que s\u00f3 faz sentido com aquele tema (tamanhos de imagem, remover suporte a blocos, ajustar um template) vai no child theme. C\u00f3digo que \u00e9 regra do site (redirecionamento, filtro de pre\u00e7o, integra\u00e7\u00e3o com CRM, ajuste de checkout) vai em um plugin de snippets. C\u00f3digo de infraestrutura, que precisa ser id\u00eantico em todos os sites, tamb\u00e9m vai em plugin de snippets, porque assim ele sobrevive \u00e0 troca de tema.<\/p>\n

O motivo \u00e9 simples: o child theme depende do tema pai. Se o cliente decide trocar de tema no ano que vem, o child theme inteiro \u00e9 descartado, e o snippet vai embora com ele. O plugin de snippets n\u00e3o tem essa depend\u00eancia.<\/p>\n

Snippets WordPress que precisam ser id\u00eanticos em todos os sites<\/h2>\n

Quem administra v\u00e1rios sites costuma repetir um conjunto de snippets em todos eles. Alguns exemplos comuns: desabilitar a edi\u00e7\u00e3o de arquivos pelo painel, limitar revis\u00f5es, desativar XML-RPC, remover a meta generator, ajustar o intervalo do WP-Cron.<\/p>\n

Esse conjunto \u00e9 o seu padr\u00e3o de infraestrutura. Ele deve ser versionado fora do WordPress, em um reposit\u00f3rio ou em um arquivo de texto com o c\u00f3digo e a data da \u00faltima altera\u00e7\u00e3o. Se um snippet de infraestrutura muda, ele muda em todos os sites ao mesmo tempo, ou voc\u00ea vai ter dez vers\u00f5es diferentes do mesmo comportamento e nenhuma forma de saber qual est\u00e1 correta.<\/p>\n

J\u00e1 o snippet espec\u00edfico do cliente (o bot\u00e3o de WhatsApp com o n\u00famero dele, o c\u00e1lculo de frete daquela loja, o campo extra daquele formul\u00e1rio) n\u00e3o deve ser replicado. Ele mora s\u00f3 naquele site. Misturar os dois tipos no mesmo plugin \u00e9 o que faz uma migra\u00e7\u00e3o de site levar o c\u00f3digo de outro cliente junto.<\/p>\n

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\u00ea clona um site para outro servidor, sabe exatamente qual dos dois precisa ser revisado. Esse cuidado aparece tamb\u00e9m em clonar site WordPress para outro servidor sem erro de URL<\/a>, porque o clone leva o banco junto, e o banco leva os snippets.<\/p>\n

O que fazer com as revis\u00f5es acumuladas<\/h2>\n

Enquanto voc\u00ea organiza o c\u00f3digo, o banco acumula revis\u00f5es. Cada vez que algu\u00e9m salva um post no editor, o WordPress grava uma c\u00f3pia em wp_posts<\/code> com o status inherit<\/code>. Em sites com muitos editores, isso vira milhares de linhas em pouco tempo.<\/p>\n

O problema n\u00e3o \u00e9 s\u00f3 o tamanho do banco. Revis\u00f5es demais deixam consultas mais lentas, backups maiores e restaura\u00e7\u00f5es mais demoradas. Por\u00e9m, apagar todas as revis\u00f5es \u00e9 um erro comum: voc\u00ea perde a capacidade de comparar vers\u00f5es antes de um rollback. Se um post foi alterado por engano, a revis\u00e3o \u00e9 o que permite voltar ao texto anterior sem restaurar o backup inteiro.<\/p>\n

A pol\u00edtica que costuma funcionar \u00e9 podar, n\u00e3o zerar. Mantenha as \u00faltimas revis\u00f5es de cada post e descarte as mais antigas. O WordPress permite limitar isso no wp-config.php<\/code> com a constante WP_POST_REVISIONS<\/code>. Definir um n\u00famero (por exemplo, 5) faz o WordPress manter apenas as \u00faltimas cinco revis\u00f5es de cada post e descartar automaticamente as anteriores. Definir como false<\/code> desliga as revis\u00f5es por completo, e isso voc\u00ea n\u00e3o quer em site de cliente.<\/p>\n

Vale conferir a documenta\u00e7\u00e3o oficial sobre constantes do wp-config.php<\/a> antes de mexer, porque a constante precisa ser declarada antes da linha que pede o wp-settings.php<\/code>.<\/p>\n

Se o site j\u00e1 tem milhares de revis\u00f5es acumuladas, limitar a constante n\u00e3o apaga o que j\u00e1 existe. Nesse caso, \u00e9 preciso uma limpeza pontual. Fa\u00e7a backup do banco antes. A limpeza pode ser feita por plugin ou por SQL, sempre com o site em manuten\u00e7\u00e3o e sem editores conectados.<\/p>\n

Como diagnosticar o que est\u00e1 solto no site<\/h2>\n

Antes de mover qualquer coisa, descubra o que j\u00e1 existe. O roteiro abaixo serve para um site e pode ser repetido nos outros.<\/p>\n

    \n
  1. Abra o functions.php<\/code> do tema ativo e do child theme. Anote todo trecho que n\u00e3o veio do tema original.<\/li>\n
  2. Liste os plugins de snippets instalados e veja quais est\u00e3o ativos. Snippet em plugin desativado n\u00e3o roda.<\/li>\n
  3. Procure por c\u00f3digo no wp-config.php<\/code> que n\u00e3o seja credencial de banco ou constante padr\u00e3o.<\/li>\n
  4. Verifique se h\u00e1 um mu-plugins<\/code> com arquivos pr\u00f3prios. Esse diret\u00f3rio carrega antes de tudo e \u00e9 f\u00e1cil de esquecer.<\/li>\n
  5. Conte as revis\u00f5es do banco para saber se o problema \u00e9 real ou imagin\u00e1rio.<\/li>\n<\/ol>\n

    Para contar revis\u00f5es sem instalar nada, uma consulta simples no banco resolve:<\/p>\n

    SELECT post_type, COUNT(*) FROM wp_posts WHERE post_type = 'revision' GROUP BY post_type;<\/code><\/p>\n

    Se o n\u00famero for baixo, n\u00e3o h\u00e1 o que limpar. Se for alto, voc\u00ea tem uma decis\u00e3o a tomar. Em sites com muitos plugins, essa investiga\u00e7\u00e3o se parece com o que se faz em profiler de plugins WordPress<\/a>: medir antes de mexer, para n\u00e3o atribuir ao snippet um problema que \u00e9 de outra coisa.<\/p>\n

    Passo a passo para organizar snippets em v\u00e1rios sites<\/h2>\n

    A ordem abaixo evita que voc\u00ea perca c\u00f3digo no meio do caminho.<\/p>\n

      \n
    1. Fa\u00e7a backup completo do site (arquivos e banco). Sem isso, n\u00e3o comece.<\/li>\n
    2. Instale um plugin de snippets e crie duas categorias: infra e cliente.<\/li>\n
    3. Copie para o plugin de snippets todo c\u00f3digo de regra de neg\u00f3cio que hoje est\u00e1 no functions.php<\/code>.<\/li>\n
    4. Deixe no child theme apenas o que \u00e9 visual ou depende do tema.<\/li>\n
    5. Teste o site em uma janela an\u00f4nima e, se poss\u00edvel, em um ambiente de staging.<\/li>\n
    6. Ative os snippets um a um, n\u00e3o todos de uma vez. Se o site cair, voc\u00ea sabe qual foi o culpado.<\/li>\n
    7. Registre em um documento o que cada snippet faz e em quais sites ele est\u00e1 ativo.<\/li>\n
    8. Defina WP_POST_REVISIONS<\/code> como um n\u00famero (5 \u00e9 um ponto de partida razo\u00e1vel) em todos os sites.<\/li>\n
    9. Fa\u00e7a a limpeza pontual das revis\u00f5es antigas nos sites que j\u00e1 acumularam muitas.<\/li>\n<\/ol>\n

      O passo 6 \u00e9 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.<\/p>\n

      Quando N\u00c3O usar plugin de snippets<\/h2>\n

      Plugin de snippets n\u00e3o \u00e9 resposta para tudo. Existem casos em que ele atrapalha:<\/p>\n