Share
Vi siete mai chiesti come si può usare Version Control con WordPress? Se preferisci lavorare sui tuoi progetti WordPress localmente ma devi farli sincronizzare da remoto, questo tutorial è per te. Probabilmente hai provato a sincronizzare le due configurazioni caricando manualmente i file modificati e usando PHPmyAdmin per esportare e importare il tuo database una volta cambiato, e (molto probabilmente) ha rotto qualcosa nel processo. In questo tutorial, stiamo andando a automatizza il processo di sincronizzazione; così puoi concentrarti su ciò che dovresti fare invece di lottare con migrazioni senza fine.
Generalmente iniziamo lo sviluppo di WordPress sulle nostre macchine locali. È sempre più facile e veloce soprattutto quando si ha una connessione internet lenta. Ma ci sono momenti in cui devi lavorare da remoto. Potresti voler fare una piccola modifica, correggere qualche padding o semplicemente pubblicare un nuovo post. Le modifiche non vengono salvate nell'installazione locale di WordPress e in quel momento inizia il caos.
Il caos si avvia perché potrebbe essere necessario rilasciare una nuova versione e, poiché si lavora localmente, le modifiche apportate in remoto devono essere portate fuori linea. È un vero dolore. È necessario capire quali file sono stati modificati e scaricarli / FTP. A volte le modifiche avvengono nel Database, quindi è necessario uno strumento speciale come phpmyAdmin per apportare le modifiche.
Nel processo, puoi rompere qualcosa o dimenticare una modifica. Questo è quando tutto diventa complicato. In questo caso, hai bisogno di due cose: controllo della versione e sincronizzazione. In questo tutorial, descriverò la soluzione che sto seguendo per organizzare il mio sviluppo e la sincronizzazione tra il mio computer locale e il mio server remoto.
Per prima cosa, lascia che ti spieghi cosa faremo. Il nostro obiettivo è sincronizzare facilmente tra la versione remota e quella locale. Lavorerai in quale versione ti piace e poi li renderà identici. Per fare ciò, dobbiamo prima tenere conto delle differenze tra l'installazione remota e quella locale.
WordPress memorizza informazioni sul tuo blog sia in file statici che nel tuo database. Alcune di queste informazioni sono relative al tuo hosting attuale. Ecco perché quando carichi l'intera directory di WordPress e sostituisci la versione remota, non funzionerà.
L'informazione è sfortunatamente divisa in due parti:
Per wp-config.php, implementeremo un processo che rileva se siamo nel server locale o remoto. In questo modo, lo stesso file funzionerà in entrambi gli ambienti. Per il database, lo integreremo con il sistema di controllo della versione e lo aggiorneremo per corrispondere alle impostazioni dell'host locale o remoto.
Io uso Mercurial per il controllo della versione. Git è più popolare nell'arena di sviluppo del web, ma nel nostro caso sono quasi simili: hai solo bisogno di uno strumento di controllo della versione.
Scegli Mercurial se sei su una macchina Windows. Ha Tortoise, un'interfaccia user-friendly, per gestire i tuoi repository. Lo strumento di controllo della versione deve essere installato sia nelle macchine locali che in quelle remote. Detto questo, avrai bisogno di un server dedicato o di un VPS per poter installare l'applicazione di terze parti.
Per inizializzare un repository in Mercurial, digitare quanto segue nella console
cd / mydev_directory hg init hg aggiungi hg commit
Nella prima riga, cambiamo la nostra directory di lavoro nella cartella in cui vogliamo abilitare il controllo della versione. Questa sarà la tua directory WordPress (dove installerai WordPress). La riga successiva inizializza il repository. La terza riga indica a mercurial il controllo della versione di tutti i file nella directory. Questo includerà anche le sottocartelle. L'ultima riga crea un nuovo changeset nella directory; il tuo editor di testo si aprirà e ti verrà richiesto di scrivere una descrizione di questo commit.
Questo tutorial non tratta come usare Mercurial. Se non conosci il controllo della versione, dovresti impararlo. Questo è uno strumento importante da aggiungere al tuo set di abilità. Ecco alcuni tutorial che suggerisco:
Faremo una nuova installazione di WordPress nella nostra macchina locale. Scarica l'ultima versione di WordPress, estraila all'interno di una directory vuota di tua scelta nel tuo server web e installala dal tuo browser o modificando il file wp-config.php.
Ora stiamo per attivare il controllo della versione nella nostra directory di WordPress
cd / testpress Hg init Hg aggiunge Hg commit
Questi comandi inizializzano il repository e creano il primo changeset. Ora, possiamo semplicemente clonare questo repository nel nostro server, installare WordPress ed essere in grado di sincronizzare avanti e indietro tra la distribuzione locale e remota.
Tuttavia, ci sono delle differenze come abbiamo detto prima. Prima di implementare il processo di sincronizzazione, è necessario implementare uno script che controlli dove è in esecuzione l'installazione di WordPress e carica le impostazioni corrette.
Le impostazioni che devono essere modificate sono le informazioni del database. Si trovano nel file wp-config.php e WordPress li carica da questo file. La mia versione locale è simile a questa
Accentsconagua
// ** Impostazioni MySQL - Puoi ottenere queste informazioni dal tuo host web ** // / ** Il nome del database per WordPress * / define ('DB_NAME', 'test'); / ** Nome utente del database MySQL * / define ('DB_USER', 'root'); / ** Password del database MySQL * / define ('DB_PASSWORD', 'xxxxx'); / ** Nome host MySQL * / define ('DB_HOST', 'localhost'); / ** Charset del database da utilizzare per la creazione di tabelle del database. * / define ('DB_CHARSET', 'utf8'); / ** Il tipo di fascicolazione del database. Non cambiare questo in caso di dubbio. * / define ('DB_COLLATE', "); Si noti che ho solo copiato la parte che conta. Nel mio server remoto, questa parte dovrebbe differire leggermente
// ** Impostazioni MySQL - Puoi ottenere queste informazioni dal tuo host web ** // / ** Il nome del database per WordPress * / define ('DB_NAME', 'user_blog'); / ** Nome utente del database MySQL * / define ('DB_USER', 'root'); / ** Password del database MySQL * / define ('DB_PASSWORD', 'xyxyx'); / ** Nome host MySQL * / define ('DB_HOST', 'localhost'); / ** Charset del database da utilizzare per la creazione di tabelle del database. * / define ('DB_CHARSET', 'utf8'); / ** Il tipo di fascicolazione del database. Non cambiare questo in caso di dubbio. * / define ('DB_COLLATE', "); Il trucco è scrivere un codice che rilevi dove si trova WordPress. La variabile da utilizzare è la variabile PHP _SERVER [ "HTTP_HOST"]. Il codice valuta la variabile e assegna le impostazioni del database.
/ * * Variabili unificate * / $ user_name = 'root'; $ hostname = 'localhost'; $ charset = 'UTF-8'; $ collate = "; / * * Verifica l'ambiente corrente * / if ($ _SERVER [" HTTP_HOST "] === 'onlineqrlab.com') $ db_name = 'user_wordpress'; $ password = 'xyxyxy'; else if ($ _SERVER ["HTTP_HOST"] === 'localhost') $ db_name = 'test'; $ password = 'xxxxxx'; // ** Impostazioni MySQL - Puoi ottenere queste informazioni dal tuo host web ** // / ** Il nome del database per WordPress * / define ('DB_NAME', $ nome_db); / ** nome utente del database MySQL * / define ('DB_USER', $ user_name); / ** Password del database MySQL * / define ('DB_PASSWORD', $ password); / ** MySQL hostname * / define ('DB_HOST', $ hostname); / ** Database Charset da utilizzare nella creazione delle tabelle del database. * / define ('DB_CHARSET', $ chartet) ; / ** Il tipo di fascicolazione del database. Non modificare questo in caso di dubbio. * / Define ('DB_COLLATE', $ collate); Nell'esempio sopra, ho solo due parametri che sono cambiati: Nome del database e password. Potresti avere di più. Ad esempio, se si ospita mySql in un server esterno, è necessario modificare il nome host per l'installazione del server remoto. È inoltre consigliabile limitare l'accesso del blog WordPress a livello di utente con funzionalità limitate anziché a livello di amministratore.
Verifica che la tua versione locale di WordPress funzioni. Se è così, allora sei a metà!
Puoi iniziare ora a lavorare sull'installazione locale di WordPress. Ogni volta che esegui una modifica importante, effettua un commit con Mercurial per tracciare le modifiche. Nel server remoto, supponendo di avere installato Apache, creare una nuova cartella in cui caricare il repository di WordPress.
cd / apache mkdir mywp_repo cd mywp_repo
Nota che questi comandi dovrebbero essere eseguiti sul tuo server remoto. Avrai bisogno dell'accesso SSH e anche di una riga di comando. Sto usando Putty su Windows per connettersi al mio server.
Una volta inizializzato il nostro repository, possiamo spingere (caricare) e tirare (scaricare) i changeset da altri repository per tenerlo aggiornato. Affinché questo processo si verifichi, è necessario che il server locale o remoto pubblichi il repository in modo da poterlo estrarre / spingere.
Il web server di Mercurial non ha alcune funzionalità importanti come controllo degli accessi, autenticazione e SSL. Quindi non è sicuro utilizzarlo sul tuo server remoto. Preferibilmente, è necessario eseguire il server Web Mercurial localmente ed estrarre le modifiche dal server locale al server remoto.
Per eseguire il server Mercurial, digitare quanto segue sulla macchina locale:
hg servire
Ora dovresti essere in grado di accedere al tuo repository dal tuo browser. Digita l'URL che viene visualizzato sulla tua riga di comando. Di solito, è localhost: 8000. Il repository è anche disponibile online. Puoi accedervi da qualsiasi computer connesso a Internet usando youripaddress: 8000.
Hg pull 192.xxx.xxx.xxx:8000 Hg update
Ma non consiglio questo metodo perché non è sicuro. C'è un modo semplice e sicuro per farlo. È un archivio intermedio ospitato da un servizio di terze parti. Sto usando BitBucket. Ha un servizio buono e affidabile e offre anche il monitoraggio degli errori e un wiki.
Registrati e crea un account in BitBucket. Offrono illimitati archivi privati e pubblici con un massimo di 5 utenti gratuitamente. Crea un nuovo repository in BitBucket e dovresti essere indirizzato a questa pagina.
BitBucket ha il supporto HTTPS e SSH. Se il tuo repository è privato, come nel mio caso, dovrai autenticare con il tuo nome utente e password per essere in grado di spingere e tirare dal repository.
Dopo aver creato il tuo nuovo repository in BitBucket, esegui i seguenti comandi nel tuo computer locale
hg push https: //[email protected]/nomeutente/rapposto
Ti verrà chiesto di fornire la tua password e il repository verrà caricato su BitBucket. Dopo aver caricato su BitBucket, clonare il repository sul server remoto.
hg clone https: //[email protected]/nomeutente/repository hg update
Clonazione scarica i file in una nuova directory (il cui nome è uguale alla directory del tuo repository); puoi rinominare questa directory. Questo farà il primo passo in questa sezione (dove abbiamo creato la directory di installazione di WordPress) piuttosto obsoleto.
Pensa a BitBucket come a un intermediario tra il tuo computer e il tuo host remoto. È possibile avere il proprio server Mercurial sicuro nel server remoto, ma questo va oltre lo scopo di questo tutorial. Il vantaggio è essere indipendente dall'uomo medio. Ciò consente di inviare modifiche direttamente al tuo server web.
Quindi, come è meglio di FTP?
Già stanco? Non preoccuparti, siamo quasi arrivati. Dopo aver estratto il repository dal tuo computer locale o da BitBucket, dovrai eseguire di nuovo l'installazione di WordPress; questa volta sul sito del server remoto. Assicurati che le impostazioni che hai inserito nel file wp-config.php che abbiamo creato in precedenza siano corrette e carica il tuo sito remoto WordPress.
Ti verrà chiesto di installare nuovamente il tuo blog WordPress, perché il tuo database è vuoto. Dopo l'installazione, il tuo blog WordPress è pronto. È possibile apportare modifiche nella versione remota o locale e sincronizzarle con Mercurial.
Ma c'è ancora un problema importante: il database non si sincronizza con i file. Questo è importante perché cose come post di blog, commenti, tabelle personalizzate plug-in? non sarà lo stesso nella versione locale e remota.
WordPress ha una funzione di importazione / esportazione. Ma non è utile, dal momento che non esegue una vera sincronizzazione. Quello di cui hai bisogno è andare sul tuo phpmyadmin, esportare tutte le tue tabelle di WordPress su un lato (remoto o locale) e poi andare sull'altro lato phpmyadmin e sostituire le tabelle.
Dopo aver fatto ciò, i tuoi database WordPress diventeranno gli stessi. Dovrai comunque modificare la riga site_url nella tabella wp_options. Questo processo diventa doloroso mentre il database diventa più pesante.
Come abbiamo visto in precedenza, il database è un po 'problematico. Non viene sincronizzato con i file, è più difficile da raggiungere e richiede l'aggiornamento di due campi ogni volta che si esegue la sincronizzazione. Non è divertente farlo più e più volte. L'automazione è la soluzione; in realtà, questo è il nostro lavoro.
Ciò di cui abbiamo bisogno è uno script che sincronizzi i database locali e remoti senza interrompere nulla. L'idea che mi è venuta in mente è di includere il database nel controllo di revisione. Il contenuto del database verrà esportato in un file monitorato dal controllo di revisione. Ogni volta che apportiamo modifiche, il contenuto del database verrà sostituito da questo file, rendendo il nostro database aggiornato.
Poiché ci sono un paio di righe che differiscono da un host a un altro (l'url del sito e l'URL della home page), abbiamo bisogno di un altro script mysql che aggiorni questi con i giusti valori.
Un'altra cosa importante sono i conflitti. Se si sta lavorando e apportando modifiche (commit) sia alla versione remota che a quella locale, ciò creerà un conflitto. Uno scenario tipico è quando si lavora e si impegna nella versione locale e qualcuno (online) aggiunge nuovi contenuti al proprio blog. Non posso aiutare in questa situazione, è necessario conoscere la fusione e il lavoro di squadra di Mercurial (o del vostro sistema di controllo di revisione).
Per evitare conflitti, assicurati di estrarre il repository da BitBucket prima di apportare modifiche; e anche per commettere e spingere le modifiche a BitBucket dopo averle fatte. Ciò assicurerà che BitBucket abbia sempre la versione più recente e che tu stia lavorando anche sull'ultima versione.
Questo passaggio è un po 'delicato, quindi assicurati di seguire attentamente i passaggi. Per prima cosa, spiegherò come funziona la soluzione finale. Avrai due script: spingi e tira. A seconda del sistema operativo, sarà push.sh e pull.sh (Linux) o push.bat o pull.bat (Windows). Sto usando Windows localmente e Linux (Ubuntu) da remoto, quindi questo tutorial riguarderà entrambi i sistemi operativi.
Il primo script trasmetterà le modifiche al server Bitbucket. Quando si apportano modifiche al database, utilizzare lo script push per caricare le modifiche nel repository BitBucket. Push eseguirà il dump del database corrente su un file (/db/db_sync.sql) tracciato dal sistema di controllo della versione. Il file verrà trasferito insieme agli altri file e caricato su BitBucket.
Il secondo script estrae le modifiche dal server Bitbucket. Lo script pull leggerà anche il file (/db_db_sync.sql) e sostituirà il database. Questo aggiornerà il database con la versione che hai spinto. Poiché hanno nomi host diversi, lo script pull modificherà i campi necessari, ovvero l'url del sito e l'URL della home page.
Nel server remoto e locale, crea una nuova directory chiamata "db". Il file di database esportato verrà salvato lì. Nel tuo server locale (presumo che tu stia usando Windows) crea un nuovo file chiamato push.bat. Non importa dove si inserisce il file (assicurati di utilizzare i percorsi giusti). Ho messo il file nella directory principale del mio repository WordPress.
mysqldump -u username -ppassword nome_database> db / db_sync.sql hg aggiungi db / db_sync.sql hg commit hg push https: //[email protected]/nomeutente/rapposto
È possibile rimuovere il comando "hg add db / db_sync.sql" dopo aver eseguito lo script per la prima volta. Questo è richiesto solo una volta.
Sul lato server (Linux / Ubuntu), le cose non sono molto diverse. L'estensione del file cambia da .bat a .sh, e possibilmente il nome utente del server mySql, la password e il nome del database. Il contenuto del file è esattamente lo stesso.
Tirare è un po 'più difficile. Richiede l'importazione del file SQL e anche la modifica di alcuni campi critici che differiscono da un ambiente all'altro.
Nel tuo computer locale, crea un file chiamato pull.bat
hg pull https: //[email protected]/nomeutente/repository hg update cd db mysql -u username -ppassword testpress < db_sync.sql mysql -u username -ppassword testpress < db.sql
Nella tua cartella db, aggiungi un file chiamato "db.sql". Questo file ha istruzioni SQL che eseguiranno le modifiche richieste per corrispondere alle impostazioni dell'host. Puoi aggiungere ulteriori dichiarazioni se necessario.
USA testpress; UPDATE wp_options SET option_value = "http: // localhost / testpress" WHERE option_name = "siteurl"; UPDATE wp_options SET option_value = "http: // localhost / testpress" WHERE option_name = "home";
A parte l'estensione del file, le impostazioni mySql e il nome del database non cambiano davvero nel server remoto. Questo perché eseguiamo i comandi dei programmi. I comandi e il loro utilizzo sono indipendenti dalla piattaforma. Assicurati di inserire i valori corretti per l'URL del sito web nel file "db.sql". Dovrebbero corrispondere all'URL del tuo blog, se non sei sicuro di poter controllare i valori nella tabella wp_options.
Per eseguire gli script, in Windows fare doppio clic sul? .Bat? file e nel terminale del server remoto esegui il comando? sh nome_script.sh?.
Ora dovresti avere 2 file eseguibili in ogni ambiente (pull e push). Dovresti anche avere uno script sql (db.sql) che non dovrebbe essere aggiunto al controllo della versione. Ora possiamo testare il nostro piccolo sistema.
