2009-09-18 14 views
5

Ho guardato attorno ai forum di Wordpress e non ho trovato nulla, quindi ho pensato di provare qui.Migrazione del database Wordpress

Se si dispone di una configurazione di Wordpress di staging/dev utilizzata per testare il nuovo plug-in e così via, come si fa a eseguire la migrazione dei dati nel database di staging nuovamente nel database di produzione? Esiste un metodo di "best practice di Wordpress" per farlo, o sono limitato a dover migrare manualmente le tabelle da un database all'altro?

risposta

1

Forse stai solo cercando la cosa sbagliata. Un plugin di backup non gestirà questo con facilità? So che esistono per tutti i grandi pacchetti CMS ...

1

I due metodi utilizzerebbero la funzione di esportazione/importazione sotto gli strumenti o la copia del database. Mi mando una copia del mio database di produzione ogni settimana usando il plug-in di WordPress Database Backup.

La funzione di importazione può essere problematico per lo spostamento di un blog wordpress come si deve configurare il file php.ini spesso perché il valore predefinito di file è possibile caricare su un'implementazione php ospitato tende ad essere troppo piccola per impostazione predefinita.

1

Volevo estrarre il database dal mio sito Web di wordpress di produzione in una copia di sviluppo offline del mio computer desktop in modo da poter modificare il sito e testarlo con un set completo di del contenuto del blog e della cronologia esistenti.

Ciò si è rivelato problematico, poiché non è stato possibile eseguire semplicemente un backup offline del database e importarlo nel database di sviluppo locale.

Il superamento di questi problemi nello spostamento dei dati dalla produzione al database di sviluppo può probabilmente essere utilizzato anche per l'altro modo, quindi penso che si possano semplicemente utilizzare queste linee guida per quello che si vuole fare, basta iniziare con dev i dati e spostarli a prod.

