They appear to be working ok but the setting has a dot indicating they are overridden?
Any idea what is going on here?
PS I did try searching for ‘custom header links’ but I can’t find a topic that mentions this problem
I think you changed that setting. So, you have overwritten the default, which is very likely since that is the purpose of this setting. The default is more like an example because you use the theme component to add custom links. With the reset button, you could change the setting back to default.
It was very odd
When I first looked at my site it had new links(external,popular,privacy)- but my links were still in the fields.
I hit reset and lost my custom link config.
Fortunately I saved the text of each and added them back, removing the new links.
Oh well. Software is weird.
1 Like
Also was puzzled about this… Actually the settings variable name was changed, see DEV: Rename `Custom_header_links` settings to `custom_header_links` (… · discourse/discourse-custom-header-links@5006125 · GitHub
2 Likes
@tgxworld There is a bug in the latest update to the theme component. It renames the setting using a migration but at that point the original setting name has already been renamed in settings.yml. So the migration won’t work since it cannot access the old setting anymore. These kind of migrations should be done in two separate steps (and, given how theme component migrations work, with lots of time in between)
So everyone updating this theme component will lose their settings.
2 Likes
FWIW I think if you re-save the setting rather than reset it then it all comes good
AFAIK that only works when updating the theme component separately in the GUI, not when the TC is updated as part of a bigger update (i.e. the rake task)
2 Likes
I think it works if you update your whole site, notice the links are now the default, and then re-save the custom header links theme setting.
Though it is easy not to do that and press reset instead. 
This worked for me. It took me a good moment to figure out what was going on since the setting looked correct. I fixed it by removing the theme component from my default theme (since it was actively making the site worse) and noticing it was now working using the other theme.
I’m glad the fix was so easy I fell into it, but it was a shock to find the links getting changed after updating Discourse. 
We pull the overriden theme settings from the database which stores the key of the setting so the content in the settings.yml does not affect the migrations at all. What I suspect here is that we are not clearing the cache?
That is not how we intended the design to be. Since we have no control over how themes are updated, we cannot do a 2 step migration.
1 Like
So this was a recent regression with our migrations system where the cache for a theme is not updated after theme migrations are run. This has been fixed in
So this is not true because the settings are actually not lost but the cache is just using the setting’s default value instead of the overrides in the database.
4 Likes
Thank you for the explanation and your quick actions.
2 Likes
Just having the same issue after updating the Easy Footer component. All custom settings are gone on the frontend and on the backend ui.
It’s causing quite some confusion for community managers. If they then push “Reset” on the backend, it takes quite some time to re-do all the settings, on the Footer component even more so than with the Header links.
Looks like we believed this was due to an issue in core which has been fixed as when the above PR was merged.
Do you know what version (commit) of Discourse they had running when you updated the theme component?
Yes, I was just about to edit my post… this happened both on the latest stable branch, 3.2. I guess it should be fixed for stable as well though, otherwise all changes to component settings would need to be pinned to a higher version?
1 Like
Ah, yep. @tgxworld let’s think about which approach makes the most sense here for stable (backporting core fix or imposing some constraints on compatibility in components that use settings migrations).
1 Like
That was already done 2 days ago FIX: Update themes javascript cache after running themes migrations (… · discourse/discourse@39dffcb · GitHub
@nolo what’s the commit hash of your install?
1 Like
Oh yeah my bad, didn’t update this server! Sorry guys, it’s just on staging but had a client reach out why it’s all reset.
3 Likes