WordPress stores absolute URLs in dozens of database tables, so a domain change or an SSL move leaves old addresses scattered through posts, options and plugin settings: a search and replace is how…

Esecuzione di una ricerca e sostituzione nel database di WordPress

WordPress memorizza URL assoluti in decine di tabelle di database, quindi un cambio di dominio o uno spostamento SSL lascia indirizzi vecchi sparsi in post, opzioni e impostazioni plugin: una ricerca e sostituzione è il modo per ripulirli in sicurezza. Questa guida copre i due metodi supportati per farlo in KPanel, perché un metodo terzo comune corrompe i dati, e come verificare il risultato.

Quando ne hai bisogno

Passaggio da http:// a https:// dopo l'abilitazione di SSL.
Cambio di dominio, ad esempio da old-brand.co.nz a new-brand.co.nz.
Dopo il push dello staging in produzione, quando il nome host dello staging è ancora incorporato nel database.
Ritiro di un vecchio host di asset e reindirizzamento di ogni URL di immagine contemporaneamente.
Correzione di un errore di battitura in massa su molti post, come un vecchio numero di telefono o un nome di prodotto non più disponibile.

Una ricerca e sostituzione riscrive righe in ogni tabella contemporaneamente e non esiste un'annullamento per singola riga. Esegui un backup prima di iniziare, ogni volta, anche per una modifica che sembra banale. KPanel ne crea uno automaticamente quando usi gli strumenti integrati descritti di seguito, ma se esegui il comando tu stesso sei responsabile di questo. Vedi Esecuzione di un backup.

Perché non puoi semplicemente eseguire un REPLACE SQL

Questo è l'errore più dannoso in assoluto nel lavoro con database WordPress, quindi vale la pena comprenderlo prima di scegliere un metodo.

WordPress memorizza impostazioni plugin, opzioni tema e dati widget come stringhe serializzate PHP. Una stringa serializzata registra la lunghezza di ogni valore al suo interno, come questo:

a:1:{s:3:"url";s:26:"http://old-domain.co.nz/x";}

Quel s:26 indica che l'URL è lungo 26 caratteri. Sostituisci http:// con https:// usando un semplice REPLACE() SQL e il testo diventa 27 caratteri mentre la lunghezza memorizzata continua a dichiarare 26. PHP rifiuta quindi di deserializzare l'intera opzione e l'impostazione torna silenziosamente a vuota. Le impostazioni della personalizzazione tema scompaiono, i cursori perdono le loro diapositive, le licenze plugin si auto-annullano.

La ricerca e sostituzione WP-CLI che KPanel esegue deserializza ogni valore, sostituisce al suo interno e reserializza con lunghezze corrette. Questo è il motivo per cui è l'unico metodo documentato qui.

Non eseguire mai UPDATE wp_options SET option_value = REPLACE(...) o l'equivalente in phpMyAdmin su un database WordPress. Sembra che abbia funzionato, segnala righe interessate, e distrugge silenziosamente ogni impostazione serializzata che ha toccato. Non c'è riparazione se non ripristinando un backup.

Metodo 1: La scheda di ricerca e sostituzione

Questa è la scelta giusta per quasi tutti. È disponibile su ogni piano WordPress.

Accedi a KPanel e fai clic su Websites nella barra laterale sinistra.
Fai clic sul sito.
Apri la scheda WordPress, quindi la sezione Quick Actions.
Trova la scheda Search & Replace e fai clic su Configure.
Inserisci il testo esistente in Find (old value).
Inserisci il nuovo testo in Replace with.
Lascia Dry run (preview only, no changes) selezionato e fai clic su Preview.

L'esecuzione a secco segnala quante sostituzioni verrebbero effettuate e suddivide il conteggio per tabella e colonna, così puoi vedere esattamente dove cambierebbe il risultato prima di impegnarti.

Quando l'anteprima sembra corretta:

Deseleziona Dry run.
Fai clic su Run.
Conferma il dialogo.

Un backup completo viene eseguito automaticamente prima che inizi la sostituzione e l'esecuzione copre tutte le tabelle incluse quelle create dai plugin.

Cerca la stringa più specifica che puoi. Sostituire old-domain.co.nz riscrive anche mail.old-domain.co.nz e staging.old-domain.co.nz, che è raramente quello che vuoi. Includere lo schema, come in https://old-domain.co.nz, mantiene il match stretto.

Metodo 2: WP-CLI dalla console

