Substituição e alterações em massa em todo o conteúdo de uma base de dados ou aplicação

Pode ser necessária uma pesquisa e substituição em massa ao mudar de domínio ou ativar o HTTPS. No WordPress, não deve ser feita com um UPDATE ... REPLACE arbitrário: muitos valores estão serializados e uma substituição SQL direta pode corromper os seus comprimentos.

Preparação obrigatória

1. Crie um ambiente de staging a partir de uma cópia recente de produção.
2. Exporte a base de dados antes de cada ensaio e verifique o ficheiro:

umask 077
wp db export "$HOME/wp-antes-reemplazo.sql" &&
test -s "$HOME/wp-antes-reemplazo.sql" &&
sha256sum "$HOME/wp-antes-reemplazo.sql" > "$HOME/wp-antes-reemplazo.sql.sha256"

Utilize um nome novo para cada cópia e verifique que wp db export termina corretamente. O checksum permite detetar alterações no ficheiro; é o teste de restauro que verifica se serve para recuperar a base de dados. Proteja os ficheiros fora da pasta pública:

chmod 400 "$HOME/wp-antes-reemplazo.sql" "$HOME/wp-antes-reemplazo.sql.sha256"
sha256sum -c "$HOME/wp-antes-reemplazo.sql.sha256"

3. Descarregue a cópia e teste a sua importação numa base de dados vazia independente.
4. Defina o valor exato de origem, o destino, as tabelas e as colunas. Não execute uma pesquisa sobre toda a base de dados se só precisar de modificar o conteúdo dos artigos.

Pré-visualizar com WP-CLI

Antes de continuar, instale e verifique o WP-CLI na conta. O WP-CLI mantém corretamente os dados serializados. Para alterar ligações dentro do conteúdo dos artigos, limite a operação à tabela e à coluna necessárias e execute primeiro --dry-run:

wp search-replace 'http://dominio.example' 'https://dominio.example' wp_posts \
  --include-columns=post_content \
  --precise \
  --report-changed-only \
  --dry-run

Substitua wp_posts pelo nome real se a sua instalação utilizar outro prefixo. O modo --dry-run indica as correspondências, mas não modifica registos: para ver como ficam os artigos, tem de executar a alteração real sobre o clone.

Reveja o número de alterações previsto. Se incluir tabelas ou colunas não previstas, restrinja a pesquisa antes de executar a alteração real em staging. Verifique depois uma amostra dos artigos modificados antes de aplicar o procedimento em produção.

Quando o ensaio, a cópia e o caminho de reversão estiverem validados, repita o mesmo comando sem --dry-run, primeiro em staging. Para produção, crie uma nova exportação, pare as escritas, execute exatamente o comando validado e verifique ligações, widgets, menus, blocos e registos de erro antes de reabrir o site.

Se a validação falhar, mantenha as escritas paradas e restaure wp-antes-reemplazo.sql. Confirme que o site volta ao estado anterior antes de retirar a manutenção.

Alternativas com interface

O WordPress dispõe de plugins para realizar estas tarefas através de uma interface gráfica, onde pode definir a pesquisa, a substituição e as tabelas afetadas. São mais lentos do que o WP-CLI em bases de dados grandes, mas também devem manter corretamente os dados serializados.

Também com estes plugins são obrigatórios a exportação, o ensaio em staging, a pré-visualização e a seleção explícita de tabelas. Não utilize uma opção global sem rever o seu alcance.

Uma opção com pré-visualização é:

• Better Search Replace

Se estiver a mudar todo o domínio

O exemplo só modifica post_content; não altera definições, widgets, menus nem tabelas de plugins. Faça o inventário dessas localizações e prepare o alcance correspondente. Não substitua automaticamente a coluna guid: não é um URL de navegação. No WordPress multisite, reveja cada site e a configuração da rede antes de alargar o comando.

Consulte as opções de wp search-replace. Para outras aplicações, utilize uma ferramenta que conheça o seu formato: o WP-CLI não transforma uma base de dados alheia ao WordPress num caso compatível.