From 6c556b0c4e6adb842aa256848a4376464a869e93 Mon Sep 17 00:00:00 2001 From: lucha <lucha@paranoici.org> Date: Sat, 26 Sep 2020 12:41:54 -0700 Subject: [PATCH] aggiornato il README.md --- README.md | 24 +++++++++++------------- 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/README.md b/README.md index 95026264..ffc481ad 100644 --- a/README.md +++ b/README.md @@ -46,14 +46,6 @@ le dipendenze di Noblogs, più da una certa configurazione alla struttura del su * 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](lucha/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](https://gitlab.com/gitlab-org/gitlab/-/issues/15886)) ci potrebbe essere in Gitlab una specie di registry tipo-docker, quindi questa cosa dovrebbe essere ancora più semplice @@ -95,6 +87,14 @@ In particolare dentro ```app/wp-root``` avremo Al momento di creare il container, ci dobbiamo ricordare che i contenuti di ```app/wp-core``` vanno copiati dentro ```app/wp-root```, e che questa è l'unica directory che va tenuta dentro il container. +## 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 ```app/wp-root/wp-content/mu-plugins```. Quindi installiamo il sorgente in una directory apposta, chiamata ```vendor/```. 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```. + # 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```. @@ -135,8 +135,6 @@ 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 -* 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?) ## Plugins mancanti @@ -152,7 +150,7 @@ Plugin non ancora aggiunti: Temi che attualmente sono nel repository di noblogs-wp ma non si trovano su wpackagist -- ai-buddytheme (ovviamente) +- ~~ai-buddytheme (ovviamente)~~ tema rimosso - boumatic - bp-default - clean-home @@ -174,8 +172,8 @@ Temi che attualmente sono nel repository di noblogs-wp ma non si trovano su wpac - pixeled - ```seo_october_special``` - structure (forse structure-lite?) -- twentynineteen-child -- twentytwenty-child +- ~~twentynineteen-child~~ (c'è un repo di temi -child apposta) +- ~~twentytwenty-child~~ - uchilla1.0 - vigilance - web2zen -- GitLab