Come spostare la cartella wp-content esistente di WordPress insieme al database su un nuovo server e con un nuovo nome di dominio?

11 feb 2013, 22:50:19
Visualizzazioni: 13.6K
Voti: 4

Sto utilizzando WP 3.5.1 su uno stack LEMP (su Linode)...

Ho una cartella wp-content per un sito WP insieme a un backup completo del database. L'URL del sito era qualcosa come:

test.example.com

Voglio rendere operativo il sito sul mio server personale all'indirizzo:

test.mydomain.com

E una volta completato il sito e dopo che le modifiche DNS avranno effetto, voglio che l'URL del sito sia:

myclientsdomain.com

Qual è il metodo preferito (e si spera più semplice) per gestire trasferimenti di server e cambi di dominio come questo? Cerco una risposta passo-passo, che tenga conto di tutte le situazioni descritte sopra sia per i file che per il database.

1
Commenti

Il Codex ha una guida piuttosto completa.

Milo Milo
20 feb 2013 02:21:46
Tutte le risposte alla domanda 7
1

C'è una guida passo passo molto utile su come spostare WordPress nel Codex. È quello che seguo quando cambio dominio.

Spostare i file è abbastanza semplice. Sono i riferimenti hard-coded nel database che sono complicati. Tuttavia, la ricerca e sostituzione serializzata si occuperà di tutte le modifiche al database. In passato ho usato il plugin Velvet Blues, ma lo script Search and Replace è davvero eccellente.

20 feb 2013 03:26:57
Commenti

Sì, è esattamente quello che ho linkato per la ricerca e sostituzione serializzata. È praticamente perfetto sotto tutti gli aspetti e rende il trasferimento del sito estremamente semplice.

helgatheviking helgatheviking
24 feb 2013 05:43:35
2

Utilizzo l'ottimo plugin Duplicator per completare questa stessa procedura regolarmente.

http://wordpress.org/extend/plugins/duplicator/

Il plugin è completamente supportato e ci sono ottime FAQ disponibili qui:

http://lifeinthegrid.com/labs/duplicator/

Il plugin creerà un backup .zip sia del tuo database che dei file e un installer .php che dovrai inserire nella tua nuova directory root. Basta inserire le nuove informazioni del database e il plugin farà il resto.

È probabilmente il mio plugin preferito per WordPress fino ad oggi.

Se hai bisogno di aiuto lungo il percorso, fammelo sapere.

20 feb 2013 03:28:17
Commenti

Utilizzo questo plugin SEMPRE per i siti dei clienti, posso creare una copia esatta del loro WordPress e installarla sul mio server di sviluppo, apportare le mie modifiche e poi riportare una copia esatta sul loro server se necessario

JasonDavis JasonDavis
2 mar 2013 19:11:17

Sì, faccio esattamente la stessa cosa. Questo, abbinato al plugin di backup su Dropbox (se riuscissi a farlo funzionare al 100% su tutti i siti dei clienti), la vita è bella.

cunningfox cunningfox
2 mar 2013 22:50:45
1

Dovrai considerare alcune cose (più avanti nella risposta), ti suggerisco i seguenti passaggi:

Esegui il backup dei tuoi file e del database

Questo è abbastanza autoesplicativo. Farai molte operazioni di manipolazione dei dati, quindi assicurati che l'originale sia al sicuro.

Trasferisci i tuoi file

Il modo più veloce per farlo è avere un host che permetta di importare directory da un altro server. Questo può essere fatto fornendo i dettagli FTP e definendo la directory di destinazione.

Poiché i server hanno una connessione internet generalmente molto più veloce di quella degli utenti, questo è il metodo preferibile per trasferire i dati. Puoi anche usare la riga di comando per eseguire manualmente questi comandi.

L'opzione più lenta è generare un file ZIP, scaricarlo, caricarlo sul nuovo server e decomprimerlo. Se non hai la possibilità di fare altrimenti, prendi la strada più lunga - scarica tutto e carica tutto. E vai a prendere un caffè mentre i file vengono trasferiti :)

Trasferisci il tuo database

