Nelle prossime settimane, sposteremo diversi plugin popolari di Discourse nel repository principale. Ciò significa che Discourse verrà fornito con un numero maggiore di plugin per impostazione predefinita e sarà più facile per noi mantenerli tutti testati e aggiornati.
Tutti questi plugin rimarranno disabilitati per impostazione predefinita, quindi questo non avrà alcun impatto visibile sulle community esistenti. Se utilizzi un servizio di hosting gestito come discourse.org, non è necessario fare nulla.
Community self-hosted
Se esegui l’hosting di Discourse autonomamente e stai già utilizzando uno di questi plugin, ti verrà richiesto di rimuovere la riga pertinente dal tuo file app.yml prima della prossima ricostruzione.
Ambiente di sviluppo
Se hai già uno dei plugin installato localmente, e poi scarichi l’ultima versione di Discourse core, accadrà una delle due cose.
Se utilizzi symlink per i tuoi plugin, otterrai un errore durante git pull. Per risolvere il problema, elimina il symlink, quindi esegui nuovamente git pull.
Se cloni i plugin direttamente, il git pull del core avrà successo, ma avrai alcune “modifiche non salvate” sorprendenti causate dai repository git annidati. Il modo migliore per procedere è eliminare la directory interessata, quindi ripristinarla da main. Ad esempio:
Grazie. Con la mia scarsa conoscenza dello sviluppo e della programmazione, vorrei comunque farti una domanda. Questi plugin, che originariamente sono componenti destinati ad essere aggiunti a un’installazione di base, potranno un giorno perdere il loro carattere di plugin e diventare parte integrante di un’installazione di base, senza essere affatto chiamati plugin?
Potrebbero farlo, sì. In particolare, i plugin di autenticazione (ad esempio, apple-auth) è molto probabile che vengano assorbiti nel core, proprio come i nostri altri metodi di autenticazione integrati (ad esempio, Google, Facebook, ecc.).
Una mossa interessante che potenzia ulteriormente il discorso per impostazione predefinita e facilita le nuove installazioni.
Una domanda riguardo a:
ti verrà chiesto di rimuovere la riga pertinente dal tuo file app.yml prima della prossima ricostruzione.
Ci sarà anche un prompt o un messaggio di avviso prima/quando si fa clic sul pulsante di aggiornamento dalla pagina di aggiornamento dell’amministratore?
Se ricordo bene dalla mia esperienza, potrai aggiornare docker solo all’inizio. Una volta aggiornato docker, ti verrà mostrato un messaggio nell’interfaccia utente di aggiornamento che spiega che devi aggiornare tramite la riga di comando e come farlo.
Quindi, quando aggiorni dalla riga di comando, vedrai il SUGGERIMENTO per ogni plugin che devi rimuovere da app.yml come spiegato nel primo post sopra.
Questo è un buon aggiornamento, ma era davvero necessario? Dare un fallimento di ricostruzione mi sembra un po’ troppo severo… un avviso dell’interfaccia utente o un aggiornamento automatico (o semplicemente ignorarli del tutto) sarebbe stato meglio che mettermi una pistola alla tempia e dire “rimuovili ora”
Questo mi ha tratto in inganno la scorsa settimana quando ho provato ad aggiornare tramite riga di comando e non è riuscito (plugin delle reazioni).
Mi ha tratto in inganno di nuovo quando il mio aggiornamento da riga di comando è fallito di nuovo stamattina (plugin data explorer).
Accoglierei con grande favore un avviso sulla riga di comando prima che inizi il processo di aggiornamento, e poi inevitabilmente fallisca.
Due volte in due settimane i miei aggiornamenti sono falliti e questo ha significato che il mio Discourse è rimasto offline per tutto il tempo necessario per risolvere il problema, modificare le configurazioni, riprovare, ecc. - tutto mentre ero in un lieve stato di panico perché tutto era rotto.
Non si tratta solo di eliminare cloni di plugin ridondanti.
Abbiamo anche il problema degli scontri tra le versioni delle gem.
Sto semplicemente passando attraverso un processo di downgrade di dipendenze specifiche in un paio dei miei plugin perché il plugin principale è molto indietro.
Quindi questa mossa introduce alcune dipendenze aggiuntive non necessarie secondo me e rende la ricostruzione più fragile.
3 Mi Piace
tobiaseigen
(Tobias Eigen)
Ha separato questo argomento il
15
Sono curioso, hai ottenuto questo elenco di plugin dalle installazioni di Discourse in uso? Corrisponde a quasi il 50% della mia installazione principale!
Mi chiedo se avere tutti questi plugin inclusi nel core non appesantisca i forum? Ad esempio, ci saranno probabilmente alcuni plugin che gli amministratori non vorranno sul loro forum (ad esempio, Discourse AI), ma non avranno altra scelta che averlo aggiunto. Può essere disabilitato, ovviamente, ma mi chiedo se i file aggiunti e altro rallenteranno i forum?
Sul lato client, Discourse non serve alcun asset javascript per i plugin disabilitati, quindi non ci sarà alcun impatto lì.
Sul lato server, per i plugin implementati correttamente (come lo sono tutti questi), le personalizzazioni dei plugin vengono ignorate quando sono disabilitati. Quindi sì, tecnicamente potrebbe esserci un leggero overhead per verificare lo stato abilitato/disabilitato, ma dovrebbe essere minuscolo.
I plugin che stiamo unendo qui sono quelli che eseguiamo su ogni singola istanza di Discourse sul nostro hosting discourse.org. Quindi sono tutti molto ben testati su larga scala.
C’è un motivo per cui state facendo tutto questo in una volta sola poco prima del rilascio? Per i traduttori che lo fanno nel loro tempo libero, 3.000 stringhe aggiuntive in due settimane sono molte. E anche nelle lingue in cui i plugin erano stati precedentemente tradotti, tutti i 3.000 testi devono essere nuovamente revisionati. Ogni tanto, 300 sarebbero probabilmente più gestibili di 3.000.
Per le community self-hosted che eseguono già uno o più di questi plugin, i plugin perderanno i dati di configurazione quando verranno rimossi da app.yml e integrati nel core?
Ho configurato il plugin AI esattamente come voglio; se dovessi riconfigurarlo (o almeno annotare le opzioni di configurazione in modo da poterle riaggiungere), sarebbe utile saperlo ora.
Abbiamo cercato di rendere il processo il più agevole possibile per i traduttori sfruttando la memoria di traduzione in crowdin, in modo che le traduzioni non debbano essere rifatte da zero. Ma comunque, sono d’accordo, ci sono molte cose da revisionare.
Mi chiedo se ci sia altro che possiamo automatizzare qui, ad esempio, forse possiamo “approvare automaticamente” tutte le stringhe di questi plugin, invece di richiedere una revisione :occhi:
Tutta la configurazione/i dati verranno mantenuti.
