Como simplificar as migrações multisite do WordPress com a migração MU

Migrar um site WordPress autônomo para um ambiente de rede de sites (ou “multisite”) é um esforço tedioso e complicado, o oposto também é verdadeiro. O WordPress Importer funciona razoavelmente bem para sites menores e mais simples, mas deixa espaço para melhorias. Ele exporta conteúdo, mas não dados de configuração do site, como configurações de widget e personalizador, plug-ins e configurações do site. O Importador também se esforça para lidar com uma grande quantidade de conteúdo. Neste artigo, você aprenderá a otimizar esse tipo de migração usando o MU-Migration, um plug-in WP-CLI.

Entendendo o Multisite

Um multisite do WordPress permite executar vários sites na mesma instalação do WordPress. É muitas vezes referido como “Rede Multisite”. O WordPress.com é provavelmente o maior exemplo de rede multisite, executando milhares de sites na mesma instância do WordPress.

Um multisite WordPress pode ser perfeito para vários casos de uso, alguns deles incluem:

• Seu cliente pode ter várias propriedades e pode fazer sentido consolidar todos os seus sites em uma instalação exclusiva do WordPress, compartilhando um único domínio, mas não limitado a ele.

• Depois de configurá-lo, é um processo simples e direto para criar novos sites e aproveitar temas e plugins já disponíveis na rede

Uma compreensão profunda de como o multisite funciona está além do escopo deste artigo, mas você pode conferir os seguintes links:

• “Crie uma rede”, Codex, WordPress.org

• “WordPress Multisite: Funções e métodos práticos”, Kevin Leary, Smashing Magazine

Entendendo os desafios

As diferenças entre a estrutura de um único site e um multisite WordPress são bastante razoáveis. Com multisite, cada subsite obtém seu próprio conjunto de tabelas de banco de dados, com exceção da tabela do usuário ( wp_user ) que é compartilhada em todos os sites. A maneira como isso funciona no WordPress é que cada conjunto de tabelas de subsite tem o ID do site adicionado a cada nome de tabela ( wp_X_posts , wp_X_postmeta , wp_X_options ).

Essa própria estrutura de banco de dados já apresenta algumas complexidades. Por exemplo, como você migraria um subsite de multisite para uma única instalação? Obviamente, você não pode simplesmente exportar e importar o banco de dados em uma única instalação — os nomes das tabelas são diferentes! Você precisaria renomear as tabelas no arquivo .sql exportado ou usar uma consulta ALTER TABLE SQL para renomear as tabelas após importá-las. O mesmo vale para o caminho oposto: se você estiver importando um único site para vários sites, os prefixos de tabela também terão que ser atualizados. Parece muito trabalho, certo?

A tabela do usuário em multisite é global, o que significa que você não pode simplesmente importar a tabela do usuário de seu único site, pois isso substituiria completamente a tabela do usuário global multisite. Se você estiver fazendo o inverso, extraindo um subsite do WordPress e importando para um único site, você estaria transportando todos os usuários da rede, mesmo aqueles que não pertencem ao subsite que está sendo migrado. Além disso, se migrar um subsite de um multisite para outro, a exportação da tabela do usuário está completamente fora da mesa.

A melhor solução é exportar os usuários separadamente, mas isso apresenta outro problema: quando os usuários são importados, eles obtêm IDs diferentes. Para resolver esse problema, é necessário acompanhar os ids do novo usuário, criar uma tabela de mapeamento e usar a tabela de mapeamento para atualizar todas as referências aos IDs dos usuários no WordPress! Mais uma vez, muito trabalho, certo?

Estes são apenas dois exemplos dos desafios que se podem enfrentar ao lidar com migrações como esta. Há várias outras coisas menores que também precisam ser cuidadas, como mover a pasta de uploads para o local apropriado, migrar os registros no banco de dados que fazem referência ao ID do site etc.

Conheça a MU-Migration

