Se l’errore dice che reactions, data explorer e solved sono ancora nel tuo file yml, allora probabilmente lo sono. Se ritieni di averli commentati, potrebbero essere stati inseriti due volte?
Vale sicuramente la pena rivedere la configurazione e assicurarsi di aver modificato il file yml corrispondente al tuo sito.
Ciao
Ho aggiornato con successo il mio forum all’ultima versione 3.4.6 stable. Prima di questo, utilizzavo il plugin standalone discourse-oauth2-basic per l’autenticazione.
Non c’è login Oauth2 Basic in /admin/plugins.
La mia versione di discourse è 3.4.6.
SUGGERIMENTO: Il plugin ‘discourse-oauth2-basic’ è ora integrato con Discourse e non dovrebbe essere incluso nella configurazione del tuo container.
Rimuovi la riga ‘git clone GitHub - discourse/discourse-oauth2-basic: A basic OAuth2 plugin for use with Discourse’ dal tuo file containers/app.yml, quindi riprova.
Per maggiori informazioni, vedi Bundling more popular plugins with Discourse core
Ho dovuto rimuovere il plugin discourse-oauth2-basic prima dell’aggiornamento a 3.4.6
Potresti aiutarmi a capire cosa potrebbe essere andato storto?
Grazie!
Hmm… potrebbe essere il fatto che sei su stabile?
In seguito al prompt di sistema, ho rimosso il plugin discourse-oauth2-basic prima di eseguire l’aggiornamento alla versione stabile 3.4.6 con successo.
Tuttavia, ho ora scoperto che le opzioni di configurazione per OAuth 2 Basic sono mancanti dalla dashboard di amministrazione.
Se sei su stabile, allora nessuno di questi argomenti si applicherà fino a dopo la prossima release stabile all’inizio di agosto. Quindi dovresti riaggiungere oauth2-basic nel tuo app.yml. Il fallimento originale deve essere stato per qualche altro motivo.
Sfortunatamente la logica di ‘suggerimento’ non è molto intelligente e non è consapevole di stabile vs. tests-passed.
Anch’io, ma cosa possiamo farci, vero? lol Penso che più risorse native, alias plugin, anche se disabilitati, non siano una buona soluzione per aiutare i principianti ad auto-ospitarsi.
@nat Guarda questo, la mia traduzione della citazione e la mia risposta
Non importa come ho provato a commentare le righe di clone nella sezione dei plugin, ma le stava leggendo come se volessi installare i plugin. Cosa ho fatto? Rimuovere la riga e finalmente ha funzionato.
Quando esegui l’aggiornamento, devi controllare l’elenco dei plugin inclusi nel core di Discourse per non aggiungerlo nella sezione dei plugin per installare o rimuovere quella riga se l’hai nel tuo file app.yml.
Penso che poiché questi sono Preinstallati, dovrebbero esserci opzioni che li separino dall’elenco dei plugin installati. Poiché l’elenco dei plugin installati è rimovibile, a differenza di quelli che possono solo essere disabilitati.
Forse i plugin principali uniti dovrebbero essere sotto qualcosa come Plugin in primo piano. O Plugin principali.
Con, naturalmente, forse un filtro Tutto.
Il loro suggerimento non è l’ideale, ma funziona. Esempio:
## I plugin vanno qui
## vedi https://meta.discourse.org/t/19157 per i dettagli
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/pfaffman/discourse-allow-pm-to-staff.git
#- git clone https://github.com/discourse/discourse-hcaptcha.git
#- git clone https://github.com/discourse/discourse-calendar.git
- rm -rf discourse-adplugin
- rm -rf discourse-affiliate
- rm -rf discourse-ai
- rm -rf discourse-apple-auth
- rm -rf discourse-assign
- rm -rf discourse-login-with-amazon
- rm -rf discourse-lti
- rm -rf discourse-microsoft-auth
- rm -rf discourse-patreon
- rm -rf discourse-subscriptions
- rm -rf discourse-zendesk-plugin
(Regola a piacere)
7 post sono stati spostati in un nuovo argomento: Risoluzione dei problemi di fallimento dell’avvio in Discourse
La realtà qui è che il ramo stabile è un LTS, e anche piuttosto buono. Riceve aggiornamenti di sicurezza ed è abbastanza chiaro quali versioni dei plugin sono compatibili con esso (grazie al file .discourse-compatibility). Ammetto totalmente che ci è voluto molto tempo prima che tutto ciò iniziasse a funzionare, ma negli ultimi due anni circa, ha funzionato, il che è un grande risultato per il team.
Ora per la seconda parte della tua affermazione. È effettivamente vero che stable è spesso rappresentato come qualcosa che non dovresti volere. Ma su Communiteq hosting, da 2,5 anni offriamo ai clienti la libera scelta tra stabile (“stabilità prima, nuovi aggiornamenti due volte all’anno, aggiornamenti di sicurezza una volta al mese”) e test-superati (“sempre all’avanguardia, nuove funzionalità una volta al mese”) e l’85% sceglie di essere su stabile.
Lo capisco. Ma non è un problema di sviluppo e non un problema di produzione? Posso capire totalmente che lo stai facendo in fase di sviluppo. Ma aggiungere quei plugin in un’installazione di produzione predefinita vanifica l’idea di avere un plugin (che per definizione è qualcosa di non predefinito).
L’unico reale beneficio di produzione che vedo è il problema molto, molto marginale di disinstallare plugin e host multisito. (Di nuovo, questa è una buona cosa, tutti gli altri problemi di produzione sono stati risolti nel tempo!)
Ciò avrebbe potuto essere risolto anche nello script di configurazione mostrando un elenco di plugin che gli utenti possono selezionare e quindi aggiungerli a app.yml.
Ma offrite ancora diversi (sotto)insiemi di plugin per diversi livelli, giusto?
Avrei preferito anche l’approccio di decommentare app.yml.
Tutti questi plugin sono installati su tutti i nostri piani self-service. Alcuni livelli non hanno accesso, ma rimangono installati anche se non hanno accesso.
Non cambieremo questa decisione, quindi è semplicemente qualcosa con cui le persone dovranno convivere. Capisco che alcune persone siano turbate, alcune persone siano contrarie a questo, ma semplicemente non cambierà.
Ci dà velocità durante lo sviluppo, definisce le nostre preferenze, garantisce che Discourse, come utilizzato dalla stragrande maggioranza delle persone, sia più stabile.
Ci sono altri plugin… i plugin core non sono gli unici plugin.
Un post è stato diviso in un nuovo argomento: Discourse non distribuisce una release LTS
Concordo pienamente sul fatto che abbia senso spostare i plugin più diffusi e le loro funzionalità nell’immagine principale. Soprattutto se provengono dagli stessi programmatori (CDCK) del core stesso. Questa è una pratica comune anche per altri progetti software. Ma dovremmo risolvere i problemi di bootstraping - sono ancora ottimista 
È il motivo per cui non puoi ricostruire.
Questo sarebbe decisamente il percorso migliore. Può ancora essere implementato utilizzando il codice di rimozione del plugin nel post precedente.
Aggiungere ciò allo script di installazione offre molte più opzioni fin da subito ed è abbastanza comune nei programmi consentire di scegliere se installare o meno determinate funzionalità opzionali.
Il file di comparabilità è fantastico. Sebbene secondo me le informazioni di comparabilità dovrebbero essere aggiunte agli argomenti. Con un link o istruzioni per se il TC/plugin è disponibile sia per le istruzioni di installazione Stable che Tests-passed.
Grazie per la guida; funziona benissimo tranne per il plugin “automation”, che non può essere rimosso, poiché sembra che il plugin chat dipenda da esso.
Il plugin di automazione è qualcosa che non dovrebbe essere rimosso, onestamente. Ha così tanti potenziali usi utili. Ha bisogno di più tempo investito, secondo me, per ottenere più opzioni di automazione.
Ma sì, è bello che ci sia un’opzione per semplificare rimuovendo i componenti aggiuntivi che, come ha sottolineato @RGJ, sono stati recentemente uniti e ci si può chiedere se queste opzioni siano desiderate da installare. Forse anche uno script separato per dopo l’installazione solo per rendere le cose più amichevoli per l’auto-ospitato, in modo che alcuni che potrebbero voler evitare di dover modificare l’app.yml.