Come affrontare lo sviluppo moderno di WordPress (parte 1)

Non è un segreto che la base di codice di WordPress sia un disastro. Personalmente, ogni volta che ci passo, tutto quello che voglio è rannicchiarmi e piangere. D'altra parte, WordPress è molto più avanti della concorrenza. Un CMS facile da usare e potente è un'impresa enorme e WordPress rimane popolare perché offre questo.

Allora perché dovremmo preoccuparci della qualità del codice nel core di WordPress? Funziona, giusto?

Sì, funziona ed è improbabile che il codice base di 15 anni venga completamente rifattorizzato dai suoi manutentori volontari. Sfortunatamente, questo significa che funziona anche come un esempio di codifica "alla maniera di WordPress", scusando numerosi sviluppatori per non aver seguito le migliori pratiche e le moderne tecniche di sviluppo. Così tanti plugin e temi WordPress hanno un codice malfamato e seguire ciecamente le pratiche legacy continua solo la tendenza.

Ma chi se ne frega del codice errato che fa ancora il suo lavoro? Bene, niente è gratis e qualcuno paga per un lavoro fatto male. Con la stessa codebase di WordPress, i suoi manutentori pagano con il loro tempo, per fortuna. Ma con il tuo codice, è il tuo cliente che paga.

Per qualsiasi sistema anche moderatamente complesso, il costo di sviluppo iniziale è insignificante rispetto al costo di manutenzione e la manutenzione significa anche aggiungere nuove funzionalità. Assumere uno sviluppatore per riparare software mal progettato e implementato costerà molte volte di più che svilupparlo correttamente dall'inizio.

Le soluzioni economiche sono sempre le più costose a lungo termine. Oppure vengono abbandonati dopo aver esaurito il budget. Risparmiamo effettivamente i soldi dei clienti quando seguiamo principi e pratiche di progettazione software comprovati. Questi metodi non sono una moda stravagante, né cambiano per il bene del cambiamento. La saggezza qui nasce dall'esperienza collettiva degli sviluppatori e seguirla ripaga davvero.

Ovviamente, questo non si applica a compiti veramente semplici come l'aggiunta di alcune righe di CSS o un paio di post personalizzati e riscritture. Ma mettere insieme alcuni plug-in (o più comunemente diverse dozzine di plug-in) o sfornare un sito basato su Visual Composer non è comunque ingegneria del software.

Non è una brutta cosa, di per sé : il fatto che alcune soluzioni siano così semplici è il motivo per cui WordPress è così popolare. Ma in questa serie parlerò del vero sviluppo di WordPress: scrivere codice PHP, HTML, CSS e JavaScript significativo. Inizierò con il flusso di lavoro generale e poi mi concentrerò sullo sviluppo del front-end di WordPress in questo articolo.

Flusso di lavoro di sviluppo moderno di WordPress

In generale, il codice di qualità è:

• Leggibile. È facile capire cosa fa il codice e perché.
• Modulare. Piccoli blocchi di codice con uno scopo chiaro sono facili da capire, sviluppare e testare.
• Riutilizzabile. Il riutilizzo di moduli già sviluppati per risolvere problemi simili accelera notevolmente lo sviluppo.
• Mantenibile. Modificare le vecchie funzionalità o introdurre nuove funzionalità è facile.

I risultati principali, minori costi di sviluppo e di proprietà, hanno molti vantaggi derivanti dallo spin-off di cui non parlerò qui.

Invece, mi concentrerò su quali tecniche di sviluppo e best practice possono aiutarti a produrre codice di qualità. Iniziamo con il controllo della versione.

Usa il controllo della versione

Questo significa usare Git. Purtroppo, la "codifica da cowboy" sulla produzione tramite FTP è praticamente ancora una cosa. Proprio di recente ho lavorato per un'agenzia con sede nel Regno Unito e avevano file con nomi come questi su tutta la loro base di codice:

• functions copy.php
• functions copy 2.php
• functions test.php
• functions2.php
• functions test2.php

La prima cosa che dovresti fare quando accedi a un sito WordPress è metterlo sotto il controllo della versione. Tanking Servers è una divertente retrospettiva degli errori di sviluppo di WordPress. Sarebbe stato molto facile modificare quelle, e simili disavventure che probabilmente sono accadute a tutti, usando Git.

