Avendo incontrato il problema del “fallimento della ricostruzione del plugin” all’inizio dell’auto-hosting di Discourse, posso apprezzare il desiderio di integrare versioni note e funzionanti nel core. E potenzialmente offrire una selezione più ricca di funzionalità.
Un’organizzazione focalizzata sul cliente avrebbe potuto fare un sondaggio sulla direzione dei plugin core, o almeno sui tempi. Forse me lo sono perso. Come fornitore di strumenti IT per i miei clienti (cioè utenti finali) che cercano di svolgere un lavoro reale con l’IT, ho visto molti prodotti essere rivisti in una sovra-complessità e alla fine sostituiti. Ora avremo gli auto-hoster che eseguono “rm -fr” sui plugin di cui non hanno bisogno. Capisco questo e potrei unirmi a quel club. Nella mia esperienza, codice aggiuntivo aumenta la complessità dell’integrazione, il rischio di errori di configurazione e la superficie di attacco. Ma prima o poi rimuovere qualcosa che lo sviluppatore dell’app presume sarà lì, romperà anche qualcosa.
Avrei preferito di gran lunga che gli sforzi dei jedi di Discourse fossero stati dedicati a lavorare su un metodo robusto, mantenuto e scriptato per abilitare l’archiviazione cloud di immagini, inclusa l’integrazione CDN. L’integrazione email SMTP è banale in confronto, e questo si è rotto con le modifiche a MailGun e altri, causando problemi ai siti auto-ospitati.
In effetti, sconsiglierei vivamente di utilizzare rm -rf su questi plugin. Come dici tu, ci sono rischi legati a interdipendenze impreviste in futuro. Ma inoltre, creerai una differenza nel repository git principale, il che significa che gli aggiornamenti dell’interfaccia utente tramite docker_manager falliranno quasi certamente.
Naturalmente, lasciare questi plugin nel loro stato predefinito di “disabilitato” è totalmente supportato e garantirà che non abbiano alcun impatto misurabile sulle prestazioni.
Per gli auto-hoster o per coloro che, come me, forniscono servizi di hosting per i clienti, ecco un semplice grep che elencherà se uno dei nuovi plugin inclusi è già presente nel tuo containers/app.yml
Deve essere eseguito come root e produrrà qualsiasi riga che debba essere rimossa manualmente dalla sezione dei plugin di app.yml prima della ricostruzione.
Potresti considerare di cambiarlo per fare riferimento a containers.*.yml in modo che aiuti anche chiunque abbia eseguito una normale installazione a due container dove sarebbero invece in modalità solo web? Non vuoi davvero che siano nelle tue definizioni di container, dopotutto.
@david considereresti di aggiungerlo al post principale e di mantenerlo una volta integrato cakeday?
Ringrazia ChatGPT che lo ha creato esattamente correttamente in un colpo solo da questo prompt:
Estrai gli URL di GitHub di ciascuno dei plugin menzionati in questo post https://meta.discourse.org/t/bundling-more-popular-plugins-with-discourse-core/373574#p-1810533-affected-plugins-3
Compilali in un elenco e crea un comando Unix che mi dica se uno qualsiasi di questi plugin è già menzionato in un ‘git clone’ in quel Discourse’s containers/app.yml
In apparenza, per me, questo sembra una cosa ragionevole da considerare di fare a un certo punto: avere un modo più dichiarativo per definire quali plugin vengono caricati o meno all’avvio, anche se la sorgente è ancora lì sul disco.
Detto questo, non conosco la fattibilità o l’impegno necessario per farlo.
È certamente possibile. Ma aggiunge complessità - un’altra cosa da supportare/mantenere. E sarebbe utile solo in ambienti single-tenant (cioè, non in ambienti di hosting condiviso, dove tenant diversi desiderano plugin diversi).
Se mai, penso che sarebbe più vantaggioso dedicare tempo a migliorare l’UX e le prestazioni dei plugin ‘disabilitati’ (cosa che abbiamo già iniziato a fare da quando ci siamo uniti al core).
Inoltre non ho provato a rimuovere i plugin, perché sento che comprometterebbe i miei report di bug per il meta, allo stesso modo anche il tentativo di un’installazione di hosting condiviso.
Uff, è stato un aggiornamento difficile. Identificare il problema nel registro di ricostruzione non è affatto banale per iniziare. Trovato, ho trascurato un altro plugin da rimuovere dalla nostra configurazione due volte, quindi il terzo tentativo di ricostruzione ha finalmente superato quella parte. Sarebbe stato davvero utile controllare e avvisare in primo luogo che la configurazione deve essere adattata. discourse-doctor controlla (troppo semplice, ma può essere preso come inizio) i plugin nella configurazione, quindi può essere utilizzato come base. Probabilmente troppo tardi ora, 3 settimane dopo, vabbè…
Ma non è stato tutto, abbiamo anche riscontrato errori db:migrate. Ci ho riprovato 2 volte, poi ho eseguito discourse-doctor, che ha anche eseguito la ricostruzione, e stranamente è riuscito. Ho controllato il suo codice, e non fa assolutamente nulla, e chiama la ricostruzione nello stesso modo in cui lo facciamo noi. Quindi sembra che db:migrate sia riuscito al terzo tentativo per qualche motivo? Ho letto nella discussione che il gran numero di plugin aggiunti aggiunge dipendenze, che potrebbero essere in conflitto/più vecchie di quelle utilizzate in precedenza. Fortunatamente non abbiamo avuto bisogno di aggiungere un passaggio manuale di rimozione dei plugin, aggiustamento delle dipendenze o modifica del database, come altri sembrano aver avuto bisogno. È in qualche modo previsto che l’esecuzione di db:migrate più volte alla fine riesca? Posso solo sperare che nulla sia rotto…
È stato installato in precedenza, lo abbiamo semplicemente omesso dall’interfaccia utente insieme al resto dei plugin preinstallati. La nostra interfaccia utente è stata migliorata per mostrare correttamente tutto ciò che esiste. (avevamo una serie di omissioni, tra cui Chat, che era nascosta tramite CSS)
Ho già osservato un aumento della velocità del team di sviluppo interno nel brevissimo tempo in cui questo è stato implementato. Sta portando a un prodotto più stabile, cosa di cui sono molto felice.
Nessun piano di fare marcia indietro qui. Devi adattarti al nuovo mondo.
IMO se qualcosa si rompe perché un plugin non è installato, allora questo è un bug. Il core non dovrebbe dipendere dai plugin. I plugin stessi dovrebbero elencare chiaramente i loro requisiti nelle rispettive pagine.
Ma sì, questo renderà la versione self-hosted ancora meno stabile in futuro, poiché saranno i self-hoster a inciampare in questi problemi. Tra questo e il thread diviso, non ho davvero l’impressione che la stabilità dei self-hoster sia una priorità alta per il team.
Non ci avevamo pensato in anticipo, quindi alcune approvazioni potrebbero essere andate perse. Ma siamo riusciti a trasferirne una buona parte dai progetti plugin su Crowdin al core. Faremo meglio la prossima volta poiché ora abbiamo gli strumenti per trasferire le approvazioni tra i progetti.
No, non avevamo controllato in anticipo, ma ho controllato in seguito. Nessuno dei plugin aveva commenti senza risposta su Crowdin. Abbiamo uno strumento interno che memorizza tutti i commenti pubblicati sui nostri plugin Crowdin. Potremmo persino usarlo per ripubblicare i commenti mancanti su Crowdin, ad esempio quando Crowdin elimina i commenti perché la stringa sorgente è stata aggiornata. Semplicemente non è stata una priorità implementarlo.
Concordo. Forse un’opzione per elencare i plugin core installati abilitati. Invece di mostrare semplicemente tutti i plugin. Opzioni di filtro aggiuntive sicuramente migliori.
Sono d’accordo con il sentimento. Imho la vera disconnessione è mantenerli elencati come plugin.
Una volta uniti dovrebbero essere spostati in qualcosa di marchiato come “Funzionalità Core” poiché i plugin sono visti come componenti opzionali che possono essere installati. Rispetto a parte del programma principale. Quindi è un termine improprio imho mantenerli elencati come plugin quando l’intento non è essere disinstallati.
Simile ai TC che sono stati uniti nel core come “bolle personali” non è elencato in Componenti del tema. Certo, in quel particolare caso non è possibile disabilitare l’ex TC. Se si volesse tornare a quello che era prima, sarebbe stato necessario creare un TC per annullare le modifiche
Questo eviterebbe l’elenco iniziale massiccio in Plugin installati.
Concordo assolutamente con ulteriori opzioni di filtro. Per averne anche uno per i plugin disabilitati.
Tuttavia, dopo ulteriori riflessioni e letture di altri post. Se i plugin vengono uniti al core. Non dovrebbero più essere chiamati plugin e non essere elencati in Plugin. Ma forse qualcosa come Funzionalità Core o Funzionalità Opzionali. Poiché non sono più veramente pensati per essere disinstallabili.
Non c’è motivo per cui un software per forum correttamente ingegnerizzato debba richiedere codice pubblicitario per funzionare.
Se Discourse deciderà di integrare funzionalità anti, l’unica cosa che costringerà le persone a fare sarà o fare un fork di Discourse o migrare a qualcos’altro. Coloro di noi a cui non piace la grande tecnologia / le cose pubblicitarie si sentono molto fortemente riguardo a questo. Discourse NON ce lo imporrà, non importa quanto venga spinto. (Ubuntu ha provato a farlo con noi e ora il mio repository con più stelle è qualcosa che rimuove le pubblicità ;))
Non sono sicuro di capire. Se per codice pubblicitario intendi plugin che sono fusi nel prodotto principale anziché rimanere componenti aggiuntivi/installazioni opzionali. Se torniamo indietro, troverai una varietà di “codice pubblicitario” che è stato fuso nel core.
Posso capire dalla prospettiva del team di sviluppo che molti dei loro plugin potrebbero essere iniziati come plugin per consentire test più flessibili prima di renderli integrati nel programma principale.
Apprezzo che, come per qualsiasi software, ci siano spesso funzionalità che le persone potrebbero non utilizzare e scegliere di disabilitarle, e che si trovino modi per disinstallare le funzionalità.
Sebbene ammetta che ci sono molti plugin recenti fusi che probabilmente non utilizzerei. Ma avere una semplice disabilitazione e filtrarli è qualcosa di buono per tutti.
Capisco che in parte, come affermato dal team, l’intento sia quello di semplificare le cose con componenti aggiuntivi per l’auto-hosting.
Ora, a mio parere, l’interfaccia di amministrazione dovrebbe essere più personalizzabile come lo era una volta. Poiché questo può anche aiutare le persone che migrano da un’altra piattaforma potendo caricare un amministratore lì che abbia un layout simile alla piattaforma da cui provengono. Molto simile a come Linux fa questo con alcuni che imitano altri sistemi operativi. Ma questo è un altro argomento.
Apprezzo la sensazione che discourse possa iniziare a dirigersi verso il bloatware. I reattori hanno dimostrato quanto più snello potesse essere Windows NT.
