In breve: un errore di restore WordPress serializzazione compare quando un valore strutturato nel database non può più essere decodificato. Succede spesso dopo sostituzioni manuali di URL che alterano le lunghezze memorizzate, ma può dipendere anche da dump troncati, codifica incoerente o dati già corrotti.
Indice dei contenuti
Restore WordPress serializzazione: perché fallisce
WordPress, temi e plugin possono salvare array e oggetti in forma serializzata. Nel formato PHP, le stringhe includono la propria lunghezza. Se una sostituzione SQL cambia il testo senza aggiornare quel numero, il valore diventa incoerente e unserialize() può generare errori o restituire dati incompleti.
La causa non è sempre una ricerca e sostituzione. Un esportazione interrotta, un import parziale, differenze di codifica, escaping errato o colonne tagliate possono produrre sintomi simili. Anche un messaggio che cita un plugin può indicare soltanto il punto in cui quel componente legge il valore danneggiato.
Individuare tabella, riga e valore danneggiato
- Conserva l’errore completo, l’orario e l’azione che lo attiva.
- Controlla log PHP e WordPress in modo protetto e individua opzione, meta o componente coinvolto.
- Confronta dimensione e completezza del dump con il backup originale.
- Lavora su una copia in staging e salva un nuovo backup prima di ogni correzione.
- Modifica il minimo insieme di dati e verifica subito il risultato.
Evita di eseguire tentativi globali sul database di produzione. Prima di toccare una riga, esportala e registra chiave primaria, tabella e valore precedente. Se il dato appartiene a un plugin, verifica se esiste una procedura ufficiale di rigenerazione: ricostruirlo dall’applicazione può essere più sicuro di editarlo a mano.
Sostituire gli URL senza rompere la serializzazione
Per una migrazione usa uno strumento consapevole dei dati serializzati. Il comando wp search-replace di WP-CLI gestisce i valori serializzati e offre --dry-run per mostrare quante sostituzioni verrebbero eseguite senza scriverle. Specifica con precisione URL vecchio e nuovo, protocollo e variante con o senza www.
Esegui prima il dry-run, controlla tabelle e conteggi, poi crea un backup immediatamente precedente alla modifica. Non usare un REPLACE() SQL globale su colonne che possono contenere dati serializzati. Evita inoltre sostituzioni troppo generiche del solo dominio, perché possono coinvolgere indirizzi email, percorsi o valori che non devono cambiare.
Le opzioni home e siteurl possono essere aggiornate con strumenti WordPress adeguati, ma non esauriscono tutte le occorrenze. Widget, blocchi, menu, meta e impostazioni dei plugin possono contenere riferimenti separati.
Recupero e verifiche dopo il ripristino
Se conosci l’operazione che ha corrotto molte righe, il percorso più affidabile è spesso ripristinare un backup integro e ripetere la migrazione con uno strumento sicuro. Una riparazione manuale diffusa può lasciare errori silenziosi. Se il backup è l’unica copia, duplicalo prima di procedere e conserva l’originale immutato.
Dopo la correzione verifica accesso, homepage, articoli, media, menu, widget, moduli, cron e funzioni del plugin coinvolto. Rigenera i permalink tramite WordPress quando necessario e svuota le cache pertinenti. Cerca ancora il vecchio URL con un dry-run e controlla che non compaiano nuovi avvisi di serializzazione.
Nel ticket indica dominio, origine del backup, strumento di esportazione e ripristino, sostituzioni eseguite, testo dell’errore e tabella sospetta. Non allegare pubblicamente un dump del database: può contenere credenziali, dati personali e token.
Guide Xlogic correlate
- Il backup WordPress contiene l'URL dell'ambiente sbagliato
- L'URL degli allegati WordPress punta al dominio sbagliato
- WordPress in loop tra URL con www e senza www
Fonti tecniche
- WordPress Developer Resources — Migrating WordPress
- WordPress Developer Resources — wp search-replace
- WordPress Code Reference — update_option
Domande frequenti
Posso usare REPLACE direttamente in SQL?
È rischioso sulle colonne che contengono dati serializzati, perché può cambiare una stringa senza aggiornarne la lunghezza memorizzata.
Il dry-run modifica il database?
No. Mostra le sostituzioni previste; resta comunque necessario controllare parametri e creare un backup prima dell'esecuzione reale.
Conviene riparare tutte le righe a mano?
Se la corruzione è estesa, è spesso più affidabile ripristinare una copia integra e ripetere la migrazione con uno strumento serializzazione-aware.
Conclusione
Un errore di serializzazione dopo il restore WordPress richiede di identificare il dato danneggiato e la modifica che l’ha alterato. Lavora in staging, conserva un backup integro e usa strumenti che aggiornano correttamente i valori serializzati.