Perché l'importazione del database perde i dati dei widget di testo?

Question

Perché l'importazione del database perde i dati dei widget di testo?

10 feb 2011, 17:35:10

Visualizzazioni: 38.7K

Voti: 48

Ho creato un sito in WordPress sul nostro server di sviluppo. Nel tema che stiamo utilizzando ci sono numerose zone widget per visualizzare il testo (barra laterale e pagina principale). Ho utilizzato semplici widget di testo in tutte queste zone per inserire le nostre informazioni.

Quando ho migrato il sito in produzione, ho utilizzato il plugin WP-DB-Backup per fare uno snapshot del database. Ho poi 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 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 accedo al sito di produzione, alcuni testi vengono visualizzati e altri no. Quando controllo la sezione widget del sito, i widget di testo sono scomparsi da alcune zone widget. I widget di testo non sono nemmeno visibili nella zona "Widget Inattivi", semplicemente non ci sono.

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

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

Dillie-O

1.56K

database mysql importazione

Commenti

Durante il percorso ho fatto alcune ricerche, e l'unica cosa a cui posso pensare è che le informazioni del widget vengano memorizzate nella tabella wp_options, che sembra codificare alcuni dei suoi dati in modo strano. Non ho ancora avuto modo di provare con un tema diverso per vedere se è legato al tema.

Dillie-O

10 feb 2011 17:39:35

Tutte le risposte alla domanda

Commenti

@Ottima risposta. Una domanda veloce: modificare una tabella non serializzata come wp_posts al di fuori di MySQL influirebbe sui dati serializzati in wp_post_meta o wp_options? Ho avuto lo stesso problema con il widget di testo ma non ho toccato wp_options, ho modificato solo wp_posts.

Chris_O

10 feb 2011 21:40:06

Wow, non avevo mai capito che fosse questo il problema con i dati, ma ha perfettamente senso! Mille grazie!

Dillie-O

10 feb 2011 22:52:15

Questa NON è una soluzione valida a lungo termine - nemmeno a breve termine.

hakre

11 feb 2011 03:18:48

Interessante; come si modifica il file hosts per puntare example.com a localhost 127.0.0.1?

markratledge

11 feb 2011 07:28:02

Se vuoi farlo sulla tua macchina locale, basta trovare il tuo file hosts e aggiungere una voce lì (controlla superuser.com per trovare le specifiche del tuo sistema operativo). Altrimenti puoi chiedere al tuo amministratore di Operations o Network di aggiungere una voce sul domain controller.

Dillie-O

11 feb 2011 16:41:50

Mostra i restanti 6 commenti

Per gestire questo problema utilizzo sempre lo strumento WordPress Serialized Search & Replace disponibile qui. Funziona perfettamente senza alcun problema. Lo uso da molto tempo per tutte le mie esigenze di migrazione del sito. Si occupa dei problemi legati alla migrazione del database di sviluppo in produzione.

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

Subharanjan

1.59K

28 mar 2013 16:07:20

Commenti

Sì, uso questo script da anni e lo raccomando vivamente

davemac

5 giu 2013 01:45:02

Per me ha funzionato la maggior parte delle volte. Ma questa settimana quando ho sostituito http://localhost/Me/site_name con http://site.dev (da un local host a un altro) usando la versione 3.0.0, stranamente ho perso le posizioni dei widget e del menu. Quindi forse questo problema è legato anche alla lunghezza della stringa.

rhand

27 nov 2014 09:01:53

Lo uso da tempo... ma non mi sono mai trovato in questa situazione finora. Puoi scaricare la versione precedente di questo script e provare di nuovo con quella. Prova a sostituire localhost/Me/site_name con site.dev.

Subharanjan

27 nov 2014 12:17:17

L'URL è cambiata (ora è https invece di http) : https://interconnectit.com/products/search-and-replace-for-wordpress-databases/

Koryonik

18 set 2015 12:26:25

Script fantastico. Ho duplicato un database MySQL da PHPMyAdmin da uno vecchio a uno nuovo -senza cambiare alcun URL-, poi sono andato nella cartella del nuovo sito dove erano presenti i file freschi di WP (insieme a un corretto wp-config.php, con le nuove credenziali del DB), ho aggiunto lo script, e ha pensato a tutto. I dati serializzati vengono aggiornati insieme agli URL normali. Facile e veloce! Altamente raccomandato. Importante: non dimenticare di rimuovere lo script dopo l'uso poiché ha accesso ai dettagli del tuo DB!

Peanuts

8 feb 2018 03:19:25

La risposta di Otto è perfetta. Anche io ho scoperto questo nel modo più difficile.

Tuttavia, sono riuscito a risolvere il problema utilizzando uno script interessante disponibile su http://spectacu.la/search-and-replace-for-wordpress-databases/

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

Esegui un dump del database (ad esempio utilizzando phpMyAdmin) del WordPress esistente
Ripristina il dump così com'è (senza bisogno di modifiche) nella nuova ubicazione
Decomprimi lo script da spectacu.la nella cartella principale di WordPress (non è un plugin...)
Esegui lo script sul tuo nuovo sito puntando il browser all'indirizzo, es. http://nuovo-sito.url/searchreplacedb.php
Non dimenticare di eliminare lo script dalla cartella principale del nuovo WordPress

Yoav Aner

313

17 apr 2011 19:21:25

