Quando NÃO usar o WordPress Multisite (e o que usar em vez disso)

O WordPress Multisite parece a resposta óbvia na primeira vez que você está olhando para dez instalações de clientes e dez ciclos de atualização. Um dashboard, um login, um lugar para gerenciar tudo. A proposta é clara.

O problema aparece depois, geralmente no pior momento possível: uma atualização de plugin derruba todos os sites de clientes de uma só vez, ou um cliente pede para levar seu site para outro lugar e você percebe que a extração é um projeto de fim de semana. O Multisite é otimizado para uma rede que atua como uma só. A maior parte do trabalho com clientes é o oposto: proprietários separados, necessidades separadas, saídas separadas.

Aqui estão as situações específicas em que o Multisite é a escolha errada, o que quebra em cada uma delas e o setup focado em isolamento que evita o problema.

1. Quando cada cliente precisa de uma stack de plugins e temas diferente

O Multisite compartilha um diretório wp-content entre todos os subsites. Os plugins são instalados em toda a rede e, em seguida, ativados na rede ou habilitados por site, mas todos vivem nos mesmos arquivos e carregam do mesmo lugar. Um plugin que um cliente precisa e que outro cliente nunca deve rodar, ainda fica na codebase compartilhada por ambos.

Essa restrição luta contra você constantemente no trabalho com clientes, onde o ponto principal é que o Cliente A recebe um plugin de agendamentos, o Cliente B recebe uma stack de membros, e nenhum deve herdar a bagagem ou a superfície de ataque do outro.

A alternativa: isolamento verdadeiro por tenant. O GrabWP Tenancy Pro dá a cada tenant seu próprio diretório wp-content, para que os temas e plugins sejam genuinamente separados por cliente em vez de compartilhados e alternados. O conjunto de plugins de um cliente não tem impacto sobre o de outro.

2. Quando um cliente pode ir embora algum dia

Esse é o ponto que silenciosamente custa mais caro. No Multisite, o site de um único cliente está emaranhado no database da rede com tabelas compartilhadas e IDs de blog. Retirar um subsite para entregar a um cliente, ou para mover para o seu próprio hosting, é um trabalho de exportação e cirurgia de várias etapas, e as ferramentas de exportação do Multisite são famosas por serem frágeis.

Se qualquer parte do seu negócio envolve finalizar um site e entregá-lo, o Multisite construiu um lock-in que você terá que combater todas as vezes.

A alternativa: exportação limpa por tenant. O GrabWP Tenancy Pro faz backup de um tenant individual como um arquivo autossuficiente, e o plugin gratuito GrabWP Restore reconstrói esse tenant como um site WordPress autônomo completo em qualquer host. O Restore transmite a importação do database, reescreve os prefixos de tabela para corresponder ao destino e executa uma busca e substituição de URL (search-and-replace) em todo o database que lida corretamente com dados serializados, atualizando automaticamente a URL do site em seguida. O cliente vai embora com uma instalação normal do WordPress e sem dependência de você.

3. Quando o problema de um cliente não deve se tornar o problema de todos

O Multisite é uma arquitetura de shared-fate (destino compartilhado) por design. Um database, uma árvore de arquivos, um core. Uma atualização ruim de plugin, uma tabela corrompida ou um subsite comprometido não estão contidos: eles ficam dentro do mesmo database e sistema de arquivos que todos os outros clientes. Não há um blast radius natural em torno de um único site.

Para uma rede de hobby, essa é uma troca aceitável. Para um conjunto de clientes, cada um pagando por seu próprio uptime, é um liability que você está carregando em nome deles.

A alternativa: databases dedicados e pontos de restore por tenant. O GrabWP Tenancy Pro permite que cada tenant rode em um prefixo MySQL compartilhado, um database MySQL totalmente dedicado ou seu próprio database SQLite, para que os dados do tenant possam ser completamente separados com zero tabelas compartilhadas. Seu fluxo de trabalho de restore por tenant em 8 etapas reverte o site de um cliente a partir do próprio backup desse cliente sem tocar em nenhum outro tenant. O dia ruim de um site continua sendo o dia ruim de apenas um site.

