Roteiro para importar um blog ao WordPress Multisite usando PhpMyAdmin e Notepad

Neste artigo, compartilho um roteiro que fiz para importar um blog ao WordPress Multisite (WPMU) usando não muito mais do que PhpMyAdmin e o Notepad (Bloco de Notas) do Windows, pois obtive resultados satisfatórios, com incrível precisão — até os IDs originais dos posts e anexos se mantiveram — e sem nenhum erro de timeout. Também resolvi fazer esse registro aqui para servir de referência, pra mim e pra você, e pra seguir o conselho do Rodrigo Gurgel para escrever um diário (muito embora só vai ser isto aqui mesmo).

A verdade é que já faz um tempo que eu estava para trazer para a rede de multisites do VaLeW a versão original do Jogos de Zumbi que estava preservada (embora já bastante depenada) na Gaming Room, só que ficava enrolando, pois eu já tinha feito várias vezes o caminho contrário (tirar um blog do multisite usando este guia). Pois bem: partindo do princípio de que eu precisava apenas de algumas tabelas do blog, baixar e copiar os arquivos, fazer pequenas edições no .sql e importar tudo na outra instalação, resolvi tentar.

A sorte é que deu certo — e sem precisar do importador do WordPress, plugins pagos ou WP-CLI. Algumas partes serão abordadas de modo mais superficial, já que não sou profissional nesses assuntos, mas mantive precisão nos passos mais críticos do processo. Partindo do pressuposto que você tem prática e acesso às ferramentas usadas (PhpMyAdmin e Bloco de Notas), segue uma lista resumindo o procedimento:

Passos principais

1. Backups completos

Resista à preguiça. Antes de qualquer coisa, exporte o banco de dados do blog antigo e copie todos os arquivos que estão na pasta wp-content/uploads.

Convém fazer backup do site original mesmo se você estiver certo que só vai mexer nele depois que for importado com total sucesso no Multisite, nem que seja por desencargo de consciência. Entretanto, é extremamente recomendado fazer o backup do WPMU como um todo antes de iniciar, o que pode acabar sendo muito importante, um bote salva-vidas nesta jornada. Nunca se sabe quando a gente vai dar uma burrada e/ou surge alguma eventualidade fora do nosso controle.

2. Pra facilitar

No nosso exemplo, vamos usar siteantigo.com como o blog a ser importado, www.rede.com como o site onde está a instalação do WPMU e sitenovo.rede.com para o destino do blog importado, partindo do pressuposto que você usa subdomínios no seu multisite.

3. Criar o novo site no WPMU

No painel de rede, criar um novo site (mesmo domínio ou subdomínio, tanto faz) apenas para gerar as tabelas iniciais (wp_X_*). Guarde o número X, vai ser importante. No nosso exemplo, X vai ser 17.

4. Subdomínio

Se for usar subdomínio no seu WordPress Multisite, configure seu SSL de uma vez, se quiser HTTPS (recomendado). Pode ser que tenha que criar um subdomínio na sua conta do servidor do WPMU também, tipo no cPanel ou DirectAdmin.

Pode demorar um pouco pro DNS atualizar, então, o quanto antes melhor. Aliás, dá pra fazer isso até antes do passo 3.

5. Identificar as tabelas correspondentes

No PhpMyAdmin, localizar as tabelas do novo site (ex.: wp_17_posts, wp_17_options, etc.) e as do blog original (ex.: wp_posts, wp_options).

6. Exporte tabelas essenciais do blog a ser importado num SQL

Na lista abaixo, temos as tabelas que devem ser exportadas do blog original para importar no novo:

• wp_posts
• wp_postmeta
• wp_options
• wp_terms, wp_termmeta, wp_term_relationships, wp_term_taxonomy (caso existam)
• wp_comments, wp_commentmeta (opcional, se quiser manter comentários)
• wp_links (opcional, por ser tabela antiga do blogroll, raramente usada hoje, mas pode ser que você use).

Se quiser manter dados de plugins, exporte suas tabelas também, mas isso varia de plugin pra plugin, então você vai ter que quebrar a cabeça aí pra descobrir o que é o que, embora isso seja razoavelmente intuitivo em muitos casos.

Pra reforçar: tabelas que geralmente não precisam (ou nem devem) ser exportadas:

• wp_users e wp_usermeta → no Multisite, os usuários são compartilhados entre todos os sites, então importar essas tabelas pode duplicar ou bagunçar IDs. é melhor criar os usuários manualmente depois, como sugerido nas verificações finais.
• wp_usermeta, wp_user_roles, wp_capabilities → se vierem junto, melhor ignorar.
• tabelas de logs ou estatísticas de plugins (ex.: Jetpack, WP Statistics, WP Super Cache).

7. Edições no SQL

Editar o prefixo das tabelas no arquivo SQL

Abra o arquivo .SQL que você exportou (por exemplo siteantigo.sql) com o Bloco de Notas e substitua wp_ pelo prefixo do novo site (wp_17_, por exemplo), mantendo o mesmo formato.

Se tiver dificuldades para descobrir qual o ID do blog onde você vai importar o conteúdo do site antigo, vá em Painel da Rede > Todos os sites (wp-admin/network/sites.php) e pegue a URL do link editar do sitenovo.rede.com .

Vai ficar algo tipo assim https://sitenovo.rede.com/wp-admin/network/site-info.php?id=17, onde 17 é o ID do blog.

Editar links de mídia

Isso exige um pouco de atenção, e é melhor fazer antes do passo seguinte. Note que, no Multisite recente (>= WP 3.5), os uploads do site com ID 17 ficam fisicamente em /wp-content/uploads/sites/17 e devem ser servidos via URL https://sitenovo.rede.com/files/. Já em redes anteriores ao WP 3.5, os uploads ficam em /wp-content/blogs.dir/17/files/ (ou /wp-content/blogs.dir/17/, dependendo da configuração).

Ou seja, substitua todas as URLs antigas das mídias no SQL para refletir o caminho correto do WPMU, garantindo que posts, páginas e attachments carreguem corretamente após a importação.

Aqui, no nosso exemplo, basta substituir tudo de ://siteantigo.com/wp-content/uploads/ para ://sitenovo.rede.com/files/.

Mais atenção: se o SQL for importado com links antigos, as imagens aparecerão quebradas ou apontando para o domínio antigo.

Editar o restante de links no arquivo SQL

Substitua, ainda no Bloco de Notas, todas as outras ocorrências do domínio antigo (siteantigo.com) pelo novo (sitenovo.rede.com).

Ajustes finos

É provável que o seu siteantigo.com tenha alguns custom fields (campos personalizados) com nomes como _wp_old_date ou _wp_old_slug. Esses campos geralmente ficam ocultos, mas podem ser importantes para o tema ou para o fluxo de trabalho do site.

Acontece que, após o passo 7, tais campos vão aparecer como _wp_17_old_date e _wp_17_old_slug. Se você importar o SQL assim, eles ficarão inutilizados no site novo, o que pode avacalhar o esquema lá.

Para corrigir, basta fazer mais uma substituição no arquivo SQL com o Notepad, de _wp_17_old_date → _wp_old_date e _wp_17_old_slug → _wp_old_slug.

Lembrete importante: seja extremamente preciso ao fazer estas edições com o Bloco de Notas pra não avacalhar o plantão.

8. Plugins

Certifique-se que os plugins que você usava no site antigo estão disponíveis para o site novo. Aí, tem que olhar as paradas referentes aos plugins no “Painel da rede”.

Pular este passo talvez não quebre o site novo, mas acho melhor conferir de uma vez, até porque o esquema de plugins do WPMU tem algumas peculiaridades, como as paradas de ativar na rede e tal.

9. Importar o arquivo SQL editado no banco da rede

Usando o PhpMyAdmin, importar o arquivo sobre as tabelas recém-criadas do novo site (pode sobrescrever ou eliminar apenas as tabelas correspondentes às do passo 6 com prefixo wp_17_).

No nosso exemplo, estas tabelas que foram dropadas/eliminadas:

• wp_17_commentmeta
• wp_17_comments
• wp_17_links
• wp_17_options
• wp_17_postmeta
• wp_17_posts
• wp_17_terms
• wp_17_term_relationships
• wp_17_term_taxonomy

10. Copiar os uploads do site antigo

Isso é moleza. Dá pra fazer com FTP se tiver com preguiça de mexer com SSH ou não tiver acesso.

Basta copiar o conteúdo que você salvou da antiga pasta wp-content/uploads, do siteantigo.com, para o diretório do novo site (/wp-content/blogs.dir/17/files/ ou /wp-content/blogs.dir/17/, dependendo da configuração, segundo nosso exemplo, onde ID = 17).

