Flusso di lavoro di sviluppo moderno di WordPress con lo stack Roots

WordPress è in circolazione da secoli, almeno per gli standard di Internet, e la sua filosofia è sempre stata quella di preservare la compatibilità con le versioni precedenti. Questa attenzione alla compatibilità è comprensibile data l'enorme quantità di siti Web WordPress online oggi. Tuttavia, mentre questo può aiutare coloro che utilizzano ancora ambienti legacy con vecchie versioni di PHP e MySQL (che è di per sé un rischio per la sicurezza, ma questo non è l'argomento dell'articolo di oggi), ha anche impedito alle versioni più recenti di WordPress di sfruttare appieno le ultime funzionalità PHP.

Ciò ha anche indotto molti sviluppatori WordPress a vivere in una bolla di WordPress, non essendo incentivati ​​​​ad apprendere nuove e moderne tecnologie di sviluppo front-end e talvolta si bloccano nel "buon vecchio modo" di fare le cose.

Puoi adottare un flusso di lavoro di sviluppo moderno per WordPress?

Sicuramente puoi, e lo stack di WordPress Roots è qui per aiutarti a sviluppare come se fosse il 2019, con tre fantastici strumenti:

• Sage come tema iniziale,
• Bedrock come un moderno boilerplate di WordPress,
• Trellis per gestire la distribuzione e il provisioning in ambienti diversi.

Il team di Roots ha anche due strumenti aggiuntivi in ​​fase di sviluppo: Acorn, un framework per la creazione di plug-in e Clover, un plug-in standard. A causa del fatto che entrambi sono in alfa, non sono inclusi in questo articolo, ma dovresti assolutamente tenerli d'occhio.

Che cos'è esattamente lo stack delle radici

Originariamente noto come il tema Roots, era un solido tema di partenza HTML5 volto a fornire un punto di partenza più pulito per i nuovi siti Web WordPress. Nel tempo, si è evoluto in un set completo di strumenti, passando attraverso tutte le principali tecnologie e standard web moderni (da Grunt a Gulp e Webpack, LESS e SCSS, NPM e Yarn, Bootstrap, standard di codifica PSR-2 e il principio DRY), costringendo così gli sviluppatori di WordPress che lo hanno adottato a imparare continuamente e rimanere aggiornati su ciò che le moderne tecnologie di sviluppo front-end hanno da offrire.

Oggi, Roots è diventato un set completo di strumenti in continua espansione, volti ad aiutarti a costruire siti WordPress migliori seguendo l'intero ciclo, dallo sviluppo allo staging e alla produzione, e renderti uno sviluppatore migliore costringendoti a uscire dalla comodità zona fornita dalla cosiddetta bolla di WordPress.

Ma diamo un'occhiata ai tre strumenti principali che offrono, cosa sono e perché dovresti considerare di usarli.

Salvia delle radici 9

Roots Sage 9 è l'ultima iterazione di un tema di base per WordPress gestito in modo professionale, originariamente rilasciato solo come Roots nel 2011. Durante la sua vita, ha subito molti cambiamenti, miglioramenti e riconsiderazioni delle migliori pratiche, per diventare finalmente ciò che oggi è un ottimo punto di partenza per introdurre il moderno flusso di lavoro di sviluppo front-end per lo sviluppo di WordPress.

Quello che Sage sta cercando di fare è adottare un pattern MVC (Model-View-Controller) in cui Views e Controller sono completamente separati; questo ci consente di riutilizzare le Visualizzazioni, che non hanno necessariamente bisogno di "sapere" da dove provengono i dati, ma semplicemente aspettano che un Controller fornisca loro alcuni dati da visualizzare.

Il controller incluso in Sage 9 non è il controller effettivo con cui potresti già avere familiarità in altri framework come Laravel, la differenza principale è che Sage 9 Controller utilizza un routing basato su modelli anziché un routing basato su URL. Fondamentalmente, consenti a WordPress di gestire il routing degli URL e scrivi i controller per i file modello.

