Perché l'importazione del mio database sta perdendo i dati del widget di testo?

Ho creato un sito in WordPress sulla nostra macchina di sviluppo. Nel tema che stiamo usando ci sono numerose zone widget in cui visualizzare il testo (barra laterale e prima pagina). Ho usato semplici widget di testo in tutte queste zone per mettere le nostre informazioni di visualizzazione.

Quando ho migrato il sito in produzione, ho usato il plug-in WP-DB-Backup per creare un'istantanea del database. Ho quindi modificato il file .sql risultante per aggiornare tutti i percorsi dei file e i riferimenti URL per puntare al nostro sito di produzione.

Dopo aver creato il database, il sito Web e aver copiato tutti i file sul sito di produzione, eseguo il file .sql dal prompt dei comandi mysql per importare i dati nel nuovo database.

Tuttavia, quando vado sul sito di produzione, parte del testo viene visualizzato e in parte no. Quando guardo nella sezione dei widget del sito, i widget di testo mancano in alcune aree dei widget. I widget di testo non sono nemmeno visibili nell'area "Widget inattivi", semplicemente non ci sono.

Ho anche provato a ripetere il processo usando il plugin BackWPup, notando che la sintassi SQL è diversa quando scarica il database.

Perché sto perdendo i dati del widget di testo durante l'importazione?

Questo è dove il tuo problema è:

Ho quindi modificato il file .sql risultante per aggiornare tutti i percorsi dei file e i riferimenti URL per puntare al nostro sito di produzione.

Non puoi farlo. WordPress memorizza molte opzioni come "dati serializzati", che contiene sia il contenuto di stringhe delle cose che la loro lunghezza . Pertanto, quando si modifica l'URL e la lunghezza cambia, i dati serializzati non sono più corretti e PHP lo rifiuta.

Il problema a lungo termine è che, fondamentalmente, stai sbagliando. Se stai configurando un sito di sviluppo in cui verranno migrati i suoi dati, all'inizio dovrebbe avere lo stesso URL del tuo sito di produzione. Puoi modificare manualmente il tuo file HOSTS per dare a quel dominio di produzione (come esempio.com) un indirizzo IP diverso (come 127.0.0.1) e quindi l'URL "produzione" diventerà il sito di sviluppo, solo per te. Quindi è possibile creare dati e collegamenti e tutto il resto utilizzando tale URL di produzione e quando si esegue la migrazione dei dati, non è necessario modificare nulla al riguardo.

A breve termine, tuttavia, non utilizzare una semplice ricerca / sostituzione di testo nel file SQL. Come hai scoperto, questo rompe le cose.

E mentre esito a suggerirlo, c'è un modo per modificare il codice core di WordPress per gestire queste serializzazioni non funzionanti. Devi modificare il file wp-Includes / Functions.php e cambiare la funzione maybe_unserialize () in questo modo:

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]); }  

Questa NON è una soluzione praticabile a lungo termine. Dovrebbe essere usato solo per farti alzare e lavorare in questo momento. A lungo termine, è necessario correggere il processo di sviluppo in modo da non dover iniziare con questo tipo di munging URL.

Per affrontare questo problema, utilizzo sempre lo strumento Cerca e sostituisci serializzato di WordPress fornito qui. Funziona perfettamente senza problemi. Lo uso da molto tempo su tutti i requisiti di migrazione del mio sito. Questo risolve davvero i problemi legati alla migrazione del database di sviluppo alla produzione.

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

La risposta di Otto è precisa. L'ho scoperto anche nel modo più duro.

Tuttavia, sono riuscito a aggirare questo problema usando uno script interessante su http://spectacu.la/search-and-replace-for-wordpress-d database/

Per migrare il tuo wordpress e su un nuovo nome URL / dominio, procedi come segue:

1. Prendi un dump DB (ad es. Usando phpmyadmin) del wordpress esistente
2. Ripristina il dump così com'è (senza necessità di modifiche) nella nuova posizione
3. Decomprimi lo script da spectacu.la nella cartella principale di wordpress (non è un plugin ...)
4. Esegui lo script sul tuo nuovo sito puntando il browser verso di esso, ad esempio http: //new-website.url/searchreplacedb.php
5. Non dimenticare di eliminare lo script dalla nuova home wordpress

L'OP era troppo zelante quando faceva una ricerca e sostituzione sul file di esportazione del database e finiva per cambiare le occorrenze di "wp_" all'interno di alcuni dei dati serializzati. La soluzione deve essere più parsimoniosa nella ricerca e sostituzione includendo il backtick all'interno dell'espressione regolare e quindi aggiornando manualmente le chiavi rimanenti all'interno del database dopo l'importazione.

Se stai migrando e modificando il prefisso, e come un approccio più manuale, procedi come segue (questo risolve solo i problemi dei PO e non si occupa dell'aggiornamento dell'URL del sito)

1. Eseguire il backup e spostare il file SQL di esportazione del database nel nuovo ambiente (il mio esempio presuppone un nome file di backup_YYYY-MM-DD.sql)
2. Esegui una ricerca e sostituzione di massa sul file SQL per modificare i nomi delle tabelle in modo da utilizzare il nuovo prefisso (PRIMA di importare il file SQL!). Un modo per farlo sarebbe usare un one-liner Perl come: perl -p -i.bak -e "s /` wp_ / `myprefix_ / g" backup_YYYY-MM-DD.sql
3. Importa i tuoi dati SQL nel database
4. Aggiorna tutte le chiavi all'interno di _options che contengono il prefisso hard-coded: update myprefix_options set option_name = concat ('myprefix _', substr (option_name, 4)) dove option_name come 'wp_%'
5. Aggiorna tutte le chiavi all'interno di _user_meta che contengono il prefisso hard-coded: aggiorna myprefix_usermeta set meta_key = concat ('myprefix _', substr (meta_key, 4)) dove meta_key come 'wp_%'

Ho usato il plugin WP Migrate , witch sostituisce le patch http e delle cartelle. Ho avuto un singolo problema durante l'importazione, ma ho risolto mettendo le seguenti righe in cima al sql generato:

/*!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 */;

Ho anche provato con lo strumento Cerca e sostituisci (v2.1), risposto da @Yoav, ma rompe ancora i miei dati serializzati.