O MU-Migration é um plugin WP-CLI que criei enquanto trabalhava em várias migrações de clientes e, posteriormente, de código aberto por 10up. Ele foi concebido para agilizar o processo de mover sites de sites únicos do WordPress para uma instância multisite (ou vice-versa). Essencialmente, ele exporta tudo para um pacote ZIP que pode ser usado para importar o site na instalação desejada do WordPress.

Ele funciona exportando o conteúdo do site e, opcionalmente, temas, plugins e pastas de uploads em um pacote zip que pode ser facilmente importado para outra instalação do WordPress. Ao usar o MU-Migration, você não precisa se preocupar com os detalhes técnicos subjacentes da migração. Ele simplesmente cuidará de tudo isso para que você possa se concentrar no que é importante: entregar uma migração bem-sucedida para seus clientes.

Instalando WP-CLI e MU-Migration

Para usar o MU-Migration, primeiro você precisa instalar o WP-CLI, a ferramenta de linha de comando oficial do WordPress. Instalar o WP-CLI é tão simples quanto executar os comandos abaixo em seu servidor:

 $ curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar $ chmod +x wp-cli.phar $ sudo mv wp-cli.phar /usr/local/bin/wp

Depois de executar essas etapas, você poderá executar o WP-CLI digitando apenas wp em qualquer instalação do WordPress, desde que esteja dentro do diretório raiz do WordPress.

Por exemplo, na pasta de instalação do WordPress, tente executar o seguinte comando:

 $ wp theme status

É um comando simples e listará todos os temas disponíveis, destacando qual deles está ativo no momento.

Por fim, para instalar o MU-Migration, você pode usar o comando package install . Use o comando a seguir para baixar e instalar o MU-Migration como um plug-in WP-CLI.

 $ wp package install 10up/mu-migration

Executando uma migração simples

O uso do MU-Migration é bastante simples. Para nosso primeiro cenário, vamos mover um único site WordPress para uma instalação multisite do WordPress.

Exportando o Site Único

Começaremos exportando o site único. Para fazer isso, precisamos usar o comando export all :

 $ wp mu-migration export all single-site.zip --themes --plugins --uploads

O comando acima exportará todo o site para um pacote ZIP, os sinalizadores --themes , --plugins e --uploads são opcionais e incluirão o tema atual, todos os plugins e a pasta de uploads, respectivamente, na exportação. Dependendo do tamanho do seu site, pode levar algum tempo para concluir o processo, mas para a maioria dos sites, o processo de exportação não deve demorar mais do que alguns minutos.

Quando terminar, ele criará um arquivo chamado single-site.zip contendo todos os dados, temas e plugins do site, bem como o diretório de uploads. O próximo passo é movê-lo para o servidor onde reside o multisite do WordPress. Você pode usar seu cliente SFTP preferido ou uma solução mais robusta como rsync .

Importando o site único para o multisite

Com o arquivo exportado em seu servidor multisite, tudo que você precisa fazer é usar o comando import do diretório multisite do WordPress; escusado será dizer que o WP-CLI e o MU-Migration também precisam ser instalados no servidor de destino.

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site

O comando acima irá pegar o arquivo single-site.zip , extraí-lo e importar tudo para o multisite. Ele criará um novo subsite em sua rede. O parâmetro --new_url é opcional; ele instruirá o MU-Migration a realizar uma pesquisa e substituir para substituir todas as ocorrências do URL do site exportado pelo especificado. Este parâmetro é útil quando a migração inclui uma mudança de URL ou se você está importando localmente, ou mesmo em um ambiente de teste.

O processo de importação geralmente demora mais e depende do tamanho do site que você está importando, mas não tenha medo, o MU-Migration o manterá atualizado enquanto a migração é executada. Quando o processo terminar, o MU-Migration informará a URL final do seu site importado. É altamente recomendável liberar todas as camadas de cache que são executadas em seu servidor, especialmente Memcache ou Redis.

Executando novamente uma migração

Ao fazer migrações, é bastante comum fazer uma simulação primeiro com o objetivo de testar as coisas antes de executar a migração final, o que geralmente significa fazer outra exportação e reimportar na instalação multisite de destino. No entanto, observe que em nosso primeiro exemplo de migração, o MU-Migration criou um novo subsite dentro da rede para importar o site único sobre ele. Executar exatamente o mesmo comando novamente levaria à criação de outro subsite, o que não é exatamente o que esperávamos.

