Vorrei aggiornare all’ultima versione, ma ho alcuni problemi con alcuni componenti del tema.
Sono tutti miei componenti personali e li ho spostati da GitHub a GitLab. Ora, quando provo ad aggiornare Discourse (non direttamente da dentro Discourse), ricevo errori perché non sono più disponibili. Ho provato a eliminarli all’interno di Discourse, ma non vengono cancellati.
La mia domanda è: qual è il percorso per eliminarli direttamente dal server? Non riesco a trovarli.
Ho provato la modalità sicura, ma non riesco ad accedere al forum in modalità sicura.
AGGIORNAMENTO:
Esiste un file simile a app.yml dove sono archiviati tutti i temi e i componenti, così da poter eliminare l’elenco e ricostruire Discourse senza di essi?
Penso che questo sia il problema da risolvere. Il modo corretto di procedere è eliminare tutti i temi e i componenti dei temi provenienti dalla vecchia posizione e importarne di nuovi dalle loro nuove posizioni.
Questo non è possibile perché altrimenti Discourse andrebbe in un loop infinito. È per questo che ho chiesto come eliminarli in un altro modo.
Non riesco nemmeno ad accedere alla modalità provvisoria.
Una reinstallazione non è possibile nemmeno perché il backup è troppo vecchio.
Dopo aver eseguito ./launcher rebuild app, ho notato che il forum non è disponibile per gli ospiti.
Penso che disabilitare manualmente i componenti nel database sia il tipo di soluzione da considerare come ultima risorsa. È altamente rischioso, ma fattibile se non ci sono altre opzioni.
I componenti disabilitati permetteranno almeno al rebuild di avere successo, il che a sua volta consentirà l’accesso all’interfaccia di amministrazione per rimuovere e reinstallare i componenti da GitLab.
Non sono memorizzati nel DB, tuttavia il loro stato di attivazione/disattivazione è memorizzato nel DB stesso.
Non ricordo esattamente i passaggi, ma ho recentemente risolto un’installazione simile rotta.
La cosa più importante qui è sapere se il tuo container è ancora in esecuzione. Se è in esecuzione, potrei essere in grado di consigliarti come provare a disabilitare i componenti problematici dal database.
Beh, ok, è un problema.
Non è possibile usare qualcosa come pgAdmin per accedere direttamente al database?
Non conosco l’ID del tema e dei componenti perché non ho più accesso all’area di amministrazione.
Modifica:
Ho individuato il tema e i componenti.
Disattivarli non funziona, quindi come posso eliminarli tramite rails c?
Ho anche provato a sbarazzarmene con rake, ma anche rake non riesce a eliminarli.
rake themes:uninstall https://github.com/link/to/git.git
rake aborted!
Non si sa come eseguire il task 'themes:uninstall' (Vedi l'elenco dei task disponibili con `rake --tasks`)
Intendevi? themes:install
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
(Vedi la traccia completa eseguendo il task con --trace)
O qual è il comando corretto per eliminare elementi con rake?
Ottengo un elenco di comandi con rake --tasks e rake -AT, ma non c’è un comando per eliminare un tema o un componente.
Con rails c posso disabilitare un tema, ma dopo un ricaricamento rimane il vecchio tema corrotto.
Puoi provare a eseguire questi comandi nella console di Rails e vedere se riesci a caricare il tuo sito in seguito? Se non funziona, puoi provare a ricostruirlo?
Ciao @Osama. Ultimamente sono preoccupato per il problema dei componenti del tema che possono rompere una ricostruzione.
Penso che ci serva una guida howto per affrontarlo.
Penso che questa correzione qui risolva solo il caso di “costruzione interrotta perché l’URL di GitHub è rotto”, giusto?
Per le costruzioni interrotte a causa di un errore nel JavaScript, esiste un modo simile per disabilitare o rimuovere i temi da riga di comando che dovremmo includere in una guida howto?
MODIFICA: come quando fallisce se “Alternative Logos” è incluso…
Ci ho pensato anch’io per un po’ e, secondo me, ha senso per alcune community ma non per tutte. Alcune community considerano le loro personalizzazioni o temi come parte fondamentale dell’identità del sito e vorrebbero assolutamente sapere se ci sono problemi con le loro personalizzazioni quando il sito viene distribuito. Altre invece utilizzano un’installazione vanilla di Discourse con alcune personalizzazioni o componenti aggiunti sopra e potrebbero tranquillamente farne a meno per qualche giorno.
Forse la casella di controllo “Aggiorna automaticamente quando Discourse viene aggiornato” dovrebbe essere disattivata di default durante l’installazione di un nuovo tema o componente? Attualmente è attiva di default e penso che dovrebbe essere disattivata, ma serve una discussione più ampia…
No, il frammento di codice sopra (in particolare la seconda riga) disabilita l’aggiornamento automatico al momento della distribuzione per tutti i temi o componenti attualmente installati, quindi dovrebbe risolvere qualsiasi build rotta dovuta all’aggiornamento automatico dei temi, inclusi errori di JS/CSS. La sezione howto dovrebbe includere solo la seconda riga.
Anche io ho appena riscontrato questo problema. Se hai un componente collegato a un repository pubblico e poi rendi quel repository privato, le ricostruzioni falliscono. È spiacevole perché gli utenti possono apportare modifiche che potrebbero rompere il sito per gli amministratori di sistema mesi dopo.
