Optistream combinou doze plugins personalizados do WordPress em uma única base de código sem perder o SEO de nenhuma de suas mil páginas públicas.

Por que a fusão foi importante

Um site típico de WordPress acaba com um punhado de plugins; um maior parece uma oficina cheia de cabos, cada um zumbindo, mas nenhum fácil de desconectar. O site da Optistream executava doze plugins sob medida que gerenciavam perfis de streamers, equipes de esports e dados de jogos. Esses plugins geravam mil páginas indexáveis. Manter essas URLs intactas era inegociável — qualquer mudança teria arruinado a migração.

Como era a configuração antiga

Os doze plugins viviam em suas próprias pastas, cada um registrava seu próprio custom post type e se conectava ao WordPress em diferentes pontos. Os problemas se acumularam:

  • Hooks e assets estavam espalhados, dificultando a previsão de qual código era executado e quando.
  • A lógica de roteamento residia em muitos arquivos separados, de modo que uma única URL poderia ser afetada por vários plugins.
  • Arquivos CSS eram carregados em uma ordem imprevisível, levando a conflitos de estilo.
  • A depuração exigia a abertura de doze diretórios diferentes, uma perda de tempo para qualquer desenvolvedor.

O objetivo não era reduzir o número de arquivos; era dar a todo o sistema um ciclo de vida único e um único lugar para gerenciar dependências.

Como a migração foi planejada

A equipe tratou a interface pública — URLs, templates e metadados — como um contrato que não poderia ser quebrado. Qualquer mudança no front-end seria considerada uma falha. Com essa regra em mente, eles elaboraram um checklist para ser executado após cada etapa.

1. Listar os contratos públicos

Cada caminho de URL foi anotado com seu post type, rewrite slug, arquivo de template e as meta keys das quais dependia. Esta planilha tornou-se o manual de regras: se uma URL mudasse após a movimentação de um módulo, a migração era revertida.

2. Construir um loader simples

Um pequeno arquivo de bootstrap foi criado. Cada antigo plugin agora registra um único “content domain” por meio de um nome de função previsível. O loader não faz nada de complexo — apenas o suficiente para puxar o módulo correto para o WordPress quando necessário. A simplicidade torna as falhas óbvias.

3. Proteger os dados

Renomear as meta keys teria transformado uma mudança de código em uma migração de dados, adicionando um risco desnecessário. As chaves antigas permaneceram intactas; novas funções auxiliares (helper functions) as envolvem, mantendo o esquema do banco de dados estável.

4. Corrigir a propriedade do CSS

Os conflitos de estilo foram resolvidos com três medidas:

  • Arquivos CSS dos módulos são enqueued com alta prioridade para que sejam carregados por último.
  • Todos os seletores são limitados (scoped) a uma classe wrapper única para cada módulo.
  • filemtime() é usado ao fazer o enqueue para invalidar o cache do navegador caso uma folha de estilo mude.

5. Usar um loop seguro

A migração prosseguiu um módulo por vez. Após mover um módulo, a equipe verificou o registro do post-type, o roteamento e o layout mobile antes de tocar no próximo. Os plugins originais permaneceram instalados, mas inativos, proporcionando um caminho de rollback instantâneo.

Checklist de produção

Após cada troca de módulo, a equipe verificou:

  • Cada URL de tipo de conteúdo retorna um status HTTP 200.
  • O cabeçalho da URL canônica corresponde à URL original.
  • Títulos de página e meta descriptions permanecem inalterados.
  • Todas as imagens carregam sem links quebrados.
  • Nenhum overflow horizontal aparece em telas de dispositivos móveis.
  • O console do navegador não mostra erros de JavaScript ou CSS.

Somente quando o checklist foi aprovado, a equipe desativou o plugin antigo permanentemente.

O que o novo plugin entrega

O plugin único resultante não reduz a base de código; ele simplesmente torna os limites visíveis. Todas as doze áreas funcionais agora compartilham um único ciclo de vida, um conjunto de hooks e um único lugar para gerenciar dependências. O novo plugin não tornou o sistema menor. Ele tornou os limites visíveis. Isso se mostrou mais útil do que ter menos plugins.

Riscos e contra-argumentos

O caso da Optistream mostra que uma abordagem disciplinada de "contract-first" e um rollout passo a passo podem manter os riscos sob controle.

O que observar a seguir

Se você está considerando uma consolidação semelhante, comece com estes dois pilares:

  1. Estabilidade de URL – mapeie cada caminho público antes de escrever uma linha de código.
  2. Estabilidade de dados – evite renomear campos do banco de dados, a menos que esteja preparado para uma migração completa.

A partir daí, construa um loader minúsculo, mantenha o CSS com escopo (scoped) e mova os módulos um por um enquanto executa um checklist de produção rigoroso.