Felizmente, é possível especificar um blog_id , que informa ao MU-Migration para substituir o subsite pelo blog_id especificado. Por exemplo, vamos supor que o comando de importação anterior criou um subsite com 2 como ID e você deseja executar novamente a migração. Você poderia fazer o seguinte:

 $ wp mu-migration import all /path/to/single-site.zip --new_url=example.com/single-site --blog_id=2

Se você não conhece o blog_id , você pode obtê-lo através das configurações de administração de rede ou executando $ wp site list .

Extraindo um subsite de uma instalação multisite

O MU-Migration também suporta a extração de subsites de instalações multisite e a importação para outro multisite ou em um único site.

Para esses dois cenários, executaríamos o comando de exportação de uma instalação multisite e não de um único site; isso significa que precisamos de uma maneira de especificar qual subsite queremos exportar. Para isso, basta passar o parâmetro --blog_id para o comando export:

 $ wp mu-migration export all subsite-3.zip --themes --plugins --uploads --blog_id=3

Neste exemplo, estamos exportando um subsite com ID igual a 3; isso criará um arquivo ZIP que está pronto para ser importado para outro multisite ou em um único site. O comando para importar para um único site e multisite é exatamente o mesmo, o MU-Migration detectará se está sendo executado em multisite ou não e se ajustará a isso automaticamente. Em uma observação lateral, ao importar para outra instância multisite, você também pode especificar o parâmetro --blog_id para substituir um subsite existente.

 $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ] $ wp mu-migration import all /path/to/subsite-3.zip [--new_url= ] [--blog_id= ]

Dicas para executar grandes migrações

Embora os exemplos anteriores funcionem muito bem para migrações de pequeno a médio porte, a migração de sites grandes de ou para vários sites pode levar um tempo razoável. Nesta seção, compartilharei algumas lições aprendidas ao fazer várias migrações corporativas.

Criar um plano de migração

As migrações de dados geralmente são necessárias, mas são uma parte negligenciada de muitos projetos. As migrações podem ser complicadas e complicadas, mas, quando planejadas adequadamente, podem ser indolores. A criação de um plano de migração deve ser a primeira etapa de qualquer projeto de migração.

Um plano de migração típico inclui coisas como:

• O impacto da migração em qualquer processo editorial de produção (ou seja, congelamento de conteúdo, requisitos de migração diferenciados).

• Por quanto tempo a migração deve ser executada?

• Como os backups serão restaurados? Como uma migração com falha será tratada?

• Como o processo de exportação afetará o desempenho do site? Muitos sites não podem arcar com uma exportação de banco de dados durante os horários de pico.

Como regra geral, as migrações devem ser o mais simples possível e, idealmente, no dia do lançamento, todo o trabalho pesado já teria sido concluído e apenas as etapas estritamente necessárias devem ser executadas. Isso significa que você deve migrar tudo o que puder antes da data de lançamento real, pois isso lhe dará espaço para corrigir erros e controle de qualidade. Se for uma nova criação de site e você estiver migrando dados, muitas vezes você pode se beneficiar de uma janela de congelamento de conteúdo e mover seu conteúdo com antecedência. Você também pode usar estratégias para mover progressivamente seu conteúdo, se possível. Confira a próxima seção para ver um exemplo dessa técnica.

Embora muitas vezes negligenciado, um plano de migração adequado pode evitar uma ampla variedade de problemas em uma migração. Não deixe que circunstâncias inesperadas façam com que sua migração falhe, planeje com antecedência! Para uma discussão mais aprofundada sobre o planejamento de uma migração, recomendo que você confira a seção de migração das práticas recomendadas do 10up.

Use o Rsync para copiar progressivamente os uploads

