Ils semblent fonctionner correctement, mais le paramètre a un point indiquant qu’ils sont remplacés ?
Une idée de ce qui se passe ici ?
PS J’ai essayé de rechercher « liens d’en-tête personnalisés » mais je ne trouve aucun sujet mentionnant ce problème.
Je pense que vous avez modifié ce paramètre. Vous avez donc remplacé la valeur par défaut, ce qui est très probable puisque c’est le but de ce paramètre. La valeur par défaut est plutôt un exemple car vous utilisez le composant de thème pour ajouter des liens personnalisés. Avec le bouton de réinitialisation, vous pourriez rétablir le paramètre par défaut.
C’était très étrange
Quand j’ai regardé mon site pour la première fois, il y avait de nouveaux liens (externes, populaires, confidentialité) – mais mes liens étaient toujours dans les champs.
J’ai appuyé sur réinitialiser et j’ai perdu ma configuration de liens personnalisée.
Heureusement, j’ai sauvegardé le texte de chacun et je les ai rajoutés, en supprimant les nouveaux liens.
Tant pis. Le logiciel est bizarre.
J’étais également perplexe à ce sujet… En fait, le nom de la variable settings a été modifié, voir DEV: Rename `Custom_header_links` settings to `custom_header_links` (… · discourse/discourse-custom-header-links@5006125 · GitHub
@tgxworld Il y a un bug dans la dernière mise à jour du composant de thème. Il renomme le paramètre à l’aide d’une migration, mais à ce stade, le nom du paramètre d’origine a déjà été renommé dans settings.yml. La migration ne fonctionnera donc pas car elle ne peut plus accéder à l’ancien paramètre. Ces types de migrations devraient être effectués en deux étapes distinctes (et, compte tenu du fonctionnement des migrations de composants de thème, avec beaucoup de temps entre les deux)
Ainsi, tous ceux qui mettront à jour ce composant de thème perdront leurs paramètres.
Pour information, je pense que si vous réenregistrez le paramètre au lieu de le réinitialiser, tout rentrera dans l’ordre.
Autant que je sache, cela ne fonctionne que lors de la mise à jour du composant de thème séparément dans l’interface graphique, et non lorsque le TC est mis à jour dans le cadre d’une mise à jour plus importante (c’est-à-dire la tâche rake).
Je pense que cela fonctionne si vous mettez à jour l’ensemble de votre site, remarquez que les liens sont maintenant par défaut, puis réenregistrez le paramètre de thème liens d'en-tête personnalisés.
Bien qu’il soit facile de ne pas le faire et d’appuyer sur réinitialiser à la place. 
Cela a fonctionné pour moi. Il m’a fallu un bon moment pour comprendre ce qui se passait car le réglage semblait correct. Je l’ai corrigé en supprimant le composant de thème de mon thème par défaut (car il dégradait activement le site) et en remarquant qu’il fonctionnait maintenant en utilisant l’autre thème.
Je suis content que la correction ait été si facile que je sois tombé dessus, mais ce fut un choc de constater que les liens étaient modifiés après la mise à jour de Discourse. 
Nous récupérons les paramètres de thème remplacés à partir de la base de données qui stocke la clé du paramètre, de sorte que le contenu de settings.yml n’affecte en rien les migrations. Ce que je suspecte ici, c’est que nous ne vidons pas le cache ?
Ce n’est pas ainsi que nous avons conçu la conception. Puisque nous n’avons aucun contrôle sur la façon dont les thèmes sont mis à jour, nous ne pouvons pas effectuer une migration en 2 étapes.
Il s’agit donc d’une régression récente de notre système de migration où le cache d’un thème n’est pas mis à jour après l’exécution des migrations de thèmes. Cela a été corrigé dans
Ce n’est donc pas vrai car les paramètres ne sont en fait pas perdus, mais le cache utilise simplement la valeur par défaut du paramètre au lieu des remplacements dans la base de données.
Merci pour l’explication et vos actions rapides.
Je rencontre le même problème après avoir mis à jour le composant Easy Footer. Tous les paramètres personnalisés ont disparu sur le frontend et dans l’interface utilisateur du backend.
Cela cause une certaine confusion pour les community managers. S’ils cliquent ensuite sur “Réinitialiser” dans le backend, il faut beaucoup de temps pour refaire tous les réglages, encore plus pour le composant Footer que pour les liens d’en-tête.
Il semble que nous pensions que cela était dû à un problème dans le cœur de l’application, qui a été corrigé lors de la fusion de la PR ci-dessus.\n\nSavez-vous quelle version (commit) de Discourse ils utilisaient lorsque vous avez mis à jour le composant de thème ?
Oui, j’étais sur le point de modifier mon message. Cela s’est produit sur la dernière branche stable, la 3.2. Je suppose que cela devrait également être corrigé pour la version stable, sinon toutes les modifications des paramètres des composants devraient être épinglées à une version supérieure ?
Ah, oui. @tgxworld réfléchissons à l’approche la plus judicieuse ici pour une version stable (rétroportage de la correction principale ou imposition de certaines contraintes de compatibilité dans les composants qui utilisent des migrations de paramètres).
Cela a déjà été fait il y a 2 jours FIX: Update themes javascript cache after running themes migrations (… · discourse/discourse@39dffcb · GitHub
@manuel quel est le hash de commit de votre installation ?
Ah oui, désolé, j’ai oublié de mettre à jour ce serveur ! Désolé les gars, c’est juste en staging mais un client m’a contacté pour savoir pourquoi tout était réinitialisé.
