WordPress WP-CLI: simulare la sostituzione di percorsi serializzati prima di migrare

Guida basata su interventi documentati. Dry-run di otto WordPress completati correttamente, con decine di migliaia di sostituzioni candidate e nessuna modifica al database.

Problema

Nel trasferimento di più siti WordPress è necessario aggiornare path e URL che possono essere presenti in opzioni, post meta e oggetti PHP serializzati. Una sostituzione SQL diretta non è sicura perché alterare la lunghezza delle stringhe compromette la serializzazione.

Inventario dopo rsync

Prima di modificare il database, confrontare siteurl, home, il percorso ABSPATH, le directory degli upload e gli eventuali URL hardcoded nei file di configurazione. In WP-CLI usare la versione PHP compatibile con il sito.

Procedura di dry-run

cd /var/www/SITO/web
php8.3 /usr/local/bin/wp core version
php8.3 /usr/local/bin/wp option get siteurl
php8.3 /usr/local/bin/wp search-replace \n '/PERCORSO_OLD/' '/PERCORSO_NEW/' \n --all-tables-with-prefix --precise --recurse-objects \n --dry-run --report-changed-only

Modificare i percorsi di esempio e usare il PHP CLI realmente supportato. Non includere nel log credenziali o token contenuti nelle righe sostituite.

Risultato verificato

In una migrazione di otto istanze WordPress, tutti i dry-run sono terminati senza errori; il riepilogo riportava 47.163 sostituzioni serializzate potenziali. Proprio perché si trattava di un dry-run, il database non era ancora stato modificato: il risultato positivo conferma la fattibilità, non il completamento del cutover.

Applicazione definitiva

Solo dopo backup SQL e verifica delle diff, eseguire il comando senza --dry-run in finestra di manutenzione. Verificare contenuti, opzioni, plugin, cache, URL canonici e reindirizzamenti.

Errore da evitare

Non usare sed o UPDATE ... REPLACE() su valori PHP serializzati senza gestire il formato. WP-CLI è progettato per gestire molti di questi casi.