A pasta de uploads de sites grandes pode ser extremamente grande, e compactá-la em um arquivo ZIP para extração posterior nem sempre é a melhor e mais rápida solução. Existem várias outras maneiras de copiar a pasta de uploads para o servidor de destino. Uma ferramenta comumente usada para migração corporativa é o rsync , que pode transferir arquivos entre servidores mais rapidamente do que usar uma solução SFTP padrão e, além disso, pode pausar e restaurar transferências. Ele mantém registros do que já foi transferido, o que significa que podemos sincronizar progressivamente nossos arquivos. Por exemplo, você pode começar a sincronizar os arquivos alguns dias antes da migração real para ganhar algum tempo. Então, no dia da migração, tudo o que você precisa fazer é sincronizar os arquivos para garantir que tudo o que foi adicionado desde a última sincronização seja transferido para o servidor de destino.

A única ressalva dessa abordagem é que você precisará mover manualmente os subdiretórios dos uploads para o lugar certo, pois o multisite tem uma estrutura ligeiramente diferente para a pasta de uploads: cada site obtém sua própria subpasta onde seu nome é o ID do site .

Como exemplo final, vamos ver como podemos migrar um único site grande para uma instância multisite. Começaremos exportando o site único para um pacote ZIP e executando um teste de simulação no servidor de destino. Nesse ponto, o site não estaria acessível a ninguém, pois o domínio ainda está apontando para o servidor antigo, o que significa que você pode apontar com segurança o arquivo do seu host para o novo servidor para testar a migração. Você também pode ativar um plug-in como Restringir acesso ao site no site de destino para garantir que ele não seja acessível publicamente de forma alguma.

Para nosso teste de simulação, exportamos o site alguns dias ou semanas antes da data de migração planejada para testar e ter uma noção de quanto tempo o processo levará. Observe que a pasta de uploads não está incluída.

Faça um teste a seco primeiro

Sempre faça um dry-run primeiro. Idealmente, uma simulação deve acontecer no servidor real ou em um ambiente de teste com uma pilha de servidores semelhante.

Considere usar o --mysql-single-transaction

O comando de importação também suporta um --mysql-single-transaction que agrupará a exportação SQL em uma única transação para confirmar todas as alterações da importação de uma só vez, evitando que a gravação sobrecarregue o servidor de banco de dados, especialmente em ambientes MySQL em cluster.

 $ cd /path/to/wordpress $ wp mu-migration export all site.zip --themes --plugins

Com rsync , podemos transferir facilmente o arquivo exportado gerado:

 $ rsync -aP site.zip [email protected]:/var/www/multisite/

Em seguida, executamos o comando import no servidor de destino:

 $ ssh [email protected] $ cd /var/www/multisite $ wp mu-migration import all site.zip

Agora precisamos saber qual é o blog_id do subsite recém-criado; podemos obter essa informação executando:

A partir da saída do comando acima, sabemos que nosso site foi importado com o ID 2. Precisaremos disso para mover corretamente a pasta de uploads usando rsync . No servidor de site único, executaríamos o seguinte:

 $ rsync -azP wp-content/uploads/ [email protected]:/var/www/multisite/wp-content/uploads/sites/2/

O comando acima irá copiar toda a pasta de uploads para o local correto em uma instalação multisite, que fica na pasta de sites e dentro de uma pasta onde seu nome é apenas o ID do site (neste caso, 2). Neste ponto, podemos editar o arquivo do host para apontar o domínio do site único para o servidor multisite; então podemos fazer alguns testes para garantir que a migração funcionou conforme o esperado.

Para a migração final, tudo seria igual, com a exceção de que --blog_id=2 para o comando import:

 $ wp mu-migration import all site.zip --blog_id=2

E como benefício, a sincronização de uploads acontecerá de maneira muito mais rápida, pois o rsync só transferirá os arquivos que foram alterados ou adicionados desde a última sincronização.

Conclusão

Migrar de ou para multisite é difícil e a ferramenta apresentada neste artigo simplifica todo o processo de migração reduzindo o esforço para alguns comandos CLI. O MU-Migration tem sido usado ativamente na produção por mais de um ano e é um projeto totalmente de código aberto. O plugin é desenvolvido no Github e solicitações de pull são bem-vindas!