Похоже, они работают нормально, но у настройки есть точка, указывающая на то, что они переопределены?
Есть ли какая-то идея, что здесь происходит?
PS Я пытался искать «пользовательские ссылки заголовка», но не могу найти тему, где упоминается эта проблема
Я думаю, вы изменили эту настройку. Таким образом, вы перезаписали значение по умолчанию, что вполне вероятно, так как в этом и заключается назначение данной настройки. Значение по умолчанию скорее служит примером, поскольку вы используете компонент темы для добавления пользовательских ссылок. С помощью кнопки сброса вы можете вернуть настройку к значению по умолчанию.
Это было очень странно.
Когда я впервые зашел на свой сайт, там появились новые ссылки (внешние, популярные, конфиденциальность), но мои ссылки всё ещё оставались в полях.
Я нажал «Сброс» и потерял свою конфигурацию ссылок.
К счастью, я сохранил текст каждой из них и добавил их обратно, удалив новые ссылки.
Ну что ж. Программное обеспечение бывает странным.
Также я был озадачен этим… На самом деле имя переменной settings было изменено, см. DEV: Rename `Custom_header_links` settings to `custom_header_links` (… · discourse/discourse-custom-header-links@5006125 · GitHub
@tgxworld В последнем обновлении компонента темы обнаружена ошибка. Он переименовывает настройку с помощью миграции, но в этот момент исходное имя настройки уже было изменено в settings.yml. Поэтому миграция не сработает, так как она больше не может получить доступ к старой настройке. Такие миграции следует выполнять в два отдельных шага (и, учитывая, как работают миграции компонентов тем, с большим промежутком времени между ними).
Таким образом, все, кто обновляет этот компонент темы, потеряют свои настройки.
Кстати, я думаю, что если вы сохраните настройку заново, а не сбросите её, то всё наладится.
Насколько я знаю, это работает только при обновлении компонента темы отдельно в графическом интерфейсе, но не когда TC обновляется в рамках более крупного обновления (например, с помощью задачи rake).
Я думаю, это сработает, если вы обновите весь свой сайт — обратите внимание, что ссылки теперь стали стандартными, — а затем повторно сохраните настройку темы «Ссылки в пользовательском заголовке».
Хотя легко ошибиться и вместо этого нажать «Сброс». 
Это сработало для меня. Мне потребовалось некоторое время, чтобы понять, что происходит, поскольку настройка выглядела правильной. Я исправил это, удалив компонент темы из моей темы по умолчанию (поскольку он активно ухудшал работу сайта), и заметил, что теперь всё работает с другой темой.
Я рад, что исправление оказалось настолько простым, что я наткнулся на него случайно, но было шокирующим обнаружить, что ссылки меняются после обновления Discourse. 
Мы извлекаем переопределённые настройки темы из базы данных, где хранится ключ настройки, поэтому содержимое в settings.yml никак не влияет на миграции. Что я подозреваю здесь, так это то, что мы не очищаем кэш?
Это не то, как мы задумали дизайн. Поскольку у нас нет контроля над тем, как обновляются темы, мы не можем выполнить двухшаговую миграцию.
Это была недавняя регрессия в нашей системе миграций, при которой кэш темы не обновлялся после выполнения миграций темы. Эта проблема исправлена в
Это неверно, поскольку настройки на самом деле не теряются, а кэш просто использует значение по умолчанию для настроек вместо переопределений в базе данных.
Спасибо за объяснение и ваши быстрые действия.
У меня возникла та же проблема после обновления компонента Easy Footer. Все пользовательские настройки исчезли как на фронтенде, так и в интерфейсе бэкенда.
Это вызывает значительную путаницу у менеджеров сообществ. Если они нажимают «Сброс» в бэкенде, восстановление всех настроек занимает много времени, особенно для компонента Footer, где это даже сложнее, чем для ссылок в Header.
Похоже, мы считали, что это было связано с проблемой в ядре, которая была исправлена после слияния вышеупомянутого PR.
Вы знаете, какая версия (коммит) Discourse использовалась при обновлении компонента темы?
Да, я как раз собирался отредактировать свой пост… Это произошло и в последней стабильной ветке 3.2. Я полагаю, что это должно быть исправлено и для стабильной версии, иначе все изменения в настройках компонентов пришлось бы привязывать к более высокой версии?
Ага, верно. @tgxworld, давайте подумаем, какой подход здесь наиболее логичен для стабильной версии (бэкпортить исправление ядра или наложить некоторые ограничения на совместимость в компонентах, использующих миграции настроек).
Это уже было сделано 2 дня назад: FIX: Update themes javascript cache after running themes migrations (… · discourse/discourse@39dffcb · GitHub
@manuel, какой хэш коммита у вашей установки?
О да, моя ошибка, я не обновил этот сервер! Извините, ребята, он находится на тестовом окружении, но один клиент написал, спрашивая, почему всё сбросилось.
