Trabalho com WordPress há mais de 15 anos. Nesse período, vi o ecossistema crescer de uma ferramenta de publicação para uma plataforma capaz de sustentar e-commerce, APIs, áreas de membros, integrações e operações de negócio.
Também vi projetos falharem pelos mesmos motivos: responsabilidade demais em um plugin, dados sem estratégia de migração, tarefas pesadas na requisição e segurança tratada como etapa final.
Estas são algumas lições que continuo aplicando em produção.
1. WordPress não elimina arquitetura
Hooks tornam extensões fáceis, mas também facilitam acoplamento invisível. Quando tudo pode disparar tudo, fica difícil prever efeitos e testar comportamento.
Prefiro separar:
- integração com hooks;
- regras de negócio;
- acesso a dados;
- comunicação externa;
- apresentação no admin.
O callback do hook deve ser uma borda fina, não o sistema inteiro.
2. Dados próprios precisam de ciclo de vida
Antes de escolher options, post meta ou tabela própria, penso em volume, consulta, índices, retenção e remoção.
Uma tabela própria pode ser adequada para logs, filas e dados transacionais. Mas ela exige versionamento de schema, migração, índices, limpeza e comportamento de uninstall.
Criar a tabela é a parte fácil; operá-la por anos é a decisão real.
3. Cron não é relógio
WP-Cron depende de tráfego e pode atrasar. Para tarefas que precisam de horário confiável, uso cron do sistema chamando o WordPress ou uma fila adequada.
Além disso, jobs precisam ser idempotentes. Reexecutar uma tarefa não pode duplicar cobrança, envio ou importação.
4. Requisições externas precisam de limites
Integrações falham. APIs ficam lentas. DNS e TLS também falham.
Toda chamada externa deveria considerar:
- timeout explícito;
- retry controlado;
- tratamento de status;
- validação da resposta;
- cache quando fizer sentido;
- logs sem secrets;
- fallback para degradação segura.
Uma página não deveria ficar indisponível porque um serviço auxiliar demorou a responder.
5. Segurança começa na fronteira
Nonces ajudam contra CSRF, mas não substituem autorização. Sempre verifico capability, valido e normalizo entradas, escapo saídas no contexto correto e preparo queries com APIs seguras.
Em REST, permission_callback não é detalhe. Em webhooks, a assinatura precisa ser validada sobre o corpo bruto. Em uploads, tipo declarado não é prova do conteúdo.
6. Performance exige medição
Instalar cache sem localizar o gargalo pode apenas esconder o problema.
Eu começo observando:
- queries repetidas ou sem índice;
- autoload excessivo em options;
- chamadas externas no caminho crítico;
- hooks executados em todas as páginas;
- assets carregados onde não são usados;
- tarefas que deveriam estar em background.
Só depois escolho cache de objeto, página, CDN ou outra camada.
7. Atualização é parte do produto
Um plugin profissional precisa sobreviver à próxima versão. Isso envolve compatibilidade, migrações repetíveis, rollback possível, testes e comunicação de mudanças.
Evito alterações destrutivas na ativação e mantenho a versão do schema separada da versão do plugin quando os ciclos forem diferentes.
8. Observabilidade reduz suporte
Logs úteis respondem o que aconteceu, quando, em qual contexto e com qual identificador de correlação. Eles não devem expor tokens, senhas ou payloads pessoais por conveniência.
Um status de integração, última execução e erro acionável no admin pode economizar horas de suporte.
9. Menos dependências, mais clareza
Nem todo plugin precisa de um framework interno. Dependências aumentam superfície de conflito, atualização e distribuição.
Uso abstrações quando existe variação real, não para antecipar um futuro imaginário.
10. O contexto do negócio decide
WordPress pode ser CMS, backend, plataforma de conteúdo ou núcleo de e-commerce. A arquitetura correta depende de tráfego, equipe, risco e vida útil.
O objetivo não é provar que WordPress faz tudo. É saber quando ele oferece a melhor relação entre velocidade, controle e operação — e quando outro desenho seria mais honesto.
Depois de tantos anos, minha principal lição é simples: WordPress não é “só instalar plugins”. Em produção, ele merece a mesma disciplina de engenharia aplicada a qualquer sistema importante.
Qual problema de WordPress em produção mais ensinou você?