Ho cambiato host. Ho eseguito un backup (completo, con l’opzione “includi miniature” abilitata) dalla vecchia istanza (ultima versione di Discourse).
Ho modificato l’indirizzo IP del dominio, quindi ho installato una nuova istanza di Discourse per prima cosa (installazione classica con Docker).
Poi ho copiato il backup in /var/discourse/shared/standalone/backups/default e l’ho ripristinato dalla nuova istanza.
Tutto è andato bene, tranne il fatto che i topic non hanno alcun messaggio.
I log sembrano corretti. Posso accedere, tutto è normale a parte i topic vuoti.
Qualche idea? Dove dovrei guardare se c’è un problema? Cosa dovrei fare ora?
L’impostazione CSP è stata attivata forzatamente al momento del ripristino. Alcuni componenti del tema dichiaravano script utilizzando una CDN. Questi script non erano nella lista bianca e i messaggi degli argomenti non apparivano a causa di errori JavaScript.
Più sicurezza è sempre benvenuta, anche se non mi aspetterei che Discourse modifichi un’impostazione di backup. Posso capirlo per le nuove installazioni, ma non per un backup. Non si trattava solo di una questione di backup/ripristino; non mi è venuto in mente di controllare la console del browser inizialmente. Devo ammettere che sono piuttosto frustrato per aver perso così tanto tempo/energia/sonno per un problema così banale e perché costruire Discourse è estremamente dispendioso in termini di tempo.
È positivo che tu abbia individuato la causa del problema.
Lo considererei un bug se avessi ripristinato il backup sulla stessa identica versione di Discourse. È stato così? Quando ripristini un backup da una versione più vecchia di Discourse su una versione più recente, devi aspettarti che il sistema si comporti in modo diverso.
Hai già segnalato i problemi CSP agli autori dei componenti del tema? Questo potrebbe almeno evitare che altre persone riscontrino lo stesso problema.
Probabilmente più recente, dato che aggiorniamo solo quando esce una nuova versione e l’installazione di una nuova istanza scaricherà l’ultima da test-passed.
Comunque, sia che si tratti di una versione più vecchia o più recente, a meno che non sussista una circostanza molto particolare, a mio parere le impostazioni esistenti non dovrebbero mai essere modificate in alcun modo. Inoltre, partendo dalla stessa versione di base, mi aspetto che il mio backup abbia lo stesso comportamento. Al limite, sarebbe gradito mostrare almeno un avviso non appena ci si connette a Discourse (ad esempio: “per motivi di sicurezza, l’impostazione CSP è stata abilitata”, capite cosa intendo) o in caso di qualsiasi altro tipo di modifica.
Pensa alle implicazioni di questo. Ciò che desideri richiederebbe un cambio di direzione a livello industriale.
Attualmente, quanto vale per un aggiornamento in situ si applica anche quando viene ripristinato un database più vecchio. Questo è un comportamento coerente e prevedibile per le applicazioni.
Se desideri che non vi siano cambiamenti nelle impostazioni, il metodo normale è utilizzare esattamente la stessa versione dell’applicazione.
Con “ultima versione” intendevo l’ultimo rilascio, non gli ultimi commit del ramo test-passed su GitHub.
Ma sì, si tratta della stessa versione di base 2.4.0.beta9.
Stiamo parlando solo di backup e solo di valori delle impostazioni, nient’altro. La versione di Discourse, le modifiche al database e via dicendo sono irrilevanti. Non vedo una sola giustificazione per modificare un valore di un’impostazione da un backup senza avvisare l’amministratore. Personalizzi Discourse con quelle specifiche impostazioni; non ha senso modificare arbitrariamente i tuoi valori di impostazione solo perché stai ripristinando un backup su una versione più recente di Discourse.
Come detto, se il valore di un’impostazione specifica deve essere modificato, mi aspetto che Discourse informi l’amministratore su cosa sta succedendo. Si tratta semplicemente di trasparenza e di rendere la vita dell’amministratore meno difficile. Il mio punto è che non dovresti mai alterare le impostazioni dell’utente a meno che non ci sia una valida ragione, e in tal caso, avvisare l’amministratore è più che corretto.
