Penso che quello che stanno suggerendo sia che se un plugin che era già incluso nel core fosse elencato in app.yaml, verrebbe semplicemente ignorato. Con una notifica che indica che l’inclusione in app.yaml era ridondante e il proprietario poteva rimuoverla.
Anche a me infastidisce un po’ il fatto che finché ho dei plugin elencati nel mio app.yaml, corro sempre il rischio di un aggiornamento fallito. Quindi ogni volta che faccio l’aggiornamento devo ricontrollare per vedere se uno dei miei plugin è stato aggiunto al core.
Perché non avere semplicemente uno script che lo faccia per il Sysop?
Io stesso organizzo i plugin per team o autore per rendermi la vita un po’ più facile, così so quali plugin sono ufficiali e cose del genere. Ma se l’idea è rendere discourse più user-friendly, questo deve essere fatto lato team.
Non è poi così diverso da quando consigliavi le persone quando un utente ha un aggiornamento interrotto a causa di un fallimento dell’aggiornamento Postreq (vero?).
Con i plugin, è esattamente qui che il concetto di Procourse Installer è stata un’ottima idea per semplificare l’installazione e la disinstallazione dei plugin senza dover usare la riga di comando.
Certo, capisco che potrebbe aver avuto bisogno di un po’ più di rifinitura in caso di problemi. Ma questo potrebbe essere abbastanza facile con un file di log o un semplice fallback se necessario dalla riga di comando. Apprezzo che questo possa renderlo più attraente per l’auto-hosting rispetto a un piano a pagamento. Tuttavia, ci sono abbastanza vantaggi per un piano a pagamento per sceglierlo comunque.
Questo tipo di gestore di plugin potrebbe anche essere creato o forkato per consentire ai piani ospitati di installare plugin all’interno del loro livello ospitato, poiché alcuni plugin potrebbero non essere necessari in un piano specifico.
In effetti mi è sfuggito un post di molto tempo fa riguardo al fatto che chat fosse inclusa e avevo provato a installarla. Non penso che il tag sia stato aggiornato sul plugin. Naturalmente ha fatto crashare il sito poiché non gradiva il tentativo di installare il plugin quando in teoria avrebbe potuto semplicemente ignorare la voce con una ricostruzione completata avvisando che poteva essere rimossa in quanto non necessaria.
Con la recente iniziativa di includere più plugin ufficiali nel core, mi chiedevo se il plugin Who’s Online fosse preso in considerazione per l’inclusione.
Ho notato che è disponibile sui piani di hosting ufficiali (contando nella quota dei plugin), quindi sono curioso se ciò indichi un movimento verso un’adozione più ampia.
Capisco perfettamente se vincoli di prestazioni o un’adattabilità filosofica significano che dovrebbe rimanere disattivato per impostazione predefinita a meno che non sia specificato diversamente in app.yml.
Attualmente non abbiamo in programma di spostare altri plugin nel core. Cakeday è stato l’ultimo e ha dovuto essere fatto separatamente dal gruppo principale a causa di alcune complicazioni nel modo in cui era precedentemente abilitato per impostazione predefinita.
Comprendo appieno la frustrazione riguardo al processo qui: certamente non è fluido come vorrei. Per fornire un po’ di contesto: il problema fondamentale è che i file app.yml non sono file di configurazione di Discourse. Sono una configurazione pups e le righe di installazione dei plugin sono solo comandi shell.
Portare la logica specifica di Discourse in pups e fargli ignorare determinati comandi shell non è davvero un’opzione. Questo strumento non viene utilizzato solo per Discourse. Inoltre, sospetto che un certo numero di persone sarebbe scontento se cambiassimo i comandi shell in esecuzione durante l’avvio a loro insaputa.
Quindi siamo arrivati alla soluzione più pulita che potessimo trovare con gli strumenti disponibili: forzare una ricostruzione CLI e quindi visualizzare un messaggio che chiede alle persone di rimuovere la riga interessata dalla loro configurazione.
Pensa attentamente prima di installare questo plugin
Penso che “installare” potrebbe essere meglio formulato come “abilitare” lì - se è tecnicamente corretto.
La formulazione attuale potrebbe dare l’impressione che avere plugin aggiuntivi inclusi sia una preoccupazione filosofica o di performance - quando in realtà si tratta solo di se siano abilitati. Poiché un nuovo plugin core che prima non era abilitato viene disabilitato per impostazione predefinita dopo la ricostruzione, il rischio non è nell’averlo installato con il core, ma nell’attivarlo.
Il plugin discourse-categories-suppressed aggiunge una semplice interfaccia utente opzionale per nascondere categorie selezionate dal feed “Latest”. Si integra tramite un singolo menu a discesa in:
Admin → Impostazioni → Categorie
“categorie soppresse dalla homepage”
Questo sembra un’impostazione di base molto naturale, soprattutto perché:
• È ufficiale e attivamente mantenuto
• Rimane disabilitato per impostazione predefinita a meno che un amministratore non lo attivi
• Molte community (inclusa la mia) si affidano a “Latest” come visualizzazione principale e desiderano un controllo più granulare su ciò che appare lì
Il team prenderebbe in considerazione l’inclusione di questo plugin (ancora disabilitato per impostazione predefinita), in modo che gli amministratori possano utilizzare questo interruttore senza dover installare nulla di aggiuntivo?
Grazie per la considerazione: sembra una piccola preferenza dell’interfaccia utente che molti siti trarrebbero beneficio dall’avere disponibile fin da subito.
Non sono sicuro se sia intenzionale, ma volevo segnalarlo:
Siamo su una versione stabile obsoleta v3.5.4 e stavamo utilizzando il plugin cakeday. Tuttavia, le ricostruzioni (della stessa versione di Discourse) hanno smesso di funzionare perché cakeday era stato unito al core. Quindi, ho disabilitato il plugin nel file yml e… beh, è sparito. Ora ricostruisce di nuovo, ma non abbiamo più i giorni di compleanno poiché l’interfaccia utente di amministrazione non mostra alcun segno che la funzionalità sia installata.
Suppongo sia perché siamo su una versione stabile obsoleta, ma è stato comunque un risultato inaspettato per una ricostruzione della stessa versione di Discourse.
Il plugin cakeday non è incluso in 3.5.4, quindi è per questo che non lo vedi più.
Sei sicuro che sia questo il motivo per cui hanno iniziato a fallire? Se hai visto qualcosa come:
HINT: Il plugin ‘$plugin’ è ora incluso in Discourse e non dovrebbe essere incluso nella configurazione del container
allora temo che questo venga mostrato per qualsiasi ricostruzione fallita quando il plugin cakeday è incluso nel file di configurazione. Questo è stato il modo più efficiente che abbiamo trovato per avvisare le persone del problema, ma può creare confusione per chi utilizza versioni core più vecchie.
Quindi, se hai bisogno del plugin cakeday, penso che dovresti essere in grado di aggiungerlo nuovamente al tuo file app.yml e ricostruire. Sospetto che il fallimento sia stato causato da qualcos’altro, che ora hai risolto.
A margine: ti consiglio vivamente di aggiornare a una versione supportata. 3.5 non riceve più aggiornamenti di sicurezza e potrebbe essere vulnerabile agli attacchi.
Cloning into 'docker_manager'...
I, [2026-03-09T15:05:49.126710 #1] INFO -- : > cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git
fatal: destination path 'discourse-cakeday' already exists and is not an empty directory.
FAILED
--------------------
Pups::ExecError: cd /var/www/discourse/plugins && git clone https://github.com/discourse/discourse-cakeday.git failed with return #<Process::Status: pid 146 exit 128>
Location of failure: /usr/local/lib/ruby/gems/3.3.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in `spawn'
exec failed with the params {"cd"=>"$home/plugins", "cmd"=>["git clone https://github.com/discourse/docker_manager.git", "git clone https://github.com/discourse/discourse-cakeday.git", "git clone https://github.com/discourse/discourse-whos-online.git", "git clone -b no-regional-flags https://github.com/mentalstring/discourse-nationalflags.git", "git clone https://github.com/discourse/discourse-yearly-review.git", "git clone https://0fa273b19b56a1a58c41484d49a01d99f1b5b8d2@github.com/mentalstring/custom-username-validator", "git clone https://github.com/discourse/discourse-saved-searches"]}
bootstrap failed with exit code 128
---
HINT: The plugin 'discourse-cakeday' is now bundled with Discourse and should not be included in your container configuration.
Remove the line 'git clone https://github.com/discourse/discourse-cakeday' from your containers/web_only.yml file, then try again.
For more information, see https://meta.discourse.org/t/373574
---
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
Aggiungere di nuovo il plugin a app.yml provoca l’errore sopra. Rimuoverlo immediatamente fa funzionare di nuovo la build. Questo plugin sembra essere l’unico problema.
Sono consapevole che siamo su una versione obsoleta e che è sulla tabella di marcia aggiornare. Volevo solo sottolineare che, sebbene non abbiamo cambiato la versione che stiamo utilizzando, 3.5.4 è passata dal compilare correttamente (con il plugin) al non compilare più con il plugin e non sembra che abbiamo alcun modo per riottenere la funzionalità del plugin (tramite plugin o nel core).
Interessante! Mi chiedo se sia perché la nostra immagine docker ora include discourse-cakeday, e poi quando il core viene “declassato” alla 3.5, lascia una directory vuota.
Se aggiungi rm -rf discourse-cakeday prima della riga git clone https://.../discourse-cakeday, allora dovrebbe pulire. Quindi dovrebbe apparire più o meno così:
Scusate per aver portato questo argomento fuori tema, ma non credo ci sia un argomento più adatto ed è in qualche modo correlato al problema precedente.
Dall’ultimo mio messaggio, penso ci siano state ulteriori modifiche su discourse/docker_manager che stanno rompendo ulteriormente le build delle versioni precedenti. Dopo una ricompilazione oggi, l’intera sezione admin di Discourse ha smesso di funzionare con errori come questo:
loader.js:247 Uncaught (in promise) Error: Could not find module `discourse/admin/models/admin-plugin` imported from `discourse/plugins/docker_manager/discourse/models/repo`
Sono riuscito a correggere la build usando questo nello yml:
- git clone https://github.com/discourse/docker_manager.git && cd docker_manager && git reset --hard 314bbd78c200860c76bb62ced65b40e7cde5aa02 && cd ..
Non sono sicuro quale fosse il commit incriminato, ma è stato sufficiente per farlo funzionare di nuovo.
Lo so, lo so, devo aggiornare (intendo davvero). Ma probabilmente ci sono altre persone come noi che sono bloccate su versioni più vecchie più a lungo del previsto per un motivo o per l’altro, ed è un po’ inaspettato che le build più vecchie si rompano senza cambiare la versione.
Comunque, ho già trovato una soluzione temporanea fino a quando non aggiorneremo, quindi condivido solo questo nel caso possa essere utile ad altri nella stessa situazione.
