Oggi WordPress alimenta il 25% di tutti i siti Web del mondo, quindi è sicuro dire che ciò che è iniziato come software di blogging è diventato qualcosa di molto più grande delle sue umili origini ed è pronto per essere utilizzato su siti di produzione dai portali di notizie a completare le applicazioni web.
Con questo livello di professionalità, sorgono nuovi bisogni.
Su un blog personale letto da amici e parenti, un aggiornamento dei plug-in non funzionerà più che un leggero fastidio, molto probabilmente, i tuoi lettori non vedranno nemmeno l'errore. Quando lavori davanti a centinaia di migliaia di visitatori, tuttavia, un tale errore verrà immediatamente notato e non te ne andrà così facilmente.
"Ha funzionato sul mio computer" potrebbe essere vero, ma non renderà più felice il cliente frustrato.
Ecco perché, mentre costruisci un sito WordPress professionale per un pubblico più vasto, avrai bisogno di una configurazione di hosting che ti aiuti ad assicurarti che gli aggiornamenti siano sicuri e non rompere mai l'ambiente live.
Quindi, come fai a essere sicuro che il tuo server non si romperà quando invierai un nuovo aggiornamento live, sia esso una nuova versione del tuo tema o un aggiornamento a uno o più dei tuoi plugin?
Effettuando il test in un ambiente identico al server live, prima di trasmettere le modifiche dal vivo.
Il setup inizia con a server di sviluppo che utilizzi per il tuo lavoro quotidiano sul prodotto: test degli sviluppatori, presentazione di modifiche iniziali ai clienti e così via. Questo server potrebbe essere eseguito sul tuo computer o su un server nel cloud.
Quando sei soddisfatto di come stanno le cose sul server di sviluppo, in questa configurazione, non avrai fretta di spingere il tuo codice dal vivo. Invece, si commettono le modifiche nel controllo della versione e le si distribuiscono in a server di prova.
Poiché l'ambiente di test esegue il software server identico al software sul server live, tranne per il fatto che il nuovo codice non è ancora stato aggiornato sul server live, è possibile utilizzarlo per individuare eventuali problemi che potrebbero verificarsi sul server ma non nel tuo ambiente di sviluppo. Per rendere i test ancora più realistici e individuare gli errori causati dai dati inseriti dai clienti, puoi anche popolare il database di test con dati reali dal tuo server live.
Sul server di test, ci si assicura che tutto funzioni come dovrebbe, testando il sito manualmente o eseguendo test automatici o una combinazione dei due. E solo allora, quando i test verranno completati correttamente, trasferirai le modifiche dal vivo. Con fiducia, sapendo che le modifiche non interromperanno il tuo sito.
Mentre l'approccio Dev-Test-Live è ben noto tra le società di software che creano servizi online, tradizionalmente si è limitato a sviluppatori e aziende con le risorse per eseguire e gestire più server da soli e per mantenerli sincronizzati con lo stesso server software e dati.
Ciò significa pagare per molti server, ma anche molti lavori di manutenzione.
Sul Pantheon, questo approccio viene integrato nel servizio.
Pantheon è un servizio di hosting WordPress e Drupal scalabile e veloce che non solo ti permette di testare il tuo codice su un server di test prima di spingerlo dal vivo ma praticamente ti obbliga a seguire la procedura di best practice in tutte le tue implementazioni.
In questo tutorial, imparerai come configurare un sito WordPress su Pantheon e svilupparlo e mantenerlo in modo sicuro utilizzando l'architettura Dev-Test-Live e il controllo della versione.
Iniziamo!
Ora che sai cosa costruiremo (e perché), è ora di iniziare.
Una delle grandi cose di Pantheon è il suo modello di prezzo: paghi solo una volta che il tuo sito è attivo, quindi puoi provare tutto e persino mostrare il tuo sito web ad amici e clienti prima di dover pagare per il tuo account.
Per prima cosa, vai sul sito di Pantheon e crea il tuo account gratuito.
Se il tuo lavoro consiste nella creazione di siti Web per un gruppo di clienti o se hai un team di sviluppatori che collabora con te, puoi registrarti come agenzia. Le agenzie hanno la stessa struttura tariffaria, ma hanno anche alcune funzionalità extra come Multidev, che consente di posizionare un sito in più ambienti di sviluppo per facilitare la collaborazione e creare e dimostrare nuove funzionalità senza dover aggiornare l'ambiente primario.
Se non sei sicuro di quale tipo di account è giusto per te, vai con quello predefinito. Puoi sempre convertire il tuo account in un account di agenzia in seguito.
Una volta effettuato l'accesso, vedrai la seguente vista:
Clicca su Crea un nuovo sito per iniziare a costruire il tuo primo sito WordPress sul Pantheon.
In questa schermata, scegli un nome per il tuo sito su Pantheon: il nome viene utilizzato nell'amministrazione di Pantheon e per generare gli URL degli ambienti. Non puoi cambiare questo nome in seguito, quindi è bene pensarci, ma non preoccuparti, non deve essere lo stesso del nome definitivo del tuo sito WordPress.
I nomi sono globali attraverso Pantheon, quindi selezionare qualcosa di molto generico può portare a un errore. In tal caso, prova qualcos'altro.
Dopo aver selezionato il nome, fare clic su Crea sito.
Successivamente, ti verrà chiesto di scegliere lo stato di partenza per il tuo nuovo sito. È possibile avviare un nuovo sito Web da zero o importare un sito Drupal o WordPress esistente:
Scegliere Iniziare da zero.
Sotto la selezione, vedrai un elenco di diversi pacchetti di partenza o upstream, come vengono chiamati sul Pantheon.
Questi upstream di default sono mantenuti da Pantheon in modo che quando un nuovo aggiornamento diventa disponibile a quello che stai usando (WordPress, nel nostro caso), puoi facilmente aggiornarli al tuo sito attraverso il Pantheon Dashboard.
Mentre creiamo un sito WordPress, fai clic su Installa WordPress.
L'installazione ha inizio. E dopo un po ', è pronto.
Clicca sul Visita il tuo Pantheon Dashboard pulsante.
Ora hai una nuova installazione WordPress in esecuzione su un server di sviluppo Pantheon e puoi accedervi e controllarla attraverso il Pantheon Dashboard.
Nella parte superiore dello schermo, vedrai tre schede per i diversi ambienti server: dev, Test, e Vivere. Sotto ogni scheda, troverai quindi una struttura di menu simile per mantenere quel server e distribuire codice e dati tra gli ambienti:
Clicca sul Amministratore del sito pulsante nella parte in alto a sinistra dello schermo. Ciò ti guiderà attraverso il normale flusso di installazione di WordPress:
Puoi anche fare clic sul Visita il sito di sviluppo pulsante per visualizzare il sito.
Ora che il tuo ambiente di sviluppo è attivo e funzionante, diamo un'occhiata agli altri due ambienti.
Come abbiamo visto sopra, nella dashboard di Pantheon, troverai le schede per i tre ambienti server: dev, Test, e Vivere.
Ciascuna scheda rappresenta uno degli ambienti server che eseguono il tuo sito. dev è l'ambiente di sviluppo per i test mentre si lavora sul sito e forse si sta dimostrando una versione anticipata del sito ai clienti. Vivere è la versione del sito installata e funzionante e utilizzata dagli utenti effettivi.
Tra i due è Test, l'ambiente che mantiene il tuo sito live relativamente sicuro dai tuoi errori. Prima di poter spingere qualsiasi cosa dal vivo sul Pantheon, dovrà sempre passare attraverso a Test ambiente, in modo da avere un'ultima possibilità di verificare che tutto funzioni correttamente prima di inviare il codice in libertà.
Poiché abbiamo appena creato il nuovo sito WordPress, esiste ancora solo nell'ambiente di sviluppo.
Creiamo un ambiente di test per questo.
Clicca sul Test linguetta.
Poiché questa è la tua prima volta sul Test scheda, vedrai alcune informazioni su come funziona l'ambiente di prova.
Clicca su Crea ambiente di test per clonare il tuo ambiente Dev per i test. In questa fase, sia il codice che i dati di Dev sono clonati poiché non esiste ancora un ambiente live. Negli aggiornamenti futuri, come ben presto vedremo, tuttavia, solo il codice si sposta da Dev a Test. Questo perché l'idea è quella sul server di test, controllerai il tuo codice con i dati copiati dall'ambiente live.
L'ambiente di test è ora pronto.
Clicca su Visita il sito di prova per verificare che il sito di test abbia lo stesso aspetto del sito in esecuzione nell'ambiente Dev. Puoi anche fare clic Amministratore del sito per accedere alla dashboard di WordPress. Utilizza le stesse credenziali di amministratore definite per WordPress sul server Dev.
Hai creato un'installazione WordPress di base con un ambiente di sviluppo e test e sei pronto per iniziare a personalizzarlo.
Ora che hai un'installazione di WordPress in esecuzione nel cloud, probabilmente vorrai fare qualcosa di più con esso. Per lo meno, installerai alcuni plug-in e forse un tema e personalizzerai il sito in base alle tue preferenze. In una configurazione più complessa, scriverai i tuoi plugin e magari creerai un tema personalizzato per rendere il tuo sito tutto tuo.
È qui che entriamo nel vivo del lavoro con una configurazione Dev-Test-Live.
L'installazione su Pantheon è basata sul controllo della versione: Pantheon mantiene l'intera installazione di WordPress, ad eccezione dei caricamenti di file, che vengono gestiti utilizzando un file system speciale, in un repository Git. In questo modo, quando si distribuiscono le modifiche al prossimo ambiente, tutto rimane sempre sincronizzato e non si perdono mai le modifiche.
Ciò significa anche che l'unico modo per aggiornare gli ambienti Test e Live è attraverso il controllo della versione. Non è possibile installare plug-in o temi sul server Live nel modo in cui probabilmente si è abituati quando si lavora con WordPress. Dopotutto, ciò spezzerebbe l'idea di testare il setup prima di spingerlo dal vivo.
Quindi, come installate e aggiornate plugin e temi sul vostro sito WordPress?
Puoi accedere al tuo sito dev ambiente su Pantheon in due modi: usando Git o direttamente su SFTP.
Mentre usare Git è utile per alcuni casi d'uso più avanzati (vedremo più avanti nel tutorial), parte della bellezza della configurazione di Pantheon è che usando SFTP, puoi usare l'ambiente Dev come server di sviluppo . In questo modo, è possibile anche saltare un server di sviluppo in esecuzione sul tuo computer.
La scelta non è permanente: puoi passare da una modalità all'altra a seconda di ciò che funziona meglio per l'attività in corso.
Quindi, per ora, assicurati che il tuo ambiente Dev stia usando il SFTP modalità di connessione:
Nella modalità SFTP, apporti le modifiche alla base di codice dell'installazione di WordPress direttamente sul server, e poi, quando tutto sembra a posto, commetti le tue modifiche a Git usando gli strumenti nella dashboard di Pantheon.
In questo modo, è possibile utilizzare il sito Dev come si farebbe con qualsiasi sito WordPress e personalizzare il sito utilizzando il dashboard di WordPress proprio come si farebbe su una singola configurazione del server.
Proviamoci in azione.
Nel pannello di amministrazione di WordPress, seleziona plugin > Aggiungere nuova. Quindi, seleziona un plug-in che desideri installare. Ad esempio, ho installato JetPack di WordPress.com:
Ora, attiva il plugin e verifica che funzioni come previsto sul tuo server Dev.
Quando sei soddisfatto del plug-in, torna a Pantheon Dashboard. Lì, vedrai che il sistema ha notato le tue modifiche e le mostra come modifiche pronte per essere sottoposte al controllo di versione.
Clicca sul campo di testo che dice Aggiungi un messaggio di commit per inserire il tuo messaggio di commit e vedere ulteriori dettagli sulle modifiche che stanno per entrare nel controllo della versione.
Controllare le modifiche, aggiungere un messaggio di commit descrittivo e fare clic Commettere per impegnare le modifiche.
Al termine del commit, le modifiche sono disponibili per essere distribuite sul server di prova. Per fare ciò, fare clic su Test linguetta.
Lì, vedrai la seguente notifica.
È l'impegno che hai appena fatto sul tuo dev ambiente, ora pronto per essere utilizzato Test.
Digitare un messaggio di registro descrittivo e fare clic su Distribuire il codice dallo sviluppo all'ambiente di test.
Quindi, visita il Dashboard di WordPress del tuo sito di test per verificare le modifiche.
Sul plugin pagina, vedrai che il plugin è stato installato, ma non è ancora attivo.
Questo perché su Pantheon, mentre il codice viene aggiornato da Dev su verso il server live, le modifiche al database, incluse le informazioni sui plugin attivi, fluiscono dall'altra parte, da Live verso Dev.
Poiché i plug-in spesso eseguono un codice all'attivazione, per i plug-in, questo non è male. Devi solo ricordarti di attivare i tuoi plugin dopo che la distribuzione è stata completata e sei pronto per partire. Nel mio prossimo tutorial su Pantheon, mostrerò come si può automatizzare usando lo strumento da riga di comando di Pantheon.
Tuttavia, mentre questo approccio funziona per i plugin, ci sono altri dati, come il plugin e le impostazioni del tema, che costituiscono una parte importante della configurazione del sito che probabilmente non si desidera configurare manualmente dopo la distribuzione.
Diamo un'occhiata a come puoi passarli da un ambiente all'altro.
Come ricordiamo, il codice oi file nel controllo della versione passano dall'ambiente di sviluppo verso il server live. Quindi, per spostare le impostazioni in modo simile, l'approccio più naturale è quello di memorizzarle nel controllo della versione.
Per fare questo, useremo un plugin gratuito per WordPress che fa proprio questo.
Il plugin, WP-CFM, legge le opzioni dalle tabelle delle opzioni di WordPress e le memorizza in un file di testo, che può quindi essere impegnato nel controllo della versione (ricorda, l'intera installazione di WordPress, tranne la directory di upload, viene archiviata in controllo di versione e letta negli altri ambienti).
Facciamo questo dopo.
Seguire le istruzioni dal punto 2 sopra per installare il plugin WP-CFM nell'ambiente Dev e distribuirlo su Test. Quindi, attiva il plugin su entrambi gli ambienti.
Ora che il plugin è attivo in entrambi gli ambienti, possiamo usarlo per spingere le opzioni di WordPress da Dev a Test. Se lo desideri, puoi modificare alcune impostazioni di WordPress a questo punto in modo da vedere come le modifiche vengono applicate sul server Test (il nome del sito, ad esempio, è una modifica piuttosto visibile).
Nel pannello di WordPress del tuo server Dev, fai clic su impostazioni > WP-CFM.
Clic Aggiungi pacchetto creare un nuovo pacchetto di impostazioni per il controllo della versione. I bundle sono raccolte di impostazioni che possono essere salvate e spinte indipendentemente l'una dall'altra.
Successivamente, ti verrà chiesto di selezionare le opzioni che desideri includere nel pacchetto. Se vuoi mantenere alcune opzioni diverse da un ambiente all'altro, puoi deselezionarle nell'elenco.
Nell'esempio sopra, ho scelto tutto Opzioni WP, tranne l'elenco dei plugin attivi (perché voglio essere in grado di eseguire gli script di attivazione del plug-in in ogni ambiente), ma puoi scegliere ciò che sembra logico per la configurazione del tuo sito.
Quando sei soddisfatto dell'elenco di opzioni, fai clic su Salva I Cambiamenti.
Una volta salvato il pacchetto, vedrai i nuovi pulsanti per esso:
Clicca sul diff per vedere le differenze tra il tuo database Dev e il contenuto del file di opzioni esportato da WP-CFM.
Poiché WP-CFM non ha ancora creato un file di esportazione, il diff mostrerà tutto come aggiunto:
Chiudere il popup Diff e fare clic Spingere per memorizzare i dati dal database al file di esportazione.
Ora, quando torni al cruscotto del tuo Pantheon dev scheda, vedrai che WP-CFM ha creato un file JSON (wp-content / config / site_options.json
) pronto per essere impegnato per il controllo della versione:
Confida le modifiche e distribuiscile nel Test ambiente.
Quindi, sul dashboard di WordPress del server di test, vai a impostazioni > WP-CFM.
Innanzitutto, noterai che il Opzioni del sito bundle è ora disponibile anche in questo ambiente.
Tuttavia, a causa delle limitazioni impostate sugli ambienti Test e Live, noterai che il bundle di opzioni funziona solo in una direzione: wp-content / config
non è scrivibile nell'ambiente di test. Questo è fantastico perché ci aiuterà a mantenere pulito il file di esportazione.
Clicca sul Tirare pulsante per leggere i contenuti del file di configurazione e applicarli nel tuo Opzioni WP tavolo. Nel popup di conferma che chiede "Importa impostazioni file su DB?", Rispondi ok.
Ora, se hai apportato alcune modifiche alle opzioni di WordPress prima di eseguire il server Push on the Dev, dovresti vedere queste modifiche applicate anche al sito Test.
Ad un certo punto nel ciclo di vita del tuo sito, potresti voler trasferire i dati effettivi dal tuo server Live a Dev. Potrebbe essere quello di testare un bug contro dati reali, o semplicemente di vedere come stanno le cose con i veri contenuti generati dagli utenti invece di alcuni dati di test creati da te, lo sviluppatore.
Sul dev ambiente, fare clic su Database / File nel menu a sinistra.
Qui, puoi scegliere l'ambiente da cui clonare i dati (test / live) e se vuoi clonare solo il database o anche qualsiasi upload di file fatto in quell'ambiente.
Hai anche la possibilità di aggiornare qualsiasi URL nel database per adattarlo alla struttura dell'URL dell'ambiente Dev.
Si noti che la clonazione sostituirà tutto nel database del proprio ambiente Dev, quindi se si hanno delle modifiche personalizzate che si desidera ripristinare dopo la clonazione, utilizzare WP-CFM per inserirle in un file di testo prima di eseguire la clonazione.
Questa funzionalità è molto utile per estrarre dati da Live e da Test a Dev, ma è anche possibile utilizzarli per clonare il database Dev su Test (e persino su Live). Può essere utile, ad esempio, se crei il tuo contenuto iniziale del sito (pagine e forse post di un blog) sull'ambiente Dev e desideri eseguirlo per testare subito prima di creare l'ambiente Live.
Abbiamo ora esaminato le attività di gestione di base di WordPress come l'installazione di nuovi plug-in e l'invio di modifiche alla configurazione tra gli ambienti.
L'aggiornamento dei plug-in e l'installazione dei temi possono essere eseguiti allo stesso modo, seguendo le stesse istruzioni. Quindi, se gestisci tutto il tuo sito utilizzando temi e plugin preesistenti, questo è praticamente ciò che devi sapere sulle basi del Pantheon per farne un grande uso.
Spesso, tuttavia, dovrai anche cambiare il codice da solo, scrivendo un plug-in o modificando e personalizzando un tema.
Per dimostrare come è possibile farlo, creiamo un tema figlio semplice per il tema predefinito corrente, Twenty Sixteen, e spingilo fino al sito Test.
Continuando a utilizzare l'ambiente Pantheon Dev come server di sviluppo, utilizziamo il tuo client FTP preferito per caricare le nostre modifiche al codice sul server Dev.
È facile, e probabilmente lo abbiamo già fatto in un momento o nell'altro su altri server su Internet.
Per connettersi al server Pantheon, prima, sul Pantheon Dashboard, fare clic su Informazioni sulla connessione STFP pulsante per aprire un popup con informazioni su come connettersi al proprio server di sviluppo.
Copia il Ospite e Nome utente informazioni al client FTP e utilizzare la password di Pantheon Dashboard per connettersi al server. Assicurati di usare il Porta specificato nelle istruzioni di connessione.
Una volta connesso al server, troverai l'intera base di codice del tuo sito WordPress nella directory ~ / Code
.
Una volta connesso, puoi usare il tuo client FTP per sostituire qualsiasi file o caricarne di nuovi, e vedere le modifiche applicate immediatamente sul sito WordPress del tuo server Dev.
Molti client FTP, editor di codice e IDE PHP (come PHPStorm ed Eclipse) consentono di sincronizzare le modifiche al codice direttamente con un server remoto utilizzando SFTP. Usando questi strumenti, puoi rendere lo sviluppo ancora più veloce con il passaggio in più del caricamento delle modifiche affinché i test avvengano automaticamente in background.
Nota che l'URL SFTP del tuo server Dev può cambiare di volta in volta, quindi se non riesci a connetterti, controlla le credenziali di connessione correnti dalla Dashboard e riprova.
Come esempio di questo approccio, creiamo un tema figlio semplice per il tema predefinito, Twenty Sixteen. Dato che questo è solo a scopo dimostrativo, terremo il tema super semplice con nient'altro che a style.css
file che cambia il colore di sfondo del sito in rosso e a functions.php
file per accodare il foglio di stile.
Sul tuo computer, crea una directory chiamata twentysixteen-figlio
, e al suo interno, un file di testo chiamato style.css
.
Dentro style.css
aggiungi il seguente contenuto:
/ * Nome del tema: Twenty Sixteen Descrizione del bambino: Un tema bambino semplice Template: twentysixteen Versione: 0.0.1 Licenza: GNU General Public License v2 o successiva URI della licenza: http://www.gnu.org/licenses/gpl-2.0. html * / body background-color: # ff0000;
Quindi, crea un functions.php
file con il seguente contenuto:
Successivamente, carica la directory insieme al suo contenuto nella directory del tuo server Dev ~ / Code / wp-content / themes /
.
Ora, quando visiti il Aspetto > Temi sullo schermo dell'amministratore di WordPress del tuo server Dev, vedrai che il nuovo tema è ora disponibile per l'uso.
Vai avanti e attivalo!
Ora, quando visiti il tuo sito Dev, noterai che il suo sfondo è diventato rosso, proprio come abbiamo definito nel file CSS del tema Bambino.
Ora hai caricato un nuovo tema figlio sul tuo server Dev. Quindi, per essere sicuro di non perdere le tue modifiche e di poterlo distribuire sul server di test, dovrai trasferire le modifiche al controllo della versione.
Quando sviluppi il tuo sito direttamente sull'ambiente Dev utilizzando SFTP, è fondamentale ricordare che prima di commettere le modifiche a Git su Pantheon Dashboard, non vengono archiviate nel controllo di versione. Quindi, per assicurarti di non perdere nessuno dei tuoi importanti cambiamenti, non dimenticare di impegnarti spesso, anche quando non sei ancora pronto a trasmettere le tue modifiche a Test.
Nella scheda Dashboard dell'ambiente Dev, noterai che hai alcune modifiche non vincolanti pronte per essere commesse.
Digitare un messaggio di commit e fare clic Commettere.
Nello screenshot qui sopra, noterai anche che ci sono cambiamenti nel site_options.json
file creato da WP-CFM. Questo perché ho spinto le informazioni sull'attivazione del tema su quel file di configurazione. In questo modo, il nuovo tema verrà attivato quasi automaticamente. Anche se questo non è necessario in questo semplice caso esemplificativo, è una buona pratica adottare considerando il futuro e le eventuali configurazioni di temi più complesse che potresti costruire.
Dopo aver eseguito il commit delle modifiche, distribuirle in Test utilizzando i passaggi illustrati in precedenza quando abbiamo distribuito le installazioni dei plug-in. Quindi, se hai spinto il pacchetto di opzioni del sito usando WP-CFM, usa il plugin per estrarre le modifiche al database del sito di test.
Ora, quando visiti l'ambiente del test Aspetto > Temi pagina, dovresti vedere il nuovo tema come tema attivo.
Se vuoi avere un controllo più chiaro sulla base di codice e preferisci eseguire i test di sviluppo e di sviluppo sul tuo computer locale, puoi inviare il tuo codice al server Dev utilizzando il controllo della versione Git da solo invece di caricare prima le modifiche sul server tramite FTP.
Per fare ciò, di nuovo sul server Dev Codice scheda, cambia Modalità di connessione a partire dal SFTP a Idiota.
Se hai modifiche non impegnate sul server Dev quando passi alla modalità Git, vedrai un popup che ti chiede di confermare che vuoi fare il passaggio e perdere le modifiche.
Se si desidera mantenere le modifiche, chiudere la notifica e confermare prima di continuare con il passaggio alla modalità. Se non hai bisogno delle modifiche, digita ELIMINA
nel campo di testo e fare clic sul grande pulsante rosso.
L'autenticazione Git su Pantheon viene eseguita utilizzando una chiave SSH, quindi prima di continuare, è necessario generare una chiave e aggiungerla al proprio account. Puoi utilizzare la stessa chiave SSH per tutti i tuoi siti Pantheon, quindi dovrai farlo una sola volta.
Con la chiave SSH installata, puoi iniziare a lavorare sull'installazione di WordPress usando Git.