Você já sentiu aquele arrepio na nuca quando o banco de dados começa a chiar? Não me refiro ao som do cooler, mas à sensação de que algo está podre no reino do WordPress. Durante um ano, ignorei os alertas. Até que uma sexta-feira à noite, um site headless de uma fintech caiu — não por tráfego, mas por um conflito silencioso entre uma licença GPL v2 mal interpretada e uma tabela wp_options inflada como um balão de gás hélio. Esse é o Dossiê Investigativo que ninguém quer escrever.
O Cenário: Headless WP e a Ilusão de Leveza
Headless WordPress é sexy. Mas se engana quem pensa que o backend fica leve. Num setup headless típico, o front-end em React ou Vue consome a REST API, enquanto o back-end continua sendo o WordPress clássico — com todas as suas tabelas, plugins e temas. O problema? O banco de dados não sabe que você ‘cortou a cabeça’. Ele continua acumulando lixo: rascunhos automáticos, revisões, transientes expirados e, o pior de tudo, dados de plugins mal-educados.
No caso da fintech, o banco tinha 3GB de transients. Três. Gigabytes. A causa? Um plugin de cache que, ao ser desativado, deixou milhares de registros órfãos na tabela wp_options. A cada requisição REST, o WordPress carregava aquela tabela inteira na memória. O Core Web Vitals? LCP de 8 segundos. CLS de 0.5. Tudo no vermelho.
O Vilão Esquecido: A Licença GPL v2 e o ‘Plugin Fantasma’
Aqui entra o paradoxo. O plugin em questão era distribuído sob GPL v2, mas uma modificação interna (uma ‘feature’ para compatibilidade com headless) quebrou a licença. O desenvolvedor, que se achava esperto, removeu o aviso de copyright e redistribuiu como ‘derivado’. O que ele não sabia: ao alterar o plugin e manter a GPL, a obrigação de manter o código aberto é uma via de mão dupla. A versão modificada deixou de ser atualizada, criando um fork morto. O plugin fantasma continuou rodando, gerando transients a cada hora. O banco de dados inchou. O Core Web Vitals despencou.
Mas o pior não foi o desempenho. Foi a corrupção silenciosa: a tabela wp_postmeta começou a ter conflitos de chave única, gerando erros Duplicate entry que o WordPress engolia com um simples log. Nenhum administrador via. Apenas o banco sofria.
A Micro-Anedota de Bastidores
Numa auditoria noturna, já com o site em chamas, descobri que o plugin fantasma tinha um hooks em init que executava uma query SELECT * FROM wp_options WHERE option_name LIKE '_transient_%' a cada 5 minutos. O pior? Ele tinha um bug: a query não usava índice. O banco, um MySQL 5.7 singelo, começou a usar tablescan. O CPU foi a 100%. A REST API respondia em 12 segundos. O cliente, uma fintech que processava pagamentos, perdia clientes a cada segundo. O erro humano? Achar que plugin GPL é sempre seguro. Não é. Não quando a licença é quebrada e o código vira um frankenstein.
Estudo de Caso Reverso: O Erro que Salvou o Site
Vamos ao reverso. Em vez de otimizar o banco primeiro, decidi atacar a causa raiz: o plugin fantasma. Forcei sua desativação via WP-CLI (com wp plugin deactivate --all e reativei um por um). Detectei o culpado. Mas, ao reativar plugins legítimos, um detalhe me salvou: eu tinha um backup do banco de dados de 48 horas antes. Restaurei a tabela wp_options inteira, não apenas os transients. Resultado: 2.9GB perdidos. O site voltou a voar. LCP caiu para 1.8s.
A lição? Backup não é só segurança, é ferramenta de debug. E a segunda lição: Nunca subestime o poder de uma licença quebrada. Ela não é apenas uma questão legal; é uma bomba relógio para o Core Web Vitals.
Manifesto Técnico Contra a Poluição Silenciosa
Chega de tratar banco de dados como lixeira. Vamos às ações concretas:
- Auditoria de Plugins GPL: Antes de instalar qualquer plugin, verifique se ele é derivado de algum fork. Use
wp plugin list --field=namee compare com o repositório oficial. Se houver diferença de versão ou autor suspeito, investigue. - Limpeza Programada de Transientes: Crie um cron job que roda
DELETE FROM wp_options WHERE option_name LIKE '_transient_%' AND option_value IS NULLa cada 6 horas. Mas cuidado: muitos plugins usam transients para cache funcional. Teste antes. - Monitoramento de Índices: Use
SHOW INDEX FROM wp_optionse veja se há índice emoption_name. Se não houver, crie:ALTER TABLE wp_options ADD INDEX option_name (option_name). Isso pode reduzir o tempo de query de segundos para milissegundos. - Headless não é desculpa para sujeira: Configure a REST API para usar cache via
WP_Querycom parâmetros precisos. Eviteposts_per_page=-1e use paginação. O banco agradece.
E, acima de tudo, lembre-se: uma licença GPL v2 não é um passe livre para má qualidade. Ela é um contrato social. Quebrá-la não só fere a comunidade, mas também corrompe os dados que você jura proteger.
No fim daquela sexta-feira, o site da fintech voltou a operar. Mas o cheiro de queimado no banco de dados permaneceu. Até hoje, quando vejo um plugin suspeito, lembro da tabela wp_options gemendo. E você? Já verificou seus transients hoje?