Commenti

So che è un po' vecchio, ma dove dovrei specificare il nuovo nome del database se sto ripristinando il dump così com'è? Non dovrei almeno inserire il nuovo nome del database nel secondo passaggio? Grazie per queste informazioni

andresmijares

5 gen 2012 21:22:12

Non sono sicuro di aver capito appieno la tua domanda. Il ripristino del database può essere fatto con strumenti come phpmyadmin e puoi dargli un nuovo nome o usare il vecchio. Lo script che ho menzionato cambia semplicemente il testo all'interno del database dopo che è già stato ripristinato.

Yoav Aner

8 gen 2012 18:45:06

Ciao Yoav, grazie per la risposta, intendo che quando esporto un DB normalmente cambio il nome del database con quello nuovo e modifico i link del dominio. Detto questo, nel tuo passaggio numero due dici di ripristinare il dump così com'è senza modifiche, volevo solo sapere se è letterale o se devo almeno cambiare il nome del database. So che può essere una domanda stupida, sono solo un po' confuso, grazie ancora per la tua risposta

andresmijares

8 gen 2012 20:19:38

Non so come esporti il tuo database, ma se usi lo strumento 'export' di phpmyadmin, allora non importa quale sia il nome del database. Puoi usare l'esportazione e importarlo nuovamente in qualsiasi altro database. In generale, riguardo al punto 2, penso che sia ok cambiare il nome del database.

Yoav Aner

9 gen 2012 17:09:30

L'OP è stato troppo zelante quando ha eseguito una ricerca e sostituzione sul file di esportazione del database, finendo per modificare le occorrenze di "wp_" all'interno di alcuni dati serializzati. La soluzione è essere più parsimoniosi nella ricerca e sostituzione includendo il backtick nell'espressione regolare, e poi aggiornare manualmente le chiavi rimanenti nel database dopo l'importazione.

Se stai migrando e cambiando il prefisso, e preferisci un approccio più manuale, procedi come segue (questo si occupa solo delle preoccupazioni dell'OP e non tratta dell'aggiornamento dell'URL del sito)

Esegui un backup e sposta il tuo file SQL di esportazione del database nel nuovo ambiente (il mio esempio assume un nome file di backup_YYYY-MM-DD.sql)
Esegui una ricerca e sostituzione di massa sul file SQL per modificare i nomi delle tabelle utilizzando il tuo nuovo prefisso (PRIMA di importare il file SQL!). Un modo per farlo potrebbe essere utilizzare un one-liner Perl come: perl -p -i.bak -e "s/`wp_/`myprefix_/g" backup_YYYY-MM-DD.sql
Importa i tuoi dati SQL nel database
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)) where option_name like 'wp_%'
Aggiorna tutte le chiavi all'interno di _user_meta che contengono il prefisso hard-coded: update myprefix_usermeta set meta_key = concat('myprefix_',substr(meta_key,4)) where meta_key like 'wp_%'

Tom Auger

7.1K

24 mag 2011 02:12:52

Ho utilizzato il plugin WP Migrate, che sostituisce gli indirizzi http e i percorsi delle cartelle. Ho avuto un unico problema durante l'importazione, ma l'ho risolto inserendo le seguenti righe all'inizio del file 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 Search And Replace (v2.1) suggerito da @Yoav, ma continua a danneggiare i miei dati serializzati.

Ricardo Martins

101

10 lug 2012 17:40:08

Commenti

Ciao Ricardo, benvenuto su WordPress Answers! L'area in cui hai postato è riservata alle risposte alla domanda originale. Anche se la tua domanda è correlata, dovresti pubblicarla come una domanda separata. In questo modo avrai molte più possibilità di ottenere una risposta.

Chris_O

11 lug 2012 13:02:20

Otto 32.8K · Accepted Answer · 2011-02-10T20:45:26Z

Ecco dove si trova il tuo problema:

Ho poi modificato il file .sql risultante per aggiornare tutti i percorsi dei file e i riferimenti agli URL in modo che puntino al nostro sito di produzione.

Non puoi farlo. WordPress memorizza molte opzioni come "dati serializzati", che contengono sia il contenuto testuale delle cose sia la loro lunghezza. Quindi, quando modifichi l'URL e la lunghezza cambia, i dati serializzati non sono più corretti e PHP li rifiuta.

Il problema a lungo termine è che, fondamentalmente, lo stai facendo nel modo sbagliato. Se stai configurando un sito di sviluppo i cui dati verranno migrati, allora dovrebbe avere lo stesso URL del tuo sito di produzione fin dall'inizio. Puoi modificare manualmente il tuo file HOSTS per assegnare a quel dominio di produzione (come example.com) un indirizzo IP diverso (come 127.0.0.1) e così l'URL "di produzione" diventerà il sito di sviluppo, solo per te. Quindi puoi creare i tuoi dati, link e tutto il resto utilizzando quell'URL di produzione, e quando migrerai i dati, nulla dovrà essere modificato.

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

E anche se esito a suggerirlo, c'è un modo per modificare il codice core di WordPress per gestire queste serializzazioni rotte. 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 valida a lungo termine. Dovrebbe essere utilizzata solo per farti ripartire e funzionare al momento. Nel lungo periodo, devi correggere il tuo processo di sviluppo in modo da non dover fare questo tipo di manipolazione degli URL fin dall'inizio.