Por que minha importação de banco de dados está perdendo dados do widget de texto?

Eu criei um site no WordPress em nossa máquina de desenvolvimento. No tema que estamos usando, existem inúmeras zonas de widgets para exibir o texto (barra lateral e primeira página). Usei widgets de texto simples em todas essas zonas para colocar nossas informações de exibição.

Quando migrei o site para produção, usei o plug-in WP-DB-Backup para tirar uma captura instantânea do banco de dados. Em seguida, editei o arquivo .sql resultante para atualizar todos os caminhos de arquivo e referências de URL para apontar para o nosso site de produção.

Após criar o banco de dados, o site e copiar todos os arquivos para o site de produção, eu executo o arquivo .sql no prompt de comando do mysql para importar os dados para o novo banco de dados.

No entanto, quando vou ao local de produção, parte do texto aparece e parte dele não. Quando olho para a seção de widgets do site, os widgets de texto estão ausentes em algumas zonas do widget. Os widgets de texto nem são visíveis na zona "Widget inativo", eles simplesmente não estão lá.

Eu até tentei repetir o processo usando o plug-in BackWPup, percebendo que a sintaxe SQL é diferente quando despeja o banco de dados.

Por que estou perdendo dados do widget de texto durante a importação?

É aqui que o seu problema é:

Em seguida, editei o arquivo .sql resultante para atualizar todos os caminhos de arquivo e referências de URL para apontar para o nosso site de produção.

Você não pode fazer isso. O WordPress armazena muitas opções como "dados serializados", que contêm o conteúdo das coisas e seu tamanho . Portanto, quando você modifica a URL e o comprimento muda, os dados serializados não estão mais corretos e o PHP os rejeita.

O problema a longo prazo é que, basicamente, você está fazendo errado. Se você estiver configurando um site de desenvolvimento que terá seus dados migrados, ele deve ter exatamente o mesmo URL que o site de produção para começar. Você pode editar manualmente o arquivo HOSTS para fornecer a esse domínio de produção (como example.com) um endereço IP diferente (como 127.0.0.1) e, portanto, a URL "produção" se tornará o site de desenvolvimento, apenas para você. Em seguida, você pode criar seus dados e links e tudo mais usando esse URL de produção e, quando você migra os dados, nada precisa ser alterado.

No curto prazo, no entanto, não use uma simples pesquisa / substituição de texto no arquivo SQL. Como você descobriu, isso quebra as coisas.

E embora eu hesite em sugerir, existe uma maneira de alterar o código principal do WordPress para lidar com essas serializações quebradas. Você precisa modificar o arquivo wp-includes / functions.php e alterar a função maybe_unserialize () para isso:

function maybe_unserialize( $original ) {
    if ( is_serialized( $original ) ) {
        $fixed = preg_replace_callback(
            '!(?<=^|;)s:(\d+)(?=:"(.*?)";(?:}|a:|s:|b:|i:|o:|N;))!s',
            'serialize_fix_callback',
            $original );
        return @unserialize( $fixed );
    }
    return $original;
}
function serialize_fix_callback($match) { return 's:' . strlen($match[2]); }  

Esta NÃO é uma solução viável a longo prazo. Só deve ser usado para você começar a trabalhar agora. A longo prazo, você precisa corrigir seu processo de desenvolvimento para não ter que fazer esse tipo de mudança de URL para começar.

Para lidar com esse problema, eu sempre uso a ferramenta Pesquisa e Substituição Serializada do WordPress, fornecida aqui. Funciona perfeitamente bem sem problemas. Uso isso há muito tempo em todos os meus requisitos de migração de sites. Isso realmente cuida dos problemas com a migração do banco de dados de desenvolvimento para a produção.

https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

A resposta de Otto é direta. Eu também descobri isso da maneira mais difícil.

No entanto, consegui contornar isso usando um script interessante em http://spectacu.la/search-and-replace-for-wordpress-databases/

Para migrar seu wordpress e para um novo nome de URL / domínio, faça o seguinte:

1. Faça um despejo de banco de dados (por exemplo, usando phpmyadmin) do wordpress existente
2. Restaure o dump como está, (sem necessidade de modificações) para seu novo local
3. Descompacte o script do spectacu.la na sua pasta inicial do wordpress (não é um plugin ...)
4. Execute o script no seu novo site, apontando o navegador para ele, por exemplo, http: //new-website.url/searchreplacedb.php
5. Não se esqueça de excluir o script da sua nova casa wordpress

O OP foi excessivamente zeloso ao fazer uma pesquisa e substituição no arquivo de exportação do banco de dados e acabou alterando as ocorrências de "wp_" em alguns dos dados serializados. A solução é ser mais parcimonioso na pesquisa e substituição, incluindo o backtick na expressão regular e atualizando manualmente as chaves restantes no banco de dados após a importação.

Se você estiver migrando e alterando o prefixo e, como uma abordagem mais manual, faça o seguinte (isso aborda apenas as preocupações dos OPs e não trata da atualização do URL do site)

1. Faça backup e mova o arquivo SQL de exportação do banco de dados para o novo ambiente (meu exemplo assume um nome de arquivo de backup_YYYY-MM-DD.sql)
2. Faça uma pesquisa e substituição em massa no arquivo SQL para alterar os nomes das tabelas para usar seu novo prefixo (ANTES de importar o arquivo SQL!). Uma maneira de fazer isso seria usar um liner Perl como: perl -p -i.bak -e "s /` wp_ / `myprefix_ / g" backup_YYYY-MM-DD.sql
3. Importe seus dados SQL para o banco de dados
4. Atualize quaisquer chaves em _options que contenham o prefixo codificado: update myprefix_options set option_name = concat ('myprefix _', substr (option_name, 4)) em que option_name como 'wp_%'
5. Atualize quaisquer chaves em _user_meta que contenham o prefixo codificado: update myprefix_usermeta set meta_key = concat ('myprefix _', substr (meta_key, 4)) em que meta_key como 'wp_%'

Eu usei o plugin WP Migrate , o qual substitui as correções de http e pastas. Eu tive um único problema ao importar, mas resolvi colocar as seguintes linhas na parte superior do sql gerado:

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

Também tentei com a ferramenta Search And Replace (v2.1) respondida por @Yoav, mas ela ainda quebra meus dados serializados.