Aggiungendo alcuni gradi di complessità all'intero processo di sviluppo, Sage 9 potrebbe non essere la scelta migliore per iniziare per i principianti, poiché avrai un bel po' di apprendimento per padroneggiarlo ed essere in grado di usarlo in produzione: corretto gestione delle dipendenze e delle risorse, controllo delle versioni del codice, una nuova struttura del progetto, un nuovo motore di template derivato da Laravel, il principio DRY (Don't Repeat Yourself) e dovrai attenerti a rigorosi standard di codifica che sono un po' diversi da quelli WordPress consiglia; ma se sei uno sviluppatore esperto può essere un ottimo vantaggio.

Se vuoi andare all-in con Sage, tieni a mente questo consiglio di Ben Word, uno degli sviluppatori del team di Roots:

Sage non è un framework tematico, è un tema iniziale. Raramente dovresti aggiornarlo e in genere non dovresti creare temi figlio da esso. Essendo un tema di partenza, Sage è pensato per essere utilizzato come punto di partenza per un nuovo progetto.

Ma anche:

Se Underscores è un vantaggio di 1.000 ore, Sage è un vantaggio di 10.000 ore.

Struttura di file e cartelle con Sage

La struttura di file e cartelle di Sage è leggermente diversa da quella che siamo abituati a vedere in altri temi iniziali come Underscores, o anche nella precedente versione principale di Sage 8.

Questo è ciò che troverai subito dopo aver installato Sage:

 ├── app/ # it contains all the PHP code of your theme │ ├── controllers/ # your Controllers, it already contains a few │ │ # examples to use as a starting point │ ├── admin.php # setup for the WordPress theme customizer │ ├── filters.php # a good place to group all your theme │ │ # filter hooks │ ├── helpers.php # for various helper functions you want │ │ # to reuse in your theme │ └── setup.php # the main theme setup file ├── config/ # theme configuration files ├── dist/ # all built theme assets, never edit this! ├── resources/ # original theme assets, edit this instead! │ ├── assets/ # all front-end assets │ │ ├── build/ # Webpack and ESLint config │ │ ├── fonts/ # theme fonts │ │ ├── images/ # theme images │ │ ├── scripts/ # theme JS scripts │ │ ├── styles/ # theme SCSS stylesheets │ │ └── config.json # settings for compiled assets │ ├── views/ # all theme Blade templates │ │ ├── layouts/ # base Blade templates │ │ └── partials/ # partial Blade templates │ ├── functions.php # Composer autoloader and theme includes, │ │ # normally you should not edit this unless │ │ # you know what you're doing │ ├── index.php # required by WordPress but left blank │ │ # intentionally, never edit this! │ ├── screenshot.png # the screenshot used in the WordPress admin │ └── style.css # required by WordPress, it should contain │ # only the theme meta information ├── vendor/ # Composer packages, never edit this! ├── composer.json # autoloading for `app/` files ├── composer.lock # Composer lock file, never edit this └── package.json # Node.js dependencies and scripts

Inoltre, alcuni altri file utilizzati da editor di codice e IDE, come .editorconfig, .eslintrc.js, .stylelintrc.js, phpcs.xml, ecc.

Ecco una rapida panoramica dei requisiti di base di Sage 9:

• WordPress >= 4.7
• PHP >= 7.1.3 (con php-mbstring abilitato)
• Compositore
• Node.js >= 8.0.0
• Filato

Roccia di fondo

Bedrock è come WordPress sotto steroidi!

Se Sage migliora lo sviluppo del tuo tema, Bedrock migliora l'intera installazione di WordPress. Lo fa fornendo un moderno progetto standard , con una struttura e sicurezza delle cartelle migliorate (ad esempio non avendo i file di configurazione nella radice del sito Web), file di configurazione e ENV e una corretta gestione delle dipendenze (sì, inclusi plugin e temi di WordPress) .

Per descriverlo in una sola frase, potremmo dire che Bedrock è un progetto WordPress autonomo che automatizza l'installazione dei file core e dei plugin necessari.

Struttura di file e cartelle

Se guardi un'installazione di base di Bedrock, potresti sentirti perso all'inizio. Bedrock separa i file web, di configurazione e di dipendenza nelle proprie cartelle. Ecco come appare la struttura dell'osso nudo:

 ├── config/ # WordPress configuration files │ ├── environments/ # configuration files for other │ │ │ # environments, they will override │ │ │ # production configuration │ │ ├── development.php # overrides for WP_ENV === 'development' │ │ └── staging.php # overrides for WP_ENV === 'staging' │ └── application.php # main configuration for production │ # environment, it's the equivalent of │ # the wp-config.php file ├── vendor/ # Composer packages, never edit this! ├── web/ # the new root folder of the webserver │ ├── app/ # your new wp-content folder │ ├── wp/ # WordPress core files, never edit this! │ ├── index.php # WordPress view bootstrapper │ └── wp-config.php # required by WordPress, never edit this! ├── .env # all environment variables: db name, │ # user and password, salts, current │ # environment, site urls, and others ├── composer.json # here you can manage versions of │ # WordPress, plugins and other │ # dependencies └── composer.lock # Composer lock file, never edit this

Più alcuni altri file meno importanti.

I requisiti di base sono:

• PHP >= 7.1
• Compositore

Traliccio

Trellis è un moderno stack LEMP per gestire senza problemi i server di sviluppo, staging e produzione, con l'obiettivo di mantenerli il più simili possibile ("parità di sviluppo e produzione"). Ciò significa che se il tuo sito WordPress personalizzato funziona nel tuo ambiente di sviluppo, è lecito ritenere che funzionerà anche in produzione e puoi implementarlo con sicurezza.

Per lo sviluppo locale, Trellis fa uso di Vagrant, con un semplice vagrant up avrai una macchina virtuale che esegue un ambiente moderno adeguato.

Il provisioning e la distribuzione nei tuoi ambienti di staging e produzione sono gestiti con i playbook Ansible, che sono file YAML che indicano ad Ansible cosa fare.

Struttura delle cartelle consigliata per traliccio

Trellis ha una struttura di cartelle suggerita composta da due sole sottocartelle:

 ├── trellis/ # the clone of the Trellis repository └── site/ # the Bedrock-based WordPress website

Consiglierei di lasciarlo così com'è, ma può essere personalizzato a seconda dei tuoi gusti e delle tue esigenze.

Requisiti del traliccio

• Compositore
• Virtualbox >= 4.3.10
• Vagabondo >= 2.1.0

Perché dovresti usarlo

Se WordPress funziona già così com'è, perché dovresti passare a uno stack più complesso e dedicare una notevole quantità di tempo a padroneggiarlo? Perché ci sono vantaggi evidenti e alcuni meno evidenti. Proviamo a vedere quali sono.

Un tema di partenza indipendente dal framework

Troppi temi iniziali di WordPress ti costringono a utilizzare un framework CSS specifico che potrebbe piacerti o meno o addirittura conoscerlo, ma Sage è completamente indipendente dal framework. Durante l'installazione, avrai la possibilità di includere automaticamente Bootstrap 4, Bulma, Foundation, Tachyons, Tailwind CSS o nessun framework se vuoi iniziare da zero o usare qualcos'altro (SUGGERIMENTO: ultimamente sto iniziando a piacermi Tailwind CSS molto).

SUGGERIMENTO PRO: su una macchina Windows, potresti ricevere il messaggio "La modalità TTY non è supportata sulla piattaforma Windows" durante l'installazione e non sarai in grado di scegliere un framework o configurare Sage. Dovrai eseguire questi tre comandi manualmente dalla cartella del tema se vuoi sfruttare la configurazione automatica:

 $ vendor\bin\sage meta # to specify the metadata for your # theme (the name, etc., that goes # in style.css). $ vendor\bin\sage config # to specify your theme's dev URL and # theme directory. $ vendor\bin\sage preset # to set up the theme with one of the # supported frameworks or no # framework at all.

Un moderno processo di costruzione

Con Webpack, incluso in Sage, non dovrai più pensare a compilare asset, concatenare e minimizzare codice JavaScript e CSS, ottimizzare immagini, controllare JavaScript e errori di stile e gestire librerie esterne. Il processo di compilazione si occuperà di tutto ciò con una semplice yarn build (o yarn build:production se vuoi che le tue risorse siano ottimizzate per l'uso in produzione), producendo tutti i file statici nella cartella /dist/ del tuo tema.

PHP moderno e requisiti

La versione minima di PHP su cui è possibile eseguire WordPress è PHP 5.2.4, questo garantirà la compatibilità con le versioni precedenti a tutti quegli utenti che eseguono i loro siti Web in un ambiente legacy, ma le vecchie versioni di PHP (<= 7.0) hanno ufficialmente raggiunto la fine del Life, quindi non sono più supportati e potrebbero esporre il tuo sito a vulnerabilità di sicurezza e problemi di prestazioni.

Sia Sage che Bedrock richiedono una versione sana di PHP 7.1 (sebbene se hai la possibilità di scegliere 7.3, fallo).

Sage 9 adotta anche completamente gli standard di codifica PSR-2 (la codifica più utilizzata e accettata

standard utilizzati nella comunità PHP), che sono leggermente diversi dagli standard di codifica di WordPress, ma ti consentono di avere un codice più pulito e manutenibile, soprattutto se lavori in gruppo o devi condividere il tuo codice con altri.

Migliori dipendenze e gestione dei pacchetti

Lo stack Roots fa ampio uso di Composer per gestire tutte le dipendenze e i pacchetti, inclusi il core di WordPress, i plugin e i temi. Questo potrebbe essere un problema se utilizzi strumenti di terze parti per gestire gli aggiornamenti di WordPress (come ManageWP, MainWP o InfiniteWP), ma qualcuno potrebbe obiettare che avere tutto sotto il controllo della versione ti dà più controllo e rende più facile tornare a un lavoro precedente versione se qualcosa va storto.

Inoltre, Sage utilizza Yarn come pacchetto e gestore delle dipendenze per il codice dell'applicazione e per avviare il processo di compilazione.

File modello migliori

WordPress manca di un vero motore di creazione di modelli, quindi per rimediare Sage ha adottato Laravel's Blade e segue il principio DRY: non ripeterti.

Ecco come appare il file modello predefinito single.blade.php, solo 6 righe di codice:

 @extend('layouts.app') @section('content') @while(have_posts()) @php the_post() @endphp @include('partials.content-single-'.get_post_type()) @endwhile @endsection

Il motore del modello Blade separa completamente visualizzazioni e controller e la sua sintassi è più elegante, concisa, leggibile e più facile da scrivere rispetto ai semplici tag PHP. La regola pratica qui è lasciare tutto il codice PHP fuori dai file del modello (o almeno provare a farlo).

Un altro vantaggio dell'utilizzo di Blade è l'ereditarietà del modello: un modello di layout di base (l'impostazione predefinita è /resources/views/layouts/app.blade.php ) definisce i blocchi contenenti gli elementi comuni del sito Web, che vengono poi ereditati dai suoi modelli figlio. L'ereditarietà dei modelli è ottima per rimuovere il markup ripetuto dai singoli modelli e mantenere le cose ASCIUTTE.

Sincronizzazione del browser

Eseguendo yarn start avvierai una sessione di sincronizzazione del browser. Browsersync è un modulo per il test sincronizzato del browser durante lo sviluppo. Osserverà le modifiche apportate alle tue risorse front-end e, lavorando insieme a Webpack, inserisce automaticamente le modifiche nella sessione del tuo browser.

Distribuzione di WordPress rapida, facile e sicura

Trellis offre implementazioni WordPress senza tempi di inattività. Quando avvii una distribuzione, Trellis clonerà il tuo repository, eseguirà l'installazione del compositore e quindi aggiornerà il collegamento simbolico alla versione corrente in modo che non modifichi mai direttamente i file attualmente serviti in produzione.

Quando si utilizza Bedrock, Trellis necessita anche di pochissima configurazione.

Svantaggi

L'unico inconveniente dell'utilizzo dell'intero stack Roots (a parte l'apprendimento di nuove cose, che non dovrebbero essere considerate affatto un problema) è che devi utilizzare un provider di hosting compatibile con Trellis come Kinsta, una gocciolina di DigitalOcean o qualsiasi altro host che supporta almeno SSH, Composer e WP-CLI, insieme all'opzione per aggiornare il percorso della radice web.

Questo lascia fuori dal gioco la maggior parte dell'hosting condiviso economico (ish) ed è qualcosa che tu e/o il tuo cliente dovete tenere in considerazione prima di iniziare un nuovo progetto.

Come iniziare

Questo può essere considerato come una nuova versione della famosa "Installazione in 5 minuti di WordPress", ma per i moderni sviluppatori front-end. Aggiunge alcuni gradi di complessità per lo sviluppo successivo, ma alla fine, i vantaggi che puoi ottenere ne valgono sicuramente la pena.

Ci concentreremo sull'adozione dell'intero stack (Sage, Bedrock e Trellis), ma puoi semplicemente usarne uno o qualsiasi combinazione. Sage può essere utilizzato come punto di partenza per un tema autonomo su qualsiasi installazione di WordPress; Bedrock può essere utilizzato con qualsiasi tema WordPress che desideri; e le distribuzioni di Trellis sono configurate per i siti basati su Bedrock e si occupano di tutto ciò che è necessario, ma con un po' di accorgimenti può essere personalizzato per quasi tutte le esigenze.

Come creare un nuovo progetto

Configurare un nuovo progetto WordPress con Trellis, Bedrock e Sage è abbastanza semplice, bastano poche righe di comando.

Installa Trellis nella cartella desiderata (ad esempio example.com ):

 $ mkdir example.com && cd example.com $ git clone --depth=1 [email protected]:roots/trellis.git $ rm -rf trellis/.git

Installa Bedrock nella sottocartella /site/ :

 $ composer create-project roots/bedrock site $ cd site/web/app/themes/

Installa e costruisci Sage:

 $ composer create-project roots/sage your-theme-name $ cd your-theme-name/ $ yarn && yarn build

Distribuzione

La distribuzione allo staging o alla produzione è ancora più semplice se hai configurato tutto correttamente secondo la documentazione ufficiale. È solo una riga di comando di distanza (eseguita dalla cartella example.com/trellis/ ):

 $ ansible-playbook deploy.yml -e "site=<domain> env=<environment>"

Puoi anche eseguire facilmente il rollback della tua distribuzione, basta eseguire:

 $ ansible-playbook rollback.yml -e "site=<domain> env=<environment>

Suggerimenti sulla configurazione dell'ambiente di sviluppo su Windows

Se cerchi su Google come installare e utilizzare lo stack Roots, in particolare Trellis, troverai molti tutorial incentrati su Linux o MacOS, ma sono disponibili pochissime informazioni per Windows dove troverai due problemi principali: Ansible non è disponibile per Windows e Vagrant è solitamente estremamente lento su macchine Windows.

Quando inizialmente ho pensato a questo articolo, la documentazione ufficiale di Trellis per Windows suggeriva di eseguire Ansible all'interno della macchina virtuale Vagrant, ma questo era un modo hacky di fare le cose e non era molto affidabile.

Da allora hanno aggiornato la documentazione con le istruzioni appropriate sull'impostazione di tutto con WSL (sottosistema Windows per Linux), quindi non c'è bisogno di reinventare la ruota e scrivere un tutorial su di esso. È bene sapere che ci sono tre pagine di istruzioni dettagliate che puoi seguire prima di installare Trellis: Installazione di Windows, Installazione di Windows: Sage e Installazione di Windows: Trellis.

Buona codifica!