4. Quando o seu host torna o Multisite doloroso (ou o proíbe)

Muitos hosts de WordPress gerenciado não suportam Multisite, o restringem ou cobram mais por ele. Mesmo onde ele roda, o Multisite baseado em subdomínio traz wildcard DNS e configuração de SSL que transformam uma tarefa de cinco minutos em um ticket de suporte.

A alternativa: roteamento que não precisa de ginástica de DNS. O GrabWP Tenancy suporta domínios personalizados completos por tenant e roteamento baseado em caminho (path-based routing), onde um tenant fica em yoursite.com/site/client-a sem nenhuma alteração de DNS por cliente. Você obtém hospedagem multi-site em um hosting single-site comum.

5. Quando você realmente só quer a eficiência de uma única instalação sem o acoplamento

O verdadeiro motivo pelo qual as pessoas buscam o Multisite não são os recursos de rede. É que elas não querem atualizar o core do WordPress dez vezes. Esse é um objetivo legítimo, mas o Multisite o agrupa com databases compartilhados, plugins compartilhados e um offboarding doloroso que você nunca pediu.

A alternativa: separe os dois. O multi-tenancy oferece a vantagem de gerenciamento de uma única instalação, atualize o core uma vez, um dashboard, clone um tenant inicial para cada novo cliente, enquanto mantém o isolamento de instalações separadas. Você ganha a eficiência sem o acoplamento.

Multisite vs instalações separadas vs multi-tenancy, em resumo

	WordPress Multisite	Instalações separadas	GrabWP Tenancy
Atualizações do core	Uma vez	Por instalação	Uma vez
Isolamento de dados	DB compartilhado (prefixo + ID do blog)	Completo	Completo com o Pro (DB dedicado)
Plugins/temas por cliente	wp-content compartilhado	Total	Total com o Pro (wp-content isolado)
Offboarding de clientes	Extração complexa	Simples	Simples (exportação do Pro + Restore gratuito)
Blast radius de uma falha	Todos os sites	Um site	Um site
Requisitos de hosting	Frequentemente restritos	Padrão	Padrão (roteamento por caminho ou domínio)

Então, quando o Multisite é a escolha certa?

Para ser justo: o Multisite é uma boa opção quando a rede genuinamente se comporta como uma única coisa. Uma universidade rodando dezenas de sites de departamentos em um conjunto compartilhado de temas e plugins, uma empresa de mídia rodando edições regionais da mesma publicação, uma intranet interna de sites quase idênticos sob uma equipe de TI. Branding compartilhado, stack compartilhada, um único proprietário administrativo, baixo churn. Se isso descreve você, o Multisite está fazendo exatamente o que foi construído para fazer.

O trabalho com clientes quase nunca é isso. Clientes diferentes querem plugins diferentes, são donos de seus próprios dados e, eventualmente, vão embora. No momento em que a afirmação “esses sites são empresas realmente separadas que por acaso eu gerencio juntas” for verdade, a arquitetura compartilhada do Multisite estará trabalhando contra você.

O setup que a maioria dos freelancers e agências realmente deseja

Para gerenciar vários sites independentes de clientes, o multi-tenancy atinge o meio-termo que o Multisite e as instalações separadas não alcançam: gerenciamento centralizado como o Multisite, isolamento genuíno como instalações separadas e uma saída limpa para qualquer cliente a qualquer momento.

O plugin base GrabWP Tenancy é gratuito e oferece uploads isolados, prefixos de tabela e roteamento por domínio ou caminho. O plano Pro adiciona databases dedicados, wp-content por tenant e backup e restore por tenant a partir de $9.99/month.

Se você quiser o detalhamento arquitetônico completo, leia WordPress Multisite vs Multi-Tenancy. Se você está pronto para mover um site para fora de uma rede existente, veja como isolar sites de clientes WordPress sem Multisite.