La console ti dà lo stesso motore con più controllo sui flag. È una delle sezioni che appaiono sui piani gestiti; su altri piani la striscia di schede mostra invece un link +8 on Managed.

Apri il sito, quindi WordPress, quindi Console. Il prompt inizia già con wp, quindi digita solo il resto del comando.

Visualizza l'anteprima prima:

search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables --dry-run

Poi eseguilo per davvero:

search-replace 'http://old-domain.co.nz' 'https://old-domain.co.nz' --all-tables

La console non esegue un backup per te. Il backup automatico pre-esecuzione si verifica solo quando usi la scheda Search & Replace nel Metodo 1. Se esegui il comando qui, esegui un backup tu stesso prima dalla scheda Backups del sito.

Flag utili:

Flag	Cosa fa
`--all-tables`	Include tabelle personalizzate create dai plugin, non solo quelle core di WordPress
`--dry-run`	Segnala cosa cambierebbe e non scrive nulla
`--precise`	Usa PHP anziché SQL per la sostituzione. Più lento, ma gestisce strutture serializzate complicate
`--skip-columns=guid`	Lascia da solo i GUID dei post (vedi sotto)
`--report-changed-only`	Riduce l'output alle tabelle che effettivamente hanno cambiato

Una nota sui GUID

Ogni post WordPress ha una colonna guid. Nonostante sembri un URL è un identificatore, non un link, e i lettori feed lo usano per dire se hanno già visto un elemento. Riscriverlo può fare riapparire ogni post nel tuo feed come nuovo.

Riscrivi i GUID quando stai cambiando dominio permanentemente e ricominciando da zero. Saltali con --skip-columns=guid quando stai solo passando da HTTP a HTTPS nello stesso dominio.

Cambio di dominio: utilizza invece la scheda Change Site URL

Se il punto intero è spostare il sito a un nuovo dominio, non iniziare con ricerca e sostituzione. La scheda Change Site URL, nella stessa sezione Quick Actions, aggiorna le opzioni siteurl e home ed esegue la sostituzione in tutte le tabelle in un'operazione, nell'ordine corretto. Farlo al contrario può lasciare WordPress incapace di caricare il suo stesso admin.

Dopo la sostituzione

Lavora attraverso questo elenco prima di ritenerti finito.

Flush della cache. Nella sezione Quick Actions, esegui Flush Cache. Se il sito usa la cache a pagina intera, purga dalla scheda WordPress, quindi Caching.
Flush delle regole di riscrittura. Esegui Flush Rewrites nella stessa sezione, o apri Settings, quindi Permalinks in wp-admin e fai clic su Save Changes senza cambiare nulla.
Purga la CDN se il sito è su di essa, da Performance, quindi Kapsule CDN. Vedi Purging the CDN Cache.
Carica il sito in una finestra privata così la cache del tuo browser non possa ingannarti.
Controlla il lucchetto. Un lucchetto mancante o di avvertimento dopo uno spostamento SSL significa che gli URL sono stati lasciati indietro: Fixing Mixed Content Warnings.
Clicca attraverso le pagine delicate. Slider della home page, il logo dell'intestazione, qualsiasi pagina costruita con un page builder, e il checkout su un negozio. Questi contengono gli URL che vivono in opzioni serializzate.
Cancella qualsiasi plugin di caching dalla sua stessa schermata di impostazioni.

Risoluzione dei problemi

L'esecuzione a secco segnala zero sostituzioni. La stringa non è nel database in quella forma esatta. Controlla una barra finale, un prefisso www., o lo schema. Prova a cercare solo il nome host nudo per primo per confermare che è lì.

Le immagini sono rotte dopo un cambio di dominio. Gli URL dei media vivono in wp_posts e wp_postmeta e vengono ripresi da --all-tables, ma una CDN o un plugin di ottimizzazione immagini può memorizzare nella cache le sue proprie copie riscritte. Purga la CDN e la cache del plugin, poi ricarica.

Le impostazioni sono scomparse dopo la sostituzione. Questo è il problema di serializzazione, e significa che la modifica è stata fatta con SQL grezzo piuttosto che attraverso gli strumenti qui. Ripristina il backup eseguito prima dell'esecuzione: Restoring From a Backup.

Gli URL di staging continuano a tornare. Qualcosa li sta ripopolando, di solito un push pianificato o un'opzione memorizzata nella cache. Controlla il flusso di lavoro in Using Staging: Pushing and Pulling e assicurati che Rewrite URLs sia selezionato quando fai il push.

Eseguire una ricerca e sostituzione nel database di WordPress