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

46

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?

Dillie-O
fonte
Venho pesquisando ao longo do caminho, e a única coisa que consigo pensar é que as informações do widget estão sendo armazenadas na tabela wp_options, que parece codificar alguns dados de uma maneira estranha. Ainda não foi possível tentar isso com um tema diferente para ver se ele está relacionado ao tema.
Dillie-O

Respostas:

44

É 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.

Otto
fonte
@Otto excelente resposta. Pergunta rápida: modificar uma tabela de blob / texto não serializada como wp_posts fora do MySql afetaria alguns dos dados serializados em wp_post_meta ou wp_options? Eu tive o mesmo problema com o widget de texto, mas não toquei em wp_options. Apenas modifiquei wp_posts.
22411 Chris_O
Uau, nunca percebi o que estava acontecendo com os dados, mas faz todo o sentido! Muito Obrigado!
Dillie-O
4
Outra solução alternativa que algumas pessoas usam é fazer com que seu sistema de desenvolvimento tenha um nome de domínio "example.dev" em vez de "example.com". Dessa forma, os comprimentos não mudam para as strings quando as movem para a produção. Eu prefiro o método de arquivo HOSTS.
Otto
3
2016 e wordrepss ainda estão salvando dados serializados no banco de dados. most famous worst codeprêmio não precisa procurar mais.
Ejaz
1
OBRIGADO!!! Bom ponto e ótimo hack. Geralmente, eu recebo esse hack para retornar todos os dados e, em seguida, basta atualizar as configurações existentes novamente e, quando remover esse código, funciona perfeitamente.
Ivijan Stefan Stipić
10

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/

Subharanjan
fonte
1
Sim, estou usando este script há anos e recomendo
davemac 4/13
Trabalhou para mim a maior parte do tempo. Mas esta semana, quando eu substituído http://localhost/Me/site_namepor http://site.dev(a partir de um host local para outro) utilizando v 3.0.0 Eu perdi meu widget e menu posições curiosamente. Talvez esse problema também esteja relacionado ao comprimento da string.
rhand
Eu tenho usado .. mas nunca enfrentou esta situação ainda. Você pode baixar a versão mais antiga desse script e tentar novamente. Tente substituir localhost/Me/site_namepor site.dev.
Subharanjan
O URL foi alterado (agora https, em vez http): interconnectit.com/products/…
Koryonik 18/09/15
Roteiro lindo. Dupliquei um banco de dados MySQL do PHPMyAdmin de um antigo para outro - sem alteração de URLs - e depois fui para a pasta do novo site onde estavam os arquivos WP frescos (ao lado de um wp-config.php adequado, com o novas credenciais de banco de dados), adicionou o script e cuidou de tudo. Os dados serializados são atualizados ao longo dos URLs normais. Fácil e rápido! Altamente recomendado. Importante: não esqueça de remover o script depois que ele tiver sido usado, pois ele tem acesso aos detalhes do seu banco de dados!
Amendoins
7

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
Yoav Aner
fonte
1
Eu sei que isso é meio antigo, mas onde devo especificar o novo nome do banco de dados se estiver restaurando o dump? eu não deveria pelo menos colocar o novo nome do banco de dados na segunda etapa? Obrigado por esta informação
andresmijares
Não sei se entendi completamente sua pergunta. A restauração do banco de dados pode ser feita com ferramentas como phpmyadmin e você pode dar um novo nome ou usar o nome antigo. O script que eu mencionei simplesmente altera o texto dentro do banco de dados depois que ele já é restaurado.
precisa saber é o seguinte
Olá Yoav, obrigado pela resposta, quero dizer, quando exporto um banco de dados, normalmente altero o nome do banco de dados para o novo e altero os links do domínio. Dito isso, em sua etapa número dois, você diz restaurar o dump como está sem modificações, eu só queria saber se isso literalmente ou tenho que alterar pelo menos o nome do banco de dados. Eu sei que pode ser uma pergunta idiota, estou meio que perdida, obrigado novamente por sua resposta
andresmijares
Não sei como você despeja seu banco de dados, mas se você usa a ferramenta 'export' do phpmyadmin, não importa qual é o nome do banco de dados. Você pode usar a exportação e importá-la de volta para qualquer outro banco de dados. Geralmente, no que diz respeito ao ponto 2, acho que é aceitável alterar o nome do banco de dados.
precisa saber é o seguinte
2

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_%'
Tom Auger
fonte
0

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.

Ricardo Martins
fonte
Olá Ricardo, Bem-vindo às Respostas do WordPress! A área em que você postou é reservada para respostas à pergunta original. Mesmo que sua pergunta esteja relacionada, você deve publicá-la como uma pergunta separada. Você terá uma chance muito maior de ter essa resposta dessa maneira.
11282 Chris_O