Ajuste as permissões (chmod), se necessário.

Verificações importantes

• Verificar a URL principal e o domínio do site – No painel da rede (/wp-admin/network/sites.php), edite o site e corrigir o domínio e o caminho, se estiverem apontando para o antigo. Tem muita coisa lá que você pode/deve conferir pra ver se está tudo legal.
• Verificar configurações de permalinks – Confira os links permanentes (permalinks) é passo importante também para manter a estrutura fiel no site novo como estava no blog antigo. Aliás, depois de editar links e importar o SQL, é recomendado salvar novamente a configuração de permalinks no admin para regenerar regras de rewrite.
• Conferir usuários – E adicionar os que estavam no site antigo, se tiver mais de um, suas permissões e tudo mais.
• Testar o front-end e o painel – Verificar se os posts, páginas, categorias e mídias aparecem corretamente no novo site.

Ajustes finais

• Configurar o cachê e demais plugins pode ser importante aqui.
• É recomendado também conferir que o site tenha uma chave única pra evitar zicar com cachês de objeto, tipo Redis ou Memcached. Provavelmente já tem isso no wp-config.php do seu www.rede.com, mas dá uma olhada pra ter certeza define('WP_CACHE_KEY_SALT', 'nomedosite_');
• Depois disso, limpe caches e reindexe se necessário.

Adendos: edições manuais via PhpMyAdmin

Anotei esses passos abaixo na lista, mas eles só foram necessários na minha experiência porque havia inconsistência entre os domínios antigos e novos. Se as URLs tivessem sido definidas corretamente no WordPress antes da migração, provavelmente não seriam precisos.

• Ajuste de domínios antigos nas colunas guid da tabela wp_X_posts.
• Remoção de valores residuais no wp_X_options (principalmente transients e caches).
• Verificação de inconsistências em URLs internas e referências cruzadas entre sites (problema causado por cache compartilhado).
• Redefinição do WP_CACHE_KEY_SALT para cada site, evitando sobreposição de caches.
• Se precisar, substituição do WordPress antigo por um redirecionador PHP dinâmico, apontando cada URL antiga para a nova com o domínio atualizado. No caso, precisei.
• Caso precise eliminar resquícios do site anterior antes de importar o SQL novo: DELETE FROM `wp_17_options` WHERE option_name LIKE '_transient_%';
• Plugins como o Better Search Replace podem ajudar a realizar edições rápidas diretamente na base de dados MySQL, pela interface do administrador do seu blogue. Isso pode ser útil para fazer ajustes no seu sitenovo.rede.com depois de importar o arquivo .SQL. Entretanto, em certos casos, o plugin não consegue editar linhas específicas — geralmente por conterem dados serializados ou codificados de outra forma. Por isso, é melhor fazer as substituições principais no .SQL antes da importação e deixar o uso do plugin apenas para correções menores, se necessário.

Então, se quiser ver como ficou o resultado final desta jornada que foi registrada neste post, está aqui!

Maravilha.

Isso ficou mais bagunçado do que imaginei, mas valew a pena registrar aqui enquanto ainda está tudo fresco na minha memória. Espero que você entenda este guia aqui sem problemas (ou que pelo menos eu consiga entender essa zona no futuro), que o texto te ajude a manter seu trabalho vivo e sua produtividade produtiva.

Se tiver observações, correções, dúvidas e complementações, deixe aí nos comentários.

Abraços!

Mais informações e troubleshooting

• Rodrigo Gurgel – Por que você deve escrever @ Direita.TV – “Os benefícios desta prática, uma das atividades mais poderosas e transformadoras que o ser humano pode realizar, capaz de curar feridas íntimas, mudar vidas e inspirar outras pessoas“.
• Moving WordPress: Moving a Site Out of a Multisite Network @ Envato Tuts+ – Este guia ensina a mover um site pra fora do WPMU. Em inglês.
• Better Search Replace @ WordPress – Plugin que faz alterações rápidas na base de dados do blogue diretamente da interface de usuário do WordPress.
• Como apaguei um arquivo com caractere inválido no Windows 10
• Barra de progresso pulando para 100% durante renderização no Camtasia? A solução é fácil!
• Como identificar whisky falso
• Como abrir arquivos .camrec do Camtasia antigo e recuperar gravação
• Como identificar picanha falsa
• Como usei um domínio com SSL num site do WordPress Multisite