dove ```<ACCESS_TOKEN>``` è il nostro token personale. A quel punto composer crea un file ```auth.json``` nel repo, che è vostro personale e non va mai committato (è già in ```.gitignore```).
In questo repository ci sono solo le patch ed i file di configuarazione di composer (al momento, ~8Mb). Il codice vero e proprio di noblogs (l'equivalente di ai/noblogs-wp> per intenderci) potrebbe non essere mantenuto in git, dato che viene generato da composer a partire da questo repository. In pratica, è comodo averlo in un repository git, per facilitare la scrittura delle patch. Non sono del tutto sicuro quale dovrebbe essere il funzionamento di tutto ciò a regime. Per il momento, ho deciso di separare il codice in un subrepository, noblogs/noblogs-codebase>. Per inizializzarlo, bisogna lanciare
```shell
git submodule init
```
In questo repository ci sono solo le patch ed i file di configuarazione di composer (al momento, ~8Mb). Il codice vero e proprio di noblogs (l'equivalente di ai/noblogs-wp> per intenderci) abbiamo deciso che non verrà mantenuto in git, dato che viene generato da composer a partire da questo repository. Lanciando ```composer install``` dovrebbe venire tutto generato nella directory ```app/```.
* Per aggiornare le dipendenze di noblogs, il comando da usare è
``` shell
...
...
@@ -86,6 +83,8 @@ composer update nothing
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](https://www.smashingmagazine.com/2019/03/composer-wordpress/) e [qui](https://roots.io/docs/bedrock/master/server-configuration/#apache-configuration-for-bedrock).
Altenativamente, possiamo rimettere tutto a posto quando creiamo l'immagine Docker, che forse è la cosa più semplice da fare.
# Come dovrebbe funzionare a regime
Una volta finita la attuale transizione, questo repository dovrebbe funzionare come segue. I contenuti della directory ```app``` devono essere generati da ```composer```.
__TODO__: questo non è più vero, dato che ```app/``` non è in git, quindi le patch vanno create usando diff direttamente. Andrebbero scritte delle instruzioni.
Le patch in ```patches/``` si possono generate ed aggiornare usando ```git```. Infatti, possiamo fare delle modifiche in ```app/``` e transformarle in un file patch con
``` shell
git diff >> patches/nomepatch.patch
...
...
@@ -124,11 +125,8 @@ ricordandosi che ogni file di patch può modificare solo un singolo tema/plugin.
* ```wp-cache.php```: su noblogs abbiamo una versione leggermente modificata di ```wp-cache-config-sample.php``` presente in ```wp-super-cache```. È una cosa che dobbiamo spostare fuori al livello del container docker, o va in qualche modo tenuta qui dentro?
* tutte le patches di wp-cache, che non ho ancora avuto il coraggio di metterci le mani
* ```.htaccess```: anche lui, sta qui o sta in noblogs-docker?
* Cosa fanno i commit e01b38062c619d3c95d88486e27ee383d42e7002,
6cecf525477f01faa458b7925ead388f7415d030 e 70c22128a3f9fea7793c4dac189280d652fd54f1 esattamente?
* I commit e01b38062c619d3c95d88486e27ee383d42e7002,
6cecf525477f01faa458b7925ead388f7415d030 e 70c22128a3f9fea7793c4dac189280d652fd54f1 creano dei temi "-child" invece che patchare i temi originali. Volendo potremmo tenere i temi child in repo separati ed installarli come dipendenze, invece che mantenerli come file di patch? (temo che ogni tema dovrebbe avere un suo repository git separato, ma forse questo non è del tutto male?)
