due chiacchiere

Impariamo a versionare il nostro codice

Premetto che ho scritto il post di oggi in ginocchio sui ceci: l’inglesizzazione delle parole italiane mi ha sempre dato molto fastidio, specialmente nell’ambito informatico. Però non avevo altra scelta nel titolo (e qui di seguito) e sono costretto ad usare il neologismo versionare. Che fa riferimento alla possibilità di tener traccia della storia dei cambiamenti di un testo (o di un pezzo di codice) e poter riavvolgere questo nastro immaginario a nostro piacimento, saltando da una versione all’altra in maniera semplice e quasi divertente. Puoi già intuire come una funzionalità del genere sia la chiave di volta di quello che stiamo costruendo in queste lezioni. Immagina per un attimo di dover aggiornare un plugin di WordPress all’ultima versione disponibile. Nel Far West, i cowboy cliccheranno sull’apposito pulsantino nel pannello di controllo, pregando tutti i santi a disposizione affinché non si rompa nulla. Ma non sarebbe più facile se esistesse un sistema in grado di tenere traccia di quei cambiamenti per noi, e di consentirci di tornare indietro nel tempo digitando un paio di comandi, quando qualcosa va storto? Beh, questo sistema esiste da un pezzo, e si chiama Git.

Per la cronaca, qualcuno aveva provato ad integrare Git direttamente all’interno di WordPress, ma sfortunatamente il progetto è stato abbandonato nel 2020 per l’eccessiva complessità dei vari componenti in gioco. Chissà, magari un giorno il buon Matt Mullenweg, il papà di WordPress, deciderà di rispolverare quell’idea. Nel frattempo ci tocca arrangiarci con la finestrella nera del terminale. L’idea di fondo del mio approccio è che qualsiasi frammento di codice necessario a far funzionare il tuo sito deve essere versionato, incluso WordPress. Ora, se hai installato la macchina virtuale della puntata precedente, tutto è stato già impostato per usare Git. Sul server nel quale gira il sito vero e proprio, collegati via SSH e posizionati nella cartella principale (document root). A quel punto digita:

git clone -b master https://github.com/gerlandotermini/dash.git .

Ti faccio notare che c’è un punto alla fine della stringa qui sopra, non lo ignorare. Quando ha finito, usa questo comando per inizializzare WordPress (e prenditi una pausa mentre aspetti):

git submodule update --init --recursive

git submodule foreach git checkout master

Questi due comandi installano lo scheletro della struttura del sito, sul quale presto cominceremo ad attaccare un po’ di carne. Si tratta del codice che ho scritto per i siti che gestisco al lavoro, ovviamente rilasciato con licenza gratuita. L’ispirazione l’ho presa da un vecchio post di Mark Jaquith, che già nel lontano 2011 ammoniva gli sviluppatori sull’uso corretto di certe tecnologie. Spostando WordPress in una sottocartella ed usando il concetto di sottomoduli, la gestione degli aggiornamenti è semplice e veloce. Aggiungi alla cartella un file .htaccess per far funzionare i permalink:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Alcuni commenti sui file che vedi sul server (ulteriori dettagli li trovi nella pagina di benvenuto che ho creato su Gitlab):

  • wp-config.php contiene soltanto parametri generici e non dovrebbe mai essere modificato; le impostazioni per la base di dati vanno aggiunte ad un nuovo file config.php
  • la direttiva define( 'DISALLOW_FILE_MODS', true ) disattiva la funzione che consente di aggiornare temi e plugin dal pannello di controllo
  • temi, plugin e media sono salvati in una cartella content alla radice del sito, non in wp/wp-content che quindi rimane “come mamma l’ha fatta”
  • il prefisso delle tabelle è definito in wp-config.php, ma puoi aggiungere un paio di righe di codice a config.php per cambiarlo in quello che preferisci

Ricorda che la stessa esatta configurazione è presente nella tua macchina virtuale, per il sito wp.local creato in fase d’installazione. Cambiare la versione di WordPress attiva diventa ora un giochetto da ragazzi:

  • dalla finestra del terminale posizionati nella document root del tuo sito
  • cd wp
  • git fetch --all; git checkout -b 5.9 tags/5.9

dove ovviamente 5.9 è la versione che vuoi usare. Il repository ufficiale contiene tutte le versioni, quindi con un paio di comandi puoi persino divertirti a tornare indietro nel tempo a quando WordPress era giovane 😉 Oppure puoi dare una sbirciatina a quello che bolle in pentola, selezionando master invece di una versione specifica. A questo punto, crea la base di dati tramite il pannello di controllo del tuo provider, ed aggiungi i parametri di collegamento (nome utente, password, ecc) al file config.php.

Se tutto è andato bene, dovresti poter digitare l’indirizzo del tuo sito in una finestra del browser, e vedere la schermata di installazione di WordPress. Procedi con i vari passaggi, finché non vedi la pagina di benvenuto del sito. Ora rimane solo una cosa da fare: dire al sistema che WordPress è installato in una sottocartella. Apri il pannello di controllo per gestire la base di dati (in genere chiamato phpMyAdmin), seleziona la tabella wp_options, e trova la riga che ha nella colonna option_name il valore “home”, e rimuovi “wp” alla fine dell’indirizzo nel valore corrispondente. Assicurati di poter accedere al pannello di controllo di WordPress, e personalizza le impostazioni a seconda delle tue esigenze (fuso orario, permalink, ecc). La prossima volta vedremo come installare e gestire temi e plugin.

Una considerazione finale: i puristi potrebbero aver storto il naso vedendo che ho usato il concetto di submodule per gestire WordPress come una dipendenza del progetto, anziché Composer. Pur apprezzando la potenza di quest’ultimo, ho deciso di non aggiungere un ulteriore strato di complessità all’architettura generale. Lo so che esiste il repository di tutti i temi e plugin pubblici di WordPress. Ma cosa succede quando devi sviluppare un plugin esclusivamente per il tuo sito? Oppure se devi versionare temi e plugin a pagamento che non sono presenti in WordPress Packagist? Ti devi impelagare con Satis e soci. Ecco dunque che il concetto di submodule torna più utile perché consente di usare un approccio uniforme e meno complicato su tutto il codice del tuo sito.

Commenti

  1. Trap ha detto:

    Occhio a non mettere le password su github. Non so se ancora oggi si mette quella di mysql dentro il config.php di wordpress?

    1. camu ha detto:

      Ottima osservazione. Per questo motivo l’ambiente che ho creato usa in realtà due file, wp-config.php e config.php. Il primo è tracciato su Github e non contiene le password, ma include il secondo che invece non è nel repo. Un dettaglio che ho dimenticato di spiegare a fondo nella guida qui sopra.

Lascia un commento