README.md

This is an attempt to re-structure the ai/noblogs-wp> repository using Composer

Problemi configurazione attuale di ai/noblogs-wp>

• fare rebase upstream è oggettivamente macchinoso
• c'è una confusione semantica: i commit di noblogs potrebbero essere patch al codice, ma anche aggiunta/rimozione di plugin scritti da noi, etc.
• non ci sono controlli per evitare di fare un commit che annulla un commit precedente, complicando inutilmente la history
• non ci sono controlli per evitare di fare commit che modificano più temi/plugin/cose alla volta
• non è chiaro capire dalla history quando qualcuno ha aggiornato upstream

Proposta:

Usiamo Composer (e.g), un gestore di dipendenze per PHP.

Come testare questo repository

• Instalare composer (richiede una versione di PHP moderna, io su Ubuntu sto usando la 7.2)

apt install composer

Io ho dovuto installare alcune librerie php extra

apt install php7.2-xml php7.2zip

• per aggiornare le dipendenze di noblogs, il comando da usare è

composer update

Cosa fa composer

Nel repository c'è un file JSON chiamato composer.json, che descrive le dipendenze di Noblogs, più da una certa configurazione alla struttura del suo repository. In questo senso le dipendenze possono essere

• La release di Wordpress core
• Temi e plugins (e i mu-plugins)
• I language pack
• I plugins drop-in, tipo hyperdb
• Codice che abbiamo scritto noi, r2db, etc.
• Le patch che abbiamo deciso di applicare ai sorgenti upstream

mu-plugins (must-use plugins) e dropin

Questo due tipi di plugin sono un po' buffi: i mu-plugins sono distribuiti come i plugin normali, e purtroppo il repository wpackagist categorizza tutti come wordpress-plugin. Ma in realtà bisogna solo spostare un file (il cui nome non è standardizzato) dentro la cartella wp-content/mu-plugins. Quindi installiamo il sorgente fuori dalla directory che esporteremo (ovvero web), in una directory apposta, chiamata wp-plugins-src. In composer.json dobbiamo sia specificare quali sono questi mu-plugins, e qual'è il file da spostare (con dropin-paths).

I dropin sono simili ma peggio, nel senso che la directory di arrivo è un po' a caso. Il caso specifico è hyperdb. Siccome il meccanismo è simile, li gestisco allo stesso modo dei mu-plugins.

Codice nostro

Il codice che abbiamo scritto noi, per esempio r2db, dovrebbe essere separato da questo repository e messo nel suo proprio repository. Poi possiamo importare questi repository come dipendenze, dichiarando un repository ```vcs`` in composer.json. In futuro (in teoria la versione di Gitlab 13.1) ci potrebbe essere in Gitlab una specie di registry tipo-docker, quindi questa cosa dovrebbe essere ancora più semplice

Le nostre patch

Poi ci sono quelle che sono realmente le nostre patch al codice sorgente non-nostro. Quelle si gestiscono con una serie di file di patch, in patches. Vige la regola che una patch agisce solo su una dipendenza "unica", quindi non si possono cambiare tutti i footer di tutti i temi in una sola patch, per esempio. L'idea è avere unità di patch piccole e abbastanza semplici da leggere. Le patch vanno attivate in composer.patch.json.

In patches/ c'è una lista di patch generata da git format-patch, estraendo tutti i nostri commit di ai/noblogs-wp>. Ho escluso i commit che aggiungono/tolgono plugi, temi, lingue, etc. Bisogna fare un lavoro di revisione, capire quali vanno tenute e quali eliminate, e poi attivare quelle rimaste per la dipendenza corrispondente.

Alla fine di questo mestiere, si dovrebbe avere una base di codice essenzialmente equivalente a quella che c'è nel branch noblogs.

Struttura delle directory di Wordpress

Composer non è contento di spacchettare due dipendenze nella stessa directory. Quindi separa wordpress-core in app/wp, mentre c'è un app/wp-content dove vengono spachettati i vari temi/plugins/etc. Bisognerà fare dei magheggi per riscrivere le URL. Vedi qui e qui.