Previously selected user themes can override allowed themes
A theme issue was reported where users can still use a previously selected theme even if it’s no longer available. pfaffman noted that users who had selected a theme that was later made unavailable would still see that theme, and the theme selector would not be available if only one theme is allowed.
It was suggested that clearing the browser cache could resolve the issue, and Vaping_Community confirmed that this worked on their v2 instance. pfaffman also suggested updating user themes via the Rails console, using a command like UserOption.update_all(theme_ids: [theme_id]).
However, david noted that the theme_key is no longer used, and the correct command should use theme_ids instead. WaitroseCarpark successfully used this method to update user themes on their instance.
sam clarified that this issue only affects administrators, as end users can only see user-selectable themes. The issue is being recategorized as a support topic rather than a bug, as it’s considered minor.
On Discourse 1.9.2 (stable) if there exists a theme “A” that gets saved as a user’s default theme and then you create a theme “B” and make theme “A” not selectable by users, people who have selected theme A still get theme A.
And if theme B is the only available theme, then there is no selector on /my/preferences/interface to be able to select theme B.
Even if you make theme B the default?
Can I assume that the theme choice is saved inside the session?
I’ve been messing with my themes all day and have noticed that sometimes if I disable a theme I still have it until I clear the browser cache.
Yes. Theme B is the default and no other themes are user-selectable. You have to change the theme in the user profile to get to it (or perhaps clear the browser cache?).
I cleared the browser cache and it reset to the default for me, I’m running v2 though..
Thanks. I suggested that to my not-so-technically-adept client who is more adept than most of their community.
Hopefully that fixes the problem, I guess the other way is to go through admin and change it manually for them (headache)
It’s possible to update them all from the Rails console.
Oh, nice, I’m still learning the basic commands, is there a cheat sheet for discourse commands?
Not quite what you’re looking for. In Completely disable mailing list mode? - #10 by techAPJ I found this
./launcher enter app
rails c
UserOption.update_all(mailing_list_mode: false)
You’d do something similar, like
UserOption.update_all(theme_key: 666)
Which I found by looking in discourse/app/models/user_option.rb.
So you force the same theme_key on every user, I assume that is the theme ID?
That’s what it looks like. That’s not tested. It might kill your dog or something.
Ok, I just ran a test and clearing the browser cache DOES change the theme to the default one in v2 if the one the user was previously using has been removed and a new one has been set as default.
If Make this my default theme on all devices is checked it should revert on the next refresh.
This is only the case if you are an administrator, as an end user this can not happen. I just confirmed cause we do a security check and only allow end users to see themes that are user selectable.
I am recategorizing this as support for now cause I feel it is too minor to need fixing.
Sorry to drag this one up. How can I find out what a ‘theme_key’ is per theme?
**Edit: Is it the number at end of URL if you go to settings/customise/themes and select the one you want?
Theme_key is no longer used. Instead, you would do
UserOption.update_all(theme_ids: [666])
Where 666 is the id of the theme (the number in the URL when you go to edit it in the admin panel)
So for my instance I typed this:
./launcher enter app
rails c
UserOption.update_all(theme_ids: [3])
Worked super fast (<1 sec) and changed all my user themes to my predetermined default. Perfect, thank you @pfaffman