I problemi qui sono stati:

  1. le designazioni permalink per le post del blog sono tutti memorizzati nel database come sarebbero per la versione online , ma i miei offline copia non è al indirizzo di dominio, invece si trova nella directory localhost. Dunque quando lancio il sito localmente, sebbene la formattazione css e le immagini siano tutte a posto (i collegamenti dell'immagine sono relativi), i post attuali del blog non vengono visualizzati.
  2. molti dei link in tutto il link sito di nuovo fuori a internet, quindi se si cerca di accedere a archivi, o commenti, o categorie, o dei principali messaggi, si spediti fuori al Internet invece di rimanere nel database sul computer locale.

Per assicurarmi che stavo facendo bene, ho scaricato l'installazione wordpress che avevo sul mio computer locale e riavviato da zero.

Una volta ho avuto un pulito, nuovo wordpress installare e nuovo di zecca di default appena creata database locale per questo, ho aperto il database in phpMyAdmin e ha preso uno sguardo ai wp_posts

tavolo.All'interno di questo, ogni record (in altre parole, ogni post) ha una colonna intitolata "guid", che mostra la posizione di quel post. Ad esempio, il primo in una nuova, di default

installare contiene questo valore "guid":

http://localhost/wordpress/?p=1 

Se si guarda nella tabella wp_posts della versione on-line, si vedrà invece in questa posizione l'URL del tuo sito online.

Non è possibile importare le tabelle all'ingrosso nell'installazione locale, perché si importano tutti questi riferimenti esterni. Renderà la tua versione locale impossibile da navigare localmente.

Quindi, ho creato una copia di backup del database del mio sito online e l'ho salvata localmente come file .sql. Ho quindi aperto quel file in un editor di testo (ho usato Notepad ++, un grande software gratuito, ma potevi usare qualsiasi editor di testo). Le cose che bisogno di guardare fuori per:

  • Per qualsiasi motivo, le tabelle sul mio sito online non sono solo, ad esempio, "wp_posts" - sono "wp_something_posts" ... ci sono alcune lettere extra in là nei nomi delle tabelle .
  • Qualsiasi riferimento a http: // ... che contengono il mio url in linea invece di localhost/wordpress

di mantenerlo semplice diciamo solo fanno solo i post. Nella copia di backup del file .sql del tuo database online, trova l'inizio della tabella wp_posts. Assomiglierà a questo:

-- 

-- Table structure for table `wp_posts` 

-- 



DROP TABLE IF EXISTS `wp_posts`; 

CREATE TABLE `wp_posts` (

... e così via. Evidenzia tutto quanto sopra fino a poco sotto il commento che segna l'inizio del database nella parte superiore del file (dirà - Database: "il nome del tuo database") ed eliminalo. Poi vai alla fine della tua tabella wp_posts, e cancella tutto dopo di allora fino alla fine del file. Ora il tuo file contiene solo i tuoi post e nient'altro.

Salvare questo come documento separato. Chiamalo posts.sql o qualcosa del genere.

Ora, in questo file posts.sql, è necessario eseguire due azioni Trova/Sostituisci.

  1. trovare ogni istanza del nome le wp_something_posts tavolo e sostituirlo con wp_posts. È sufficiente eseguire se la copia di backup del database online non corrisponde a e corrisponde all'installazione locale pulita come come i nomi delle tabelle. Si desidera qualunque sia il nome della tabella in questo file per corrispondere a quello che il proprio database wordpress installato in locale ha come nome tabella . Se non fai corrispondere questi nomi allo , sei pronto a importare i post in una nuova tabella con nomi diversi, , che non ti servirà a tutti allo .
  2. Trova ogni istanza di http: // ... (sostituire l'elipsis con il vostro URL) e sostituirlo con http://localhost/wordpress (o qualunque sia l'url locale per la versione dev del sito è)

Ora salvare di nuovo il file, per assicurarsi che si' abbiamo questi cambiamenti impostati.

Ora che hai fatto questo, utilizzare phpMyAdmin per entrare nel database di WordPress sul computer locale, selezionare la scheda "import" e passare il selettore al file di posts.sql hai appena fatto, e quindi importare esso. Questo trarrà tutti i dati in quel file nella tua tabella wp_posts locale.

Al termine, sfoglia il tuo sito wordpress locale. Vedrai tutti i tuoi post lì dentro ora. Evviva!

Potrebbe essere necessario fare qualcosa di simile per un paio di altri tavoli se si desidera portare nei vostri commenti, tag, categorie e pagine statiche che hai creato, ecc

Mi rendo conto che questo è un processo contorto . Probabilmente c'è uno strumento là fuori da qualche parte che rende più facile questa attività, e se qualcuno ne conosce uno mi piacerebbe scoprirlo. Se qualcuno conosce un modo migliore di farlo manualmente rispetto a quello che ho descritto, mi piacerebbe saperlo anche io!

Fino ad allora, questo è il modo in cui ho capito come farlo. Spero che ti aiuti ad andare nella giusta direzione.

3

Ho uno script che mysqldump una copia del mio DB Wordpress di produzione, ripristina il mio test Wordpress installa & quindi corregge tutte le impostazioni di "produzione" & url nel DB di test.

Entrambi i database di prova di produzione & risiedono nello stesso server, ma è possibile modificare le impostazioni di mysqldump per eseguire il dump da un server mysql remoto & ripristinarlo su un server locale abbastanza facilmente.

Qui sono i miei script:

overwrite_test.coach_db_with_coache_db.sh

#!/bin/bash 
dbUser="co*******" 
dbPassword="*****" 
dbSource="coach_production" 
dbDest="coach_test" 
tmpDumpFile="/tmp/$dbSource.sql" 

mysqldump --add-drop-table --extended-insert --user=$dbUser --password=$dbPassword --routines --result-file=$tmpDumpFile $dbSource 
mysql --user=$dbUser --password=$dbPassword $dbDest < $tmpDumpFile 
mysql --user=$dbUser --password=$dbPassword $dbDest < /AdminScripts/change_coach_to_test.coach.sql 

change_coach_to_test.coach.sql

-- Change all db references from @oldDomain to @newDomain 

SET @oldDomain = 'coach.co.za'; 
SET @newDomain = 'test.coach.co.za'; 
SET @testUsersPassword = 'password'; 

UPDATE `wp_1_options` SET `option_value` = REPLACE(`option_value`,@oldDomain,@newDomain) WHERE `option_name` IN ('siteurl','home','fileupload_url'); 
UPDATE `wp_1_posts` SET `post_content` = REPLACE(`post_content`,@oldDomain,@newDomain); 
UPDATE `wp_1_posts` SET `guid` = REPLACE(`guid`,@oldDomain,@newDomain); 
UPDATE `wp_blogs` SET `domain` = @newDomain WHERE `domain` = @oldDomain; 
UPDATE `wp_users` SET `user_pass` = MD5(@testUsersPassword); 

-- Only valid for main wpmu site 
UPDATE `wp_site` SET `domain` = @newDomain WHERE `domain` = @oldDomain; 
0

Questa circa riassume i problemi con il wordpress architettura core ... ma ho scritto un plugin che risolve il problema ms con nomi di dominio e URL assoluti di essere memorizzate nel database:

http://wordpress.org/extend/plugins/root-relative-urls/

Questo risolverà i problemi delineati da @oddbill. Anche se non ti preoccupare troppo dell'URL che si trova nella colonna GUID, questo campo non viene mai utilizzato per la generazione di link.

@markratledge fornisce un paio di link ad alcuni lunghi documenti che dicono fondamentalmente questo:

// esportazione

mysqldump -u[username] -p[password] [database] > backup.sql

// importazione

mysql -u[username] -p[password] [database] < backup.sql

Avrete vuoi escludere le tabelle commenti/commenti_meta se passi alla produzione dalla stadiazione, così fai non perdere tutti i tuoi commenti e trackback (l'approccio di @ DavidLaing li cancellerà). Questo presuppone che tu possa solo apportare modifiche ai contenuti nell'ambiente di staging. Se desideri apportare modifiche alla produzione e all'ambiente di staging, devi scrivere script che sincronizzano i dati anziché sovrapporli all'ingrosso ... buona fortuna per quel compito, potrei suggerire di aggiungere creare colonne di data/ora modificate & prima di investire troppo tempo con lo schema attuale.

Infine, l'approccio di @ RussellStuever è adatto nella maggior parte dei casi, è sufficiente accertarsi di sapere quando si sta esplorando il sito mappato host rispetto al sito di produzione. E ne siamo davvero sicuri, perché alcuni browser nascondono le ricerche DNS per giorni fino a quando non le chiudono fisicamente e iniziano un nuovo processo. A quel punto il cambio di host potrebbe richiedere del tempo e il passaggio frequente potrebbe risultare frustrante. E se hai bisogno di testare un iPhone, devi prima pubblicare il sito live o utilizzare un buon router in grado di rimappare le richieste Internet in uscita verso i server locali perché non puoi modificare i file host sulla maggior parte dei dispositivi mobili.

Il mio plugin consente di sviluppare e testare da http://localhost/ o http://staging.server.local/ o http://www.production.com senza le solite trappole. E poi per migrare i dati, è semplice come esportare e importare i dati, nessuna ricerca & sostituzione passo o modifiche alle impostazioni del database necessarie.

E non fare affidamento sullo strumento di importazione/esportazione, non acquisisce tutto nelle tipiche installazioni di wordpress e richiede ancora una sostituzione inutile del passaggio &.

0

È necessario gestire gli oggetti serializzati. Ecco un client side HTML5 utility per gestirlo. Perché è tutto javascript, è abbastanza veloce.

L'alternativa sarebbe l'aggancio di uno script di bash nella distribuzione. Quindi, una volta distribuito il sito, il db viene sottoposto a backup e deserializzato con il nuovo dominio.

Problemi correlati