Hai commesso un errore nel tuo codice e l'intero sito è andato giù? git reset riporta tutto come prima. L'aggiornamento della nuova versione ha rotto tutto? git reset funziona come una macchina del tempo. Qualche codice dannoso è apparso dal nulla? git status mostra tutti i nuovi file, i file eliminati o le modifiche a qualsiasi file tracciato. Quindi esegui semplicemente il git checkout , ripristinando gli originali.

Attenzione all'esposizione della cartella .git

OK, è chiaramente importante usare Git. Ma quando lo fai, è altrettanto importante evitare di esporre il tuo repository Git ad essere violato. Il problema arriva quando hai le cartelle .git esposte e in esse memorizzi le tue credenziali.

Un'installazione standard di WordPress risiede completamente in una cartella Web pubblica ed è molto probabile che sia presente anche la cartella .git . Ovviamente, nessuna credenziale di accesso dovrebbe essere memorizzata nel repository Git, ma succede che la maggior parte dei repository contenga alcune informazioni sensibili che non dovrebbero essere divulgate all'esterno.

Quindi l'accesso pubblico alla cartella .git dovrebbe essere bloccato. Se stai usando Apache, l'aggiunta dello snippet in basso nella parte superiore del file .htaccess bloccherà l'accesso alla cartella .git e anche ai file di registro. I file di registro spesso contengono informazioni riservate, quindi è consigliabile renderli non disponibili. Per diverse configurazioni del server web, chiedi aiuto al tuo esperto DevOps.

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

Usa ambienti separati

Non eseguire lo sviluppo su siti live: questa è una ricetta per tempi di inattività e clienti insoddisfatti. OK, ma come dovresti configurarlo?

Idealmente, dovrebbero esserci tre ambienti di sviluppo, con il codice che va sempre in una direzione: locale → staging → produzione. Questo è un metodo collaudato per evitare le collisioni. Tutti gli aggiornamenti di base, plug-in e temi vengono prima eseguiti localmente, quindi testati sullo staging e infine distribuiti in produzione.

Ad esempio, la configurazione specifica del server potrebbe essere archiviata in un file separato. Puoi creare un wp-config-local.php per ogni ambiente locale e di staging. (Non dimenticare di aggiungerlo al tuo file .gitignore !) Quindi aggiungi il seguente snippet a wp-config.php :

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

Spesso il modo migliore per configurare ambienti diversi è utilizzare le variabili di ambiente. Se non hai familiarità con questo concetto, ti consiglierei di utilizzare una soluzione moderna completa come Roots.

Usa WP-CLI

L'interfaccia della riga di comando di WordPress (WP-CLI) è uno strumento estremamente utile per la gestione delle installazioni di WordPress. Avere accesso a WP-CLI significa avere la possibilità di eseguire praticamente qualsiasi funzione dell'API di WordPress. Ad esempio, puoi aggiungere, rimuovere e modificare utenti e le loro password con WP-CLI. Utile se hai appena ereditato un sito e il proprietario si è bloccato.

Un altro esempio è che la distribuzione iniziale è un gioco da ragazzi con WP-CLI. Questi possono essere realizzati con pochi comandi:

• Download di core, temi e plugin
• Ricerca e sostituzione nel database
• Aggiunta di un utente amministratore

Inoltre, queste azioni possono essere programmate e automatizzate.

Usa le opzioni di distribuzione avanzate

Parlando di automazione, vale la pena imparare alcune tecnologie e processi di implementazione come:

• Integrazione continua/implementazione/consegna continua (CI/CD)
• Docker
• Test automatici (inclusi test di regressione front-end)

Certo, passare dal non utilizzare il controllo della versione alla gestione di Docker è un enorme salto da fare e sarà probabilmente travolgente per un tipico progetto WordPress di una sola persona. Alcune opzioni potrebbero non essere nemmeno possibili a seconda del provider di hosting. Ma l'implementazione avanzata è un must per i team e per progetti più grandi.

Usa Linting

Per progetti di qualsiasi dimensione, tuttavia, linting è un vantaggio per la maggior parte degli sviluppatori. Linting significa controllare automaticamente la presenza di errori nel codice. Un IDE completo come PHPStorm lo fa già fuori dagli schemi; tuttavia, editor più semplici come VSCode o Sublime Text necessitano di un programma dedicato chiamato linter. Un modo per impostare questo è configurare il tuo editor per eseguire un linter ogni volta che salvi un file.

PHP_CodeSniffer è il linter di fatto per PHP. Oltre a controllare gli errori di sintassi, può anche verificare se il codice segue linee guida di stile come PSR-2. Ciò semplifica notevolmente i seguenti standard di codifica.

Per JavaScript, ESLint è un linter popolare. Ha un set di regole completo e supporta configurazioni personalizzate per tutte le versioni e framework di JavaScript disponibili.

Un potente caso d'uso in questo caso è l'incorporazione di linting in una pipeline di build CI/CD in modo che tutto il codice venga automaticamente convalidato prima di essere distribuito.

Moderne tecniche di sviluppo front-end di WordPress

Con un flusso di lavoro adeguato ora impostato per il tuo progetto WordPress complessivo, immergiamoci nelle migliori pratiche per il front-end.

Usa strumenti moderni: Sass ed ES6+

Il mondo dello sviluppo front-end è in continua evoluzione e sempre in movimento. Una volta pensavamo che Sass fosse lo strumento migliore per scrivere CSS, e per lo sviluppo di WordPress pre-Gutenberg, lo è ancora, ma poi tutti hanno iniziato a parlare di CSS-in-JS e di componenti in stile.

Anche WordPress non ha resistito e ha raccolto alcune di queste nuove tecnologie. Gutenberg, il nuovo editor di blocchi, è basato su React e un'API REST.

Dovresti assolutamente aggiornarti con queste principali tecnologie front-end:

• ES6+. La documentazione di WordPress lo chiama ESNext e incoraggia persino a usarlo.
• Sass. Utilizzato da WooCommerce e il modo migliore per scrivere CSS se non ti piace ancora CSS-in-JS.
• Pacchetto Web. Anche il core di WordPress ora utilizza Webpack e Babel.

ES6 e Sass sono rispettivamente JavaScript e CSS moderni e Webpack è uno strumento che consente di utilizzare tutte queste moderne funzionalità senza preoccuparsi della compatibilità con le versioni precedenti. Webpack può essere chiamato un compilatore di app front-end che genera file da utilizzare in un browser.

Transizione da jQuery a Vue.js o React

Il core di WordPress e quasi tutti i plugin di WordPress dipendono da jQuery, quindi non puoi semplicemente smettere di usarlo. In realtà, non ha senso smettere di usarlo per compiti semplici come nascondere un paio di <div> so fare una richiesta AJAX una tantum quando sei abituato a farlo in quel modo. jQuery verrà comunque caricato ed è semplice e facile da usare.

Le app complesse sono dove jQuery lotta: logica difficile da seguire, callback hell, variabili globali e nessun modello HTML. Ciò richiede chiaramente un modo diverso di organizzare l'app front-end.

Le moderne librerie front-end come React utilizzano i principi della programmazione orientata agli oggetti (OOP) e organizzano l'architettura delle app front-end in componenti modulari e riutilizzabili. Un componente contiene tutto il codice, il markup e lo "stato del componente" (variabili) per un particolare elemento. Un elemento potrebbe essere praticamente qualsiasi cosa: un pulsante, un campo di input, un modulo utente o un widget che mostra i post recenti dal back-end dell'API REST di WordPress. I componenti possono contenere altri componenti, formando una relazione gerarchica.

Con la complessità delle pagine Web al giorno d'oggi, organizzare un'app in componenti è un modo collaudato per creare app Web gestibili e veloci di qualsiasi complessità. I componenti sono "mattoni" altamente riutilizzabili, isolati e quindi facilmente testabili, quindi vale davvero la pena imparare questo concetto.

Ci sono due librerie basate su componenti che sono di tendenza al momento: Vue.js e React. React sarebbe una scelta ovvia perché è già utilizzato da Gutenberg. Tuttavia, per qualcuno che non conosce JavaScript moderno, Vue.js potrebbe essere migliore per cominciare.

React ti porta subito nel profondo utilizzando le funzionalità, le classi, la sintassi JSX proprietaria e la pipeline di build Webpack di ES6. La curva di apprendimento è piuttosto ripida.

Vue.js, d'altra parte, è molto più adatto ai principianti e può essere utilizzato semplicemente inserendo un tag <script> . Vue.js utilizza JavaScript (ES5), HTML e CSS semplici. L'introduzione di nuovi concetti è molto più graduale.

Dopo aver lavorato su alcuni progetti Vue.js, sarai più preparato per immergerti in profondità in React. Non che sia sempre necessario, ma lo sviluppo di Gutenberg, ad esempio, lo richiede.

Usa l'API REST di WordPress

L'API REST di WordPress è solo un'interfaccia standardizzata per richiedere e modificare in remoto i dati da WordPress. È più un'architettura software che un modo completamente diverso di codificare. Gli stessi vecchi frammenti di jQuery AJAX potrebbero essere utilizzati con parametri leggermente diversi.

Il vantaggio più importante? Poiché l'API REST di WordPress standardizza la comunicazione tra il back-end e il front-end, è un passo importante verso la modularità, la riutilizzabilità e la leggibilità nel codice. Quei terribili modelli con HTML e PHP mescolati insieme e un po' di SQL gettato nel mix devono essere eliminati. Una volta che i modelli sono solo HTML con segnaposto per i dati passati come parametri, non c'è alcuna differenza sostanziale tra il passaggio di tali dati in PHP o tramite un'API REST a un'app front-end.

Potresti anche voler esaminare WPGraphQL. Potrebbe o meno sostituire l'API REST di WordPress, ma sta guadagnando terreno rapidamente.

Impara Gutenberg (i clienti lo richiederanno presto)

L'obiettivo finale di Gutenberg è la personalizzazione completa del sito, tra gli altri piani.

Questo pone le basi per un nuovo modello per WordPress Core che avrà un impatto sull'intera esperienza di pubblicazione della piattaforma.

La pagina del progetto WordPress Gutenberg su GitHub

Gutenberg ha ricevuto importanti respingimenti dagli sviluppatori di WordPress. Alcuni degli argomenti contro la sua fusione nel core di WordPress erano:

• Una quota significativa di utenti finali non ne ha bisogno, quindi dovrebbe essere un plug-in opzionale e non parte del core
• Ha rotto alcuni siti
• Semplicemente non era pronto e poteva usare più lucidatura e meno bug

Tuttavia, per gli autori di contenuti che utilizzano WordPress come piattaforma di blogging, Gutenberg offre chiaramente un'esperienza migliore rispetto al vecchio editor.

La disabilitazione di Gutenberg sarà supportata finché sarà necessario, sì. Ma ora è un'idea saggia: quando un cliente si avvicina a te e ti chiede di fare lo sviluppo di Gutenberg, sarai pronto.

È ora di mettersi al passo: anche il "modo WordPress" si sta evolvendo

L'argomento più comune contro l'utilizzo di tutti gli strumenti e le tecniche sopra descritti nello sviluppo di WordPress è questo: il "modo WordPress" di fare le cose funziona ancora, e questo modo dovrebbe essere migliore di tutte queste nuove cose brillanti.

Ma ora hai visto che gli sviluppatori principali di WordPress sono ben consapevoli di tutti gli ultimi sviluppi. Non solo, li usano il più possibile nelle parti più nuove del nucleo a causa dei loro ovvi vantaggi. L'unica cosa che ci trattiene è il codice legacy che nessuno refactoring.

Da tempo WordPress e WooCommerce seguono la pratica di sviluppare “plugin di funzionalità” che implementano e utilizzano nuove tecnologie. Quando è il momento giusto, questi plugin vengono uniti nel core, come ha fatto Gutenberg. WooCommerce ha anche il suo progetto React. Anche l'API REST di WordPress è iniziata come plug-in separato e ora fa parte del core di WordPress.

La domanda non è se dovremmo imparare cose nuove e usarle nel mio lavoro quotidiano, ma come . La risposta è "gradualmente", un passo alla volta. O impara una cosa nuova o fai qualcosa che conosci bene in un modo nuovo e diverso.

Ad esempio, impara come utilizzare Webpack con tutti i tuoi vecchi script. Webpack può trasferire il tuo nuovo codice ES6+ in JavaScript "semplice" compatibile con i browser meno recenti. Può anche minimizzare gli script e raggrupparli insieme. Questa è una cosa nuova. Fatto? Quindi riscrivi il tuo JavaScript sfruttando le funzionalità di ES6. È un nuovo modo di fare ciò che conosci bene.

Il risultato: imparerai Webpack ed ES6. Come professionisti, dovremmo fare un passo avanti e non fare un passo indietro. Continua sempre ad imparare. E condividi quando lo fai: Toptal mantiene un elenco delle migliori pratiche di sviluppo di WordPress e accoglie con favore i contributi della community.

Nella parte 2 della nostra serie, ci addentreremo nella parte PHP del moderno sviluppo back-end di WordPress.