Controllo della migrazione di WordPress: spostare i file, i dati e i domini in modo sicuro

Definire ciò che si muove e che controlla il taglio

Una migrazione WordPress muove un'applicazione esistente e i suoi dati. Decidi se stai cambiando solo il server di hosting, o anche il percorso di dominio, URL o lo schema HTTPS. Scrivere le impostazioni attuali WordPress e Indirizzo del sito, la connessione del database, la posizione di upload e qualsiasi routing personalizzato. Una mossa del server e una modifica del dominio richiedono controlli diversi.

Assegna a una persona di approvare la copia finale e la modifica DNS. Confermare che è possibile accedere ai vecchi file, esportare il database, configurare la destinazione e modificare i relativi record DNS. Registra i record esistenti prima di cambiarli. La scelta di un piano di hosting non trasferisce il tuo sito web; organizza la migrazione con la persona responsabile della tua applicazione.

Creare un backup dei file e dei dati corrispondenti

Salvare i file WordPress e un'esportazione di database come un set di backup identificabile. Includere upload, temi, plugin e la configurazione necessaria per riconnettere l'applicazione. Il download della directory WordPress da solo non cattura un database memorizzato in MySQL o MariaDB. Registrare quando l'esportazione è stata presa e conservare una copia lontano dal server in sostituzione.

Controllare la destinazione PHP versione, estensioni richieste, compatibilità del database e spazio sia per l'applicazione ripristinata che per gli archivi temporanei. Confermare che il backup può essere aperto e ripristinato in un database separato. Trattare le credenziali nei file di configurazione come segreti e rimuovere i file di esportazione temporanei da directory pubblicamente accessibili una volta che il loro scopo è completo.

Pianificare e testare un ripristino completo di hosting

Separare una mossa di hosting da un cambiamento URL

Quando il dominio pubblico e i percorsi rimangono gli stessi, gli URL delle applicazioni esistenti di solito rimangono validi. Aggiornare la connessione del database di destinazione se il suo host, il nome del database o le credenziali differiscono. Provare utilizzando un metodo che conserva il nome host previsto, come un override local hosts-file, dove il vostro operatore lo supporta; questo cambia solo il dispositivo di prova, non DNS pubblico.

Scorrere il tavolo orizzontalmente se necessario.

Gestisci URL modificati senza interrompere i dati serializzati

Temi e plugin possono memorizzare valori strutturati contenenti sia testo che lunghezza. Un semplice sostituto del testo SQL può danneggiare i dati serializzati quando un vecchio URL e un nuovo URL hanno lunghezze diverse. Utilizzare uno strumento di migrazione WordPress-aware o WP-CLI se è disponibile WP-CLI, e rivedere la sua portata prima di applicare una modifica.

Su una copia restaurata, eseguire una corsa a secco prima, ispezionare le tabelle riportate e preservare un rollback esportazione. WP-CLI fornisce --dry-run e --skip-columns=guid; WordPress post GUIDs identificano il contenuto e non devono essere riscritti come collegamenti ordinari. Un comando Multisite ha bisogno di un'area di rete deliberata. Controllare le tabelle e la configurazione del plugin separatamente invece di sostituire ogni stringa corrispondente in ogni database.

Testare la destinazione senza attivare effetti collaterali vivi

Aprire la homepage, un post, ricerca, media, login e l'area di amministrazione sulla destinazione. Controllare i permalink, i beni mancanti, HTTPS reindirizza e gli errori delle applicazioni. Moduli di prova e flussi di negozio utilizzando un ambiente di prova appropriato. Mantenere una copia isolata dall'invio di messaggi reali del cliente, pagamenti di ricarica o webhook di produzione di registrazione durante le prove.

Per WooCommerce, verificare le variazioni di prodotto, gli aggiornamenti del carrello, il comportamento di checkout e la schermata di amministrazione dell'ordine. Un carico di pagina di successo è solo un test. Confrontare la destinazione con un breve elenco di funzioni aziendali che si utilizza e risolvere le differenze prima della copia finale. Registra qualsiasi impostazione di applicazione cambiata per il test in modo che possa essere rivisto prima del lancio.

Recensione WooCommerce hosting e configurazione negozio

Proteggere gli ordini e altre scritture durante il taglio DNS

Un negozio può ricevere nuovi ordini dopo il backup delle prove. Pianifica una pausa controllata in scritture o una sincronizzazione finale specifica dell'applicazione, quindi crea la copia coerente finale. Confronta i record di ordini più recenti e gli eventi di pagamento-provider con il punto di cutover approvato. Ripristinare un database più vecchio sui dati del negozio dal vivo può scartare le transazioni che sono avvenute in seguito.

Le cache DNS possono inviare i visitatori a diverse destinazioni durante la transizione. Decidi quale applicazione è autorevole per gli ordini e come gli scritti tardivi saranno trattati prima di commutare i record. Mantenere l'ambiente precedente disponibile per le indagini senza riaprire casualmente due negozi scrivibili. La guida DNS copre i cambiamenti di record; la decisione di migrazione ha anche bisogno di un chiaro proprietario per i dati delle applicazioni.

Controllare i record DNS prima di collegare la destinazione

Verificare il lancio e definire un rollback utilizzabile

Ripetere i controlli funzionali attraverso il pubblico DNS, ispezionare gli errori delle applicazioni e rivedere nuovi ordini o presentazioni sulla destinazione prevista. Se gli URL sono cambiati, testare gli indirizzi vecchi importanti e i loro reindirizzamenti. Controllare le impostazioni di indicizzazione, gli URL canonici e la mappa del sito in modo da una restrizione di staging o il nome host temporaneo non è portato in produzione.

Impostare le condizioni che giustificherebbero il rollback. Per un negozio dal vivo, la conversione di DNS da sola non sposta nuovi ordini creati di nuovo al vecchio database. Riconciliare nuovi dati prima di restituire il traffico, e mantenere un record della decisione finale di migrazione. Ritirare la vecchia installazione solo dopo la destinazione, copia di recupero e record aziendali sono stati verificati.

• Il set di backup finale e il database di destinazione corrispondono al cutover approvato.
• Gli URL pubblici, HTTPS, i moduli e le funzioni di store funzionano sulla destinazione.
• I nuovi ordini e le richieste sono registrati nell'applicazione prevista.
• Gli archivi temporanei e le impostazioni di sola prova sono stati esaminati.

Confronta i piani di destinazione WordPress