Sembrano funzionare bene, ma l’impostazione ha un punto che indica che sono sovrascritte?
Qualche idea su cosa sta succedendo qui?
PS Ho provato a cercare ‘custom header links’ ma non riesco a trovare un argomento che menzioni questo problema.
Sembrano funzionare bene, ma l’impostazione ha un punto che indica che sono sovrascritte?
Qualche idea su cosa sta succedendo qui?
PS Ho provato a cercare ‘custom header links’ ma non riesco a trovare un argomento che menzioni questo problema.
Penso che tu abbia modificato quell’impostazione. Quindi, hai sovrascritto l’impostazione predefinita, il che è molto probabile dato che questo è lo scopo di questa impostazione. L’impostazione predefinita è più simile a un esempio perché utilizzi il componente del tema per aggiungere collegamenti personalizzati. Con il pulsante di ripristino, potresti reimpostare l’impostazione al valore predefinito.
È stato molto strano
Quando ho guardato per la prima volta il mio sito, aveva nuovi link (esterni, popolari, privacy), ma i miei link erano ancora nei campi.
Ho premuto reset e ho perso la mia configurazione di link personalizzata.
Fortunatamente ho salvato il testo di ciascuno e li ho riaggiunti, rimuovendo i nuovi link.
Pazienza. Il software è strano.
Anche perplesso riguardo a questo.. In realtà il nome della variabile settings è stato modificato, vedi DEV: Rename `Custom_header_links` settings to `custom_header_links` (… · discourse/discourse-custom-header-links@5006125 · GitHub
@tgxworld C’è un bug nell’ultimo aggiornamento del componente del tema. Rinomina l’impostazione utilizzando una migrazione, ma a quel punto il nome dell’impostazione originale è già stato rinominato in settings.yml. Pertanto, la migrazione non funzionerà poiché non può più accedere alla vecchia impostazione. Migrazioni di questo tipo dovrebbero essere eseguite in due passaggi separati (e, dato il funzionamento delle migrazioni dei componenti del tema, con molto tempo in mezzo)
Quindi, chiunque aggiorni questo componente del tema perderà le proprie impostazioni.
Per quanto mi riguarda, penso che se si risalva l’impostazione anziché reimpostarla, tutto andrà bene.
Per quanto ne so, ciò funziona solo quando si aggiorna il componente del tema separatamente nell’interfaccia grafica, non quando il componente del tema viene aggiornato come parte di un aggiornamento più ampio (ad esempio, il task rake)
Penso che funzioni se aggiorni tutto il tuo sito, nota che i link sono ora quelli predefiniti, e poi risalvi l’impostazione del tema custom header links.
Anche se è facile non farlo e premere invece reset. ![]()
Questo ha funzionato per me. Mi ci è voluto un bel momento per capire cosa stesse succedendo dato che l’impostazione sembrava corretta. L’ho risolto rimuovendo il componente del tema dal mio tema predefinito (poiché stava attivamente peggiorando il sito) e notando che ora funzionava usando l’altro tema.
Sono contento che la correzione sia stata così facile da trovare, ma è stato uno shock scoprire che i link venivano modificati dopo l’aggiornamento di Discourse. ![]()
Recuperiamo le impostazioni del tema sovrascritte dal database che memorizza la chiave dell’impostazione, quindi il contenuto in settings.yml non influisce in alcun modo sulle migrazioni. Quello che sospetto qui è che non stiamo svuotando la cache?
Questo non è il modo in cui abbiamo inteso il design. Poiché non abbiamo alcun controllo su come vengono aggiornati i temi, non possiamo eseguire una migrazione in 2 passaggi.
Quindi questa è stata una regressione recente nel nostro sistema di migrazioni in cui la cache di un tema non viene aggiornata dopo l’esecuzione delle migrazioni del tema. Questo è stato corretto in
Quindi questo non è vero perché le impostazioni in realtà non vengono perse, ma la cache utilizza semplicemente il valore predefinito dell’impostazione invece delle sovrascritture nel database.
Grazie per la spiegazione e per le vostre pronte azioni.
Sto riscontrando lo stesso problema dopo aver aggiornato il componente Easy Footer. Tutte le impostazioni personalizzate sono scomparse sul frontend e sull’interfaccia utente del backend.
Sta creando parecchia confusione per i community manager. Se poi premono “Reset” sul backend, ci vuole parecchio tempo per rifare tutte le impostazioni, ancora di più per il componente Footer rispetto ai collegamenti dell’Header.
Sembra che credessimo che ciò fosse dovuto a un problema nel core che è stato risolto quando la PR sopra è stata unita.
Sai quale versione (commit) di Discourse avevano in esecuzione quando hai aggiornato il componente del tema?
Sì, stavo giusto per modificare il mio post.. questo è successo sia sul ramo stabile più recente, 3.2. Immagino che dovrebbe essere risolto anche per la versione stabile, altrimenti tutte le modifiche alle impostazioni dei componenti dovrebbero essere bloccate a una versione superiore?
Ah, certo. @tgxworld pensiamo a quale approccio abbia più senso qui per una versione stabile (backporting della correzione principale o imposizione di alcuni vincoli sulla compatibilità nei componenti che utilizzano le migrazioni delle impostazioni).
Questo è già stato fatto 2 giorni fa FIX: Update themes javascript cache after running themes migrations (… · discourse/discourse@39dffcb · GitHub
@manuel qual è l’hash del commit della tua installazione?
Oh sì, scusami, non ho aggiornato questo server! Scusate ragazzi, è solo in staging ma un cliente mi ha contattato chiedendo perché è tutto resettato.