Ho notato che le persone tendono a provare la modalità provvisoria non appena qualcosa si rompe, specialmente quando utilizzano personalizzazioni di terze parti. È comprensibile: non si sa da dove provenga il problema.
Tuttavia, la modalità provvisoria disabilita solo JavaScript. Se è presente del codice lato server, la soluzione immediata consiste solitamente nel rimuovere il commento da tutti i plugin nel file app.yml. Va bene, ma richiede una ricompilazione ed è relativamente “tecnica”. Se sei un utente non tecnico, commentare elementi nel file app.yml non è qualcosa che si fa alla leggera.
Mi chiedo se sia fattibile una PR che aggiunga la disabilitazione dei plugin lato server nella modalità provvisoria. Immagino qualcosa di simile a quanto segue nel controller della modalità provvisoria.
find_opts = {
include_official: params["only_official"] != 'true',
include_unofficial: params["no_plugins"] == "true"
}
Discourse.find_plugins(find_opts).each do |plugin|
if plugin.enabled_site_setting.present?
SiteSetting.set(plugin.enabled_site_setting, false)
end
end
Sì, lo stesso effetto potrebbe essere ottenuto dall’utente navigando nelle impostazioni del sito e disattivando i plugin in quel modo, ma trovo che gli utenti raramente lo facciano effettivamente.
La modalità provvisoria attuale è valida solo per la pagina corrente e si disattiva aprendo una nuova scheda o aggiornando la pagina. Quindi è assolutamente sicura per i test.
La tua proposta ne cambierebbe il significato, trasformandola nell’attivazione persistente di un’impostazione che influisce su tutto il sito. Ciò significa che dovrebbe essere riservata agli amministratori.
Capisco la tua proposta, ma si tratta di un cambiamento significativo nel comportamento.
Penso che il punto chiave sia che gli amministratori di siti non tecnici cercano una soluzione per far funzionare il loro sito quando si guasta. Una “modalità sicura” è spesso percepita come in grado di farlo (a ragione o meno). Forse un modo per farlo sarebbe prevedere controlli aggiuntivi per la modalità sicura nell’area di amministrazione.
Potresti aggiungere un grande pulsante nella rotta /admin/plugins per disabilitare automaticamente tutti i plugin allo stesso modo, ma mi chiedo se avrebbe lo stesso effetto. Forse sì.
Sono anche attratto da questa idea perché è piuttosto realizzabile all’interno dell’attuale architettura dei plugin di Discourse.
Di solito, ciò che rompe i plugin sono modifiche incompatibili al core; spesso, se si include un plugin problematico, il sistema non si avvia nemmeno, o non riesce a eseguire il bootstrap.
Una funzionalità per disattivare tutti i plugin dovrebbe in qualche modo riavviare l’applicazione per essere corretta.
Credo che sarei favorevole a una modifica del plugin di gestione Docker che permetta di disabilitare/abilitare facilmente i plugin spostando i file dentro e fuori dalla directory dei plugin e riavviando l’app; ciò potrebbe rendere il debugging più veloce.
Tuttavia, rilevo che un numero non trascurabile di errori proviene dal codice racchiuso nell’API del plugin lato server, che verrebbe gestito da questo (credo?).
Attualmente, la ‘modalità sicura’ (o qualcosa di simile) non è una soluzione completa ai problemi di rottura. Aggiungere una disattivazione automatica dei plugin renderebbe la soluzione leggermente migliore, riducendo il numero di casi in cui è necessario un riavvio completo o una modifica della configurazione, e riflettendo meglio come gli amministratori di siti non tecnici la vedono.
Immagino che stia cercando passi incrementali relativamente semplici. Forse la modifica del gestore Docker è altrettanto diretta dal punto di vista tecnico.
Sì, se possibile in futuro, sarebbe molto utile avere un singolo booleano “disattiva tutti i plugin” nelle impostazioni di amministrazione, che funzioni senza dover ricostruire alcun container. Tuttavia, non essendo uno sviluppatore di Discourse (avendo solo un anno di esperienza nello sviluppo di app con node.js e vuejs), il mio istinto mi dice che non si tratta di una modifica semplice e richiederebbe un cambiamento molto significativo dell’architettura.
Il nostro vecchio forum LAMP aveva questa funzione e non possiamo contare quante volte abbiamo usato questo booleano per identificare rapidamente se un errore fosse legato ai plugin. Tuttavia, l’architettura del software è così diversa che non è nemmeno utile fare un confronto.
Sono personalmente fiducioso che il team di Discourse troverà una soluzione. Molti utenti sono dipendenti dai plugin e col tempo emergeranno sempre più problemi.
Grazie per aver preso in considerazione la questione.
Un fattore importante per me è che questa funzionalità sarebbe al 100% per chi fa l’auto-hosting; non voglio davvero dover mantenere una modalità di sicurezza per i plugin nel core, poiché certamente non la useremmo: coordinare un riavvio attraverso 5 cluster è difficile.
Docker manager è lo strumento giusto qui: supporta già il riavvio dell’applicazione, qualcosa di necessario perché la tua proposta funzioni, e può fare tutto ciò di cui ha bisogno senza modifiche al core di Discourse.