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

43

Eu criei um site no WordPress em nossa máquina de desenvolvimento. No tema que estamos usando, há inúmeras zonas de widgets para exibir o texto na (barra lateral e página inicial). Eu 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 um instantâneo do banco de dados. Em seguida, editei o arquivo .sql resultante para atualizar todos os caminhos de arquivos e referências de URL para apontar para o nosso site de produção.

Depois de criar o banco de dados, site e copiar todos os arquivos para o site de produção, eu corro o arquivo .sql do prompt de comando do mysql para importar os dados para o novo banco de dados.

No entanto, quando vou ao site de produção, parte do texto aparece e outras não. Quando olho para a seção de widgets do site, os widgets de texto estão ausentes de algumas das zonas do widget. Os widgets de texto não 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 de widget de texto durante a importação?

    
por Dillie-O 10.02.2011 / 16:35
fonte

5 respostas

41

Aqui é onde está o seu problema:

  

Eu editei o arquivo .sql resultante   para atualizar todos os caminhos de arquivos e   Referências de URL para apontar para o nosso   local de produção.

Você não pode fazer isso. O WordPress armazena muitas opções como "dados serializados", que contém tanto o conteúdo das sequências das coisas como seu tamanho . Então, quando você modifica a URL e o tamanho muda, então 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 deverá ter exatamente o mesmo URL que seu site de produção para começar. Você pode editar manualmente seu arquivo HOSTS para dar a esse domínio de produção (como example.com) um endereço IP diferente (como 127.0.0.1) e, portanto, a URL de "produção" se tornará o site de desenvolvimento, somente para você. Então você pode criar seus dados e links e tudo o mais usando essa URL de produção, e quando você migrar os dados, nada sobre isso tem que ser alterado.

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

E embora eu hesite em sugerir, há uma maneira de alterar o código principal do WordPress para lidar com essas serializações quebradas. Você tem que modificar o arquivo wp-includes / functions.php, e mudar 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. Ele só deve ser usado para você se levantar e trabalhar agora. No longo prazo, você precisa corrigir o seu processo de desenvolvimento para que você não precise fazer esse tipo de URL para começar.

    
por Otto 10.02.2011 / 19:45
fonte
10

Para lidar com esse problema, sempre uso o WordPress Serialized Search & Substitua a ferramenta fornecida aqui. Funciona perfeitamente sem problemas. Eu tenho usado isso por um longo tempo em todos os meus requisitos de migração do site. Isso realmente cuida dos problemas com a migração do banco de dados de desenvolvimento para a produção.

enlace

    
por Subharanjan 28.03.2013 / 15:07
fonte
7

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

No entanto, eu consegui contornar isso usando um script legal em enlace

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

  1. Faça um dump do banco de dados (por exemplo, usando o phpmyadmin) do wordpress existente
  2. Restaurar o despejo como está, (sem necessidade de modificações) para o seu novo local
  3. Descompacte o script do spectacu.la em sua pasta inicial do wordpress (não é um plug-in ...)
  4. Execute o script em seu novo site apontando seu navegador para ele, por exemplo enlace
  5. Não se esqueça de excluir o script da sua nova página do wordpress
por Yoav Aner 17.04.2011 / 18:21
fonte
2

O OP estava com excesso de zelo 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 parcimoniosa na pesquisa e substituição, incluindo o backtick na expressão regular e, em seguida, atualizando manualmente as chaves restantes no banco de dados após a importação.

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

  1. Fazer backup e mover sua exportação de banco de dados Arquivo SQL 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 (PRIOR to importando seu arquivo SQL!). Mão única para fazer isso seria usar um Perl one-liner 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 todas as chaves dentro de _opções que contém o prefixo codificado: atualizar conjunto myprefix_options option_name = concat ('myprefix _', substr (nome_da_opção, 4)) onde option_name como 'wp _%'
  5. Atualize todas as chaves dentro de _user_meta que contêm o prefixo codificado: atualizar conjunto myprefix_usermeta meta_key = concat ('myprefix _', substr (meta_key, 4)) onde meta_key como 'wp _%'
por Tom Auger 24.05.2011 / 01:12
fonte
0

Eu usei o plugin WP Migrate , que substitui as correções de http e pasta. Eu tenho 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 */;

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

    
por Ricardo Martins 10.07.2012 / 16:40
fonte