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.