Anche in questo caso, molti host offrono la possibilità di importare un database esistente in uno nuovo, persino da un altro server (ovviamente, il tuo vecchio server deve accettare connessioni dati esterne).

Se puoi farlo, ottimo, altrimenti puoi sempre esportare/importare il tuo database.

Imposta il nuovo (sotto)dominio sulla tua nuova directory

Sul tuo nuovo server, assicurati che i file siano configurati come nel vecchio server e punta il tuo sottodominio alla stessa directory che usavi nel vecchio server (di solito la root di WordPress).

Modifica il wp-config.php

Salva il nuovo wp-config.php. Dovrai solo modificare i dettagli di connessione al database.

Carica il nuovo URL

A questo punto WordPress dovrebbe essere configurato, ma utilizzerà ancora il vecchio SiteURL e AdminURL, quindi non potrai accedere. Modifica questi valori nella tabella options del tuo nuovo database. I due valori che cerchi sono siteurl e home. Inserisci qui il tuo nuovo dominio.

Controlla il login e il tuo sito

Ora tutto dovrebbe funzionare, potrai accedere, modificare e scrivere, oltre a utilizzare il sito. L'unico problema potrebbe essere che i tuoi articoli contengano ancora il vecchio URL per immagini e allegati.

Se i tuoi articoli contengono il vecchio URL, o se non sei sicuro, controlla il database nella tabella posts.

Puoi farlo cercando direttamente nel tuo database o usando uno script come Serial Search and Replace. Se trovi il tuo vecchio URL, dovrai sostituirlo manualmente o automaticamente. Io preferisco farlo automaticamente e controllare eventuali errori dopo.

Controlla le altre tabelle

Verifica anche se le altre tabelle contengono il vecchio URL. Potrebbe essere un po' complicato da sostituire, ma è necessario per trasferire completamente il sito.

Rigenera i tuoi Permalink

Per sicurezza, salva nuovamente le impostazioni dei Permalink per ricrearli.

Controlla il tuo sito

Per favore, non dimenticare di controllare DAVVERO il tuo sito dopo il trasferimento. Verifica tutte le funzioni, specialmente elementi AJAX, moduli di contatto, mappe, ecc., poiché hanno maggiori probabilità di fallire rispetto a semplice PHP/HTML.

Tempo per una birra :)

Cose a cui prestare attenzione!!

Come sempre, nulla che sia stato creato manualmente, trasferito manualmente e modificato automaticamente è infallibile. Ecco alcune trappole comuni in cui è facile cadere, ma che possono anche essere evitate facilmente.

  • Plugin mal codificati (Salvano l'URL del tuo sito invece del percorso relativo e usano le funzioni di WordPress per recuperare l'URL completo. Potrebbero esserci anche molti problemi con il tuo AjaxURL.)
  • Problemi di codifica (Assicurati assolutamente di usare la stessa codifica su entrambi i server e database!!! Di solito, se usi la raccomandata UTF-8, dovrebbe andare bene)
  • Dati serializzati (Questo è il problema più grande che potresti incontrare. Se usi un plugin come Tablepress, dove un'intera tabella è memorizzata in un array serializzato, si romperà non appena sostituirai qualcosa automaticamente. Se hai dati di questo tipo, cerca una funzione di esportazione/importazione in questi specifici plugin e usala come passaggio aggiuntivo. Se non hanno questa funzione, dovrai farlo manualmente)
  • Impostazioni del server (Può facilmente accadere che il tuo sito non funzioni sul nuovo server a causa di impostazioni standard. Assicurati di avere risorse sufficienti disponibili!)
  • URL hardcoded nel tuo tema (anche se non dovrebbe accadere, succede troppo spesso e rompe immagini e link non appena il vecchio sito non è più disponibile)
  • Problemi di cache (Non usare gli stessi file di cache del vecchio server. Il modo migliore sarebbe disattivare la cache prima di esportare il sito, oltre a svuotare tutte le cache)
  • Presumere che tutto funzioni quando cambi le impostazioni per la seconda volta sul tuo server (controlla sempre tutto di nuovo)
  • Opzioni nei tuoi plugin e tema (Vecchi indirizzi email, ecc.)

Dovrebbe essere tutto. Sembra molto da fare, ma in realtà la maggior parte è automatica. Devi solo pensare a tutto ciò che POTREBBE andare storto e verificare se è successo :)

Divertiti!

26 feb 2013 13:02:45
Commenti

Ottimo articolo, Ora della birra dovrebbe essere nel Codex!

brasofilo brasofilo
26 feb 2013 16:54:59
7

Non è necessario utilizzare plugin, script o conoscenze di SQL. È sufficiente un semplice blocco note per effettuare la migrazione. Dovrai caricare tutti i file di WordPress sul nuovo server e modificare solo 3 valori nel file wp-config.php (nella cartella principale di WordPress): define('DB_NAME', 'il_tuo_nuovo_nome_db'); define('DB_USER', 'il_tuo_username_db'); define('DB_PASSWORD', 'la_tua_password_db');

Successivamente, se stai utilizzando un client MySQL come phpMyAdmin sul server attuale, devi esportare il database in un file, aprire il tuo_db_dump.sql con il blocco note, cercare e sostituire tutte le occorrenze di test.example.com con test.miodominio.com e infine importare il db_dump modificato nel nuovo database (che hai definito in wp-config.php). Questo è tutto.

22 feb 2013 23:33:03
Commenti

Una semplice ricerca e sostituzione fallirà quasi nel 99% dei casi di migrazione di dominio perché parte dei dati, in particolare i widget, sono serializzati e bisogna modificare sia le dimensioni delle stringhe che il contenuto.

Mark Kaplun Mark Kaplun
26 feb 2013 08:18:09

Non posso essere d'accordo con te. Ho spostato molte installazioni WordPress con questo metodo e ha sempre funzionato. Nel database quasi tutte le sostituzioni vengono fatte con i post guid. Solo poche sostituzioni vengono fatte in wp_options (come siteurl, home). Posso concordare che alcuni dati siano serializzati, ma non si applica al nostro URL di dominio. Un widget progettato correttamente usa bloginfo('url'); non un URL diretto, quindi non dobbiamo preoccuparci dei dati serializzati.

bigwolk bigwolk
26 feb 2013 12:29:34

sì, se pianifichi in anticipo o sei semplicemente fortunato potrebbe funzionare, ecco perché ho detto 99% ;), ma la domanda è generale. E questo deriva dalla mia esperienza personale.

Mark Kaplun Mark Kaplun
26 feb 2013 12:42:32

Quindi abbiamo esperienze diverse ;) Direi che questo metodo FUNZIONERÀ nel 99% dei casi. Forse mi sbaglio, perché lavoro con wp solo da pochi anni, ma non ho mai incontrato resistenze durante lo spostamento di wp, nemmeno con plugin e widget attivati.

bigwolk bigwolk
26 feb 2013 12:54:16

Immagino dipenda da cosa usi sul sito. La mia brutta esperienza è stata con siti semplici... Il punto è che, come ha sottolineato @helgatheviking, esiste uno strumento gratuito che esegue la ricerca e sostituzione tenendo conto della serializzazione, quindi non c'è bisogno di rischiare anche se sei sicuro al 99% di vincere.

Mark Kaplun Mark Kaplun
26 feb 2013 13:02:08

sì, funzionerà nel 99% dei casi, ma perché indirizzare male proprio l'1%? La tua risposta dovrebbe includere l'avvertenza che potrebbe invalidare alcuni dati. In un mondo ideale tutti i plugin sono codificati perfettamente, ma io stesso ho incontrato questo problema, non viviamo in un mondo perfetto.

Milo Milo
26 feb 2013 17:29:11

Concordo sul fatto che non viviamo in un mondo perfetto e che c'è sempre una certa possibilità di fallimento. Entrambi avete ragione. Lui ha chiesto il modo più diretto per la migrazione e penso che questo lo sia. E funzionerà nella maggior parte dei casi. Con un rischio dell'1% di fallimento, posso rischiare, se dovesse essere il modo più semplice. Questa è la mia proposta per risolvere il problema. Se posso chiederti, potresti inviarmi alcuni link per plugin o widget che potrebbero creare problemi con questo tipo di migrazione? Finora non ne ho visti.

bigwolk bigwolk
27 feb 2013 19:44:36
Mostra i restanti 2 commenti
11

Quello che faccio è:

  1. Creare un nuovo database sul server di destinazione. Importare il file SQL. Eseguire le seguenti query SQL sul nuovo database:

    UPDATE wp_options SET option_value = replace(option_value, 'test.example.com', 'test.miodominio.com') WHERE option_name = 'home' OR option_name = 'siteurl';
    
    UPDATE wp_postmeta SET meta_value = replace(meta_value, 'test.example.com', 'test.miodominio.com') WHERE meta_key = '_menu_item_url';
    
    UPDATE wp_posts SET guid = replace(guid, 'test.example.com','test.miodominio.com');
    
    UPDATE wp_posts SET post_content = replace(post_content, 'test.example.com', 'test.miodominio.com');
    
  2. Caricare i file di WordPress sul server di destinazione.

  3. Caricare la cartella wp-content, sovrascrivendo i file predefiniti di WordPress.
  4. Configurare il file wp-config.php normalmente, utilizzando il nome del database, l'utente e la password del database creato.
  5. Andare nella Dashboard e cambiare manualmente tutte le occorrenze di test.example.com nei widget (questi non possono essere modificati via query SQL perché sono serializzati nel database).
  6. Quando sarà il momento di passare a myclientsdomain.com, ripetere le query SQL e le correzioni dei widget sopra indicate.

A seconda del tema e dei plugin utilizzati, potrebbero esserci ulteriori modifiche da apportare nel database o nella Dashboard. Queste dovranno essere individuate autonomamente e modificate man mano che si trovano.

Avvertenza: non è un metodo perfetto e può essere piuttosto laborioso spostare WordPress tra domini. Un'altra cosa che ho visto fare è aggiungere quanto segue al file wp-config:

define('WP_HOME','http://'. $_SERVER['SERVER_NAME']);
define('WP_SITEURL','http://'. $_SERVER['SERVER_NAME']);

Questo aiuterà il sito a funzionare su qualsiasi dominio si trovi, ma sarà comunque necessario gestire gli URL hard-coded nei contenuti, nelle opzioni e nei menu. Non l'ho testato personalmente e non so se sia necessario rimuovere le opzioni corrispondenti dal database per farle funzionare.

Aggiornamento: Avrei dovuto immaginare che ci sarebbe stato un plugin per gestire la parte del database http://wordpress.org/extend/plugins/wp-migrate-db/

20 feb 2013 02:46:15
Commenti

Raccomando vivamente di NON eseguire i comandi SQL di aggiornamento suggeriti sopra. La tabella delle opzioni in particolare può contenere molti dati serializzati - semplici operazioni di ricerca/sostituzione su dati serializzati corromperanno tali dati

eddiemoya eddiemoya
20 feb 2013 03:06:42

Suggerisco di rimuovere completamente quella parte della tua risposta, e anzi di mettere in guardia contro tecniche manuali di ricerca/sostituzione come quella o l'uso del comando 'sed'.

eddiemoya eddiemoya
20 feb 2013 03:07:17

Non sto facendo una semplice ricerca/sostituzione. Sto limitando i comandi a modificare campi che NON contengono dati serializzati, e infatti menziono di non usare tali comandi per modificare informazioni memorizzate nei widget poiché quei dati SONO serializzati.

Sulla tabella delle opzioni in particolare sto usando la clausola where " WHERE option_name = 'home' OR option_name = 'siteurl';" per evitare di modificare dati serializzati.

Michael Dozark Michael Dozark
20 feb 2013 03:33:21

Ora ho capito, la prima volta che l'ho letto mi era sfuggita la clausola WHERE. Scusa per quello. Tuttavia, non dovresti aver bisogno di modificare i valori home e siteurl nella tabella delle opzioni, è proprio a questo che servono WP_HOME/WP_SITEURL. L'utilizzo di queste definizioni sovrascrive i valori nella tabella delle opzioni, aggiungendo la definizione aggiuntiva WP_RELOCATE fa sì che le prime due sostituiscano le impostazioni nella tabella delle opzioni.

eddiemoya eddiemoya
20 feb 2013 04:00:05

Inoltre, sono abbastanza sicuro che non dovresti modificare i guid nella tabella dei post. Questi non sono pensati per essere usati come URL ma piuttosto come ID univoci. Edit: Ho verificato - per gli allegati c'è un caso in cui è necessario modificare il guid ma non si applica a un semplice cambio di dominio.

eddiemoya eddiemoya
20 feb 2013 04:04:38

Noterai che l'uso della definizione di WP_HOME e WP_SITEURL era separato dal resto della mia risposta e ho anche specificato "Non l'ho testato personalmente e non so se è necessario rimuovere le opzioni corrispondenti dal tuo database per farle funzionare." Ho riconosciuto di non saperne di più su quel particolare argomento, ma che era diverso dall'uso del database.

I GUID non sono solo ID univoci e modificarli non è sempre necessario ma non è dannoso.

Michael Dozark Michael Dozark
20 feb 2013 04:22:02

Va bene, stavo solo offrendo informazioni più rilevanti riguardo a quelle due opzioni, non volevo creare una discussione. Per quanto riguarda i GUID, possono effettivamente essere dannosi. Sono univoci a livello globale. Globale in questo caso significa proprio in tutto il mondo, ecco perché includono informazioni sul dominio. Quindi qualsiasi sistema esterno che interagisce con il tuo sistema (ad esempio un aggregatore RSS), perderà traccia di tutti i tuoi contenuti.

eddiemoya eddiemoya
21 feb 2013 21:56:32

L'OP ha detto che sta trasferendo dal suo sito di sviluppo. Questo sito non dovrebbe ancora essere aggregato, e se lo è, perderli è preferibile poiché non vuoi che i link e i contenuti del tuo spazio di sviluppo finiscano in fonti esterne.

Michael Dozark Michael Dozark
26 feb 2013 20:33:06

"Affinché il campo GUID sia 'globalmente' univoco, è una convenzione accettata utilizzare l'URL o una rappresentazione dell'URL. Quindi, se possiedi example.com, sei l'unico a utilizzare example.com e quindi è univoco per te e il tuo sito." <- Questo può potenzialmente rompersi se il GUID contiene il dominio di sviluppo (se lo spazio di sviluppo viene aggregato da fonti esterne, ad esempio). Improvvisamente, ci sono due post con lo stesso GUID. Meglio che contenga il dominio live in modo da seguire questa regola, secondo me.

Michael Dozark Michael Dozark
26 feb 2013 20:37:25

P.S. Spero che i miei commenti non risultino antagonisti o simili; non è questa l'intenzione. Non cerco di essere in disaccordo, solo di esprimere un'opinione diversa. :)

Michael Dozark Michael Dozark
26 feb 2013 20:56:33
Mostra i restanti 6 commenti
0

Una risposta precedente aveva questo, ma ecco una guida passo passo con qualche altro suggerimento:

  • Non installare WP
  • Trasferisci tramite FTP l'intera directory originale di WP in una nuova directory (vedi sotto se manca qualcosa)
  • Importa il file SQL con phpMyAdmin dal pannello di controllo del tuo server.
  • Carica via FTP searchreplacedb.php nella directory dove si trova WP.
  • Esegui searchreplacedb.php dal tuo browser (eliminalo dopo!!!)
  • Prenditi una pausa e fattura al tuo cliente $75!

    (searchreplacedb.php è disponibile GRATUITAMENTE su: interconnectit.com/products/search-and-replace-for-wordpress-databases ... hanno anche le istruzioni).

Se hai solo la cartella dei contenuti di WP hai un altro problema. Devi procurarti il resto dell'installazione di WP della STESSA IDENTICA VERSIONE. Cerca nel database se non sai quale versione di WP è installata. È facile trovare online versioni precedenti. Sistemare tutto al posto giusto come prima, usando FTP per configurare le nuove cartelle, se vuoi che il sito appaia esattamente come prima. Non visitare il sito dopo aver caricato il database e i file di WP se ti manca qualcosa, altrimenti utilizzerà il tema predefinito o disattiverà i plugin. Ho perso le impostazioni dei plugin e ho dovuto rifare tutto, quindi pensa bene e procedi con calma.

Se hai già una sottocartella o un addon, o il nuovo sito ne avrà bisogno, pianifica in anticipo. Non sostituire semplicemente l'URL senza tenere conto della necessità di una nuova cartella o dell'assenza di una nuova cartella. Potresti dover eseguire searchreplacedb per 'cartella/url' prima di tornare a 'url', ecc. Altrimenti potresti incasinare un 'addon' trasformandolo in un 'sito principale con installazione in sottodirectory' o altre simili assurdità!

Se la nuova struttura corrisponde alla vecchia struttura e hai l'intera directory di WP, puoi farlo più facilmente e rapidamente di quanto non sia leggere questo post! Metti il programma nella stessa directory dove hai caricato WP per i migliori risultati, come dicono le istruzioni, poiché ha un autoconfig.

Se non hai accesso FTP, accesso al pannello di controllo o accesso SQL, hai davvero bisogno di un server migliore e potresti essere sfortunato.


Prova il search and replace consigliato in altri post e, se sei fortunato, hai una versione precedente di WP e rientra nei parametri necessari, funzionerà; un modo davvero fastidioso per giocare alla roulette russa con il tuo sito.

Inoltre, non modificare mai i dati con il blocco note a meno che tu non sappia che non ci sono stringhe più lunghe di quelle che può accettare. Ecco un bel errore che potresti metterci settimane a trovare! Se devi guardarli, solo guarda, non salvare. Dovresti dimenticare che il blocco note esista e usare Notepad++, ma modificare manualmente i dati serializzati in un editor di testo è tanto grave quanto cercare e sostituire in phpMyAdmin; non farlo.

Potresti cercare "sql serialized data". La risposta breve è che il cerca e sostituisce distruggerà i dati serializzati in un SQL. I database di WP hanno dati serializzati... sempre più spesso oggigiorno.

L'ho fatto troppe volte e ho avuto un successo marginale e ho sbattuto la testa contro il muro molte volte prima di finalmente fare una ricerca adeguata. Ora è una passeggiata.

23 feb 2013 04:06:32
0

Ho trasferito numerosi siti da un server/dominio a un altro in questo modo, e tutto ciò di cui solitamente hai bisogno è un backup e la tua cartella wp-content, che sembra tu abbia. Ecco il metodo che seguo:

  1. Installa WordPress sul nuovo sito. Puoi usare qualsiasi metodo preferisci per questo, alcuni host offrono installazioni con un click, altrimenti procedi semplicemente secondo il tuo metodo preferito.
  2. Sovrascrivi la cartella wp-content con la copia che hai. Questo assicura che tutti i tuoi plugin, file caricati ecc. siano come quelli del vecchio server.
  3. Sovrascrivi il database con la copia che hai. Io solitamente lo faccio usando phpMyAdmin con la funzione Importa. Una cosa da controllare qui è che se il tuo backup non include istruzioni DROP, dovrai eliminare prima tutte le tabelle nel database.
  4. Se stai cambiando il nome del dominio, dovrai sfogliare la tua tabella wp_options in phpMyAdmin e aggiornare l'opzione "site_url". C'è un'altra opzione chiamata "home" che puoi aggiornare, ma non sei obbligato a farlo poiché può essere modificata nell'admin di WordPress una volta che il tuo sito è operativo.

Fatto!

Questo dovrebbe essere tutto ciò che devi fare per far funzionare il tuo sito. Una volta operativo, sarebbe prudente controllare qualsiasi impostazione specifica di plugin/tema che potrebbe fare riferimento al vecchio sito e rigenerare i tuoi permalink.

26 feb 2013 16:45:25