Posted under Site Bug Reports & Feature Requests
This probably isn't an original thought, but I really wish your site theme selections were tied to your account and not your browser cookies. Really annoying if you prefer your theme selections over the default yet also use incognito mode.
If there's any reason for why it functions the way it does, please let me know.
It's because themes can be accessed by people not logged into their account.
I think you can emulate them through custom css, which will be tied to your account.
In addition to enabling access to users not logged in, there's also some other challenges I've brought up previously when discussing user customization.
aacafah said:
The user settings pane stores all of its data on the server, & therefore all of it is uniform across all devices you sign in on; all other options (e.g. the searchbar's settings menu, the themes menu, your currently deactivated blacklist items, keyboard shortcuts, etc.) are stored in Local Storage (to be simple, inside your browser), & therefore it can be customized for each browser (/device) you use.
Server storage:
- Eats up server bandwidth to update
- Eats up server storage even if unused
- Requires a page refresh every time it's changed in order to reflect updates
- Increases the memory load on the server for every loaded user, which decreases performance
- Increases chances of mandatory server downtime every time it changes (b/c the database must be updated as well)
- Is persistent across all browsers used to access the site
Local Storage:
- Is persistent on the browser it's set on
- Virtually zero storage on users' machines
- No mandatory page update when changed
- Reloading the same page is also faster b/c the previously cached value is the same as the new one (as the changes only occur client-side)
Obviously, granular UI customization would be best served by being stored locally; it's specific to each browser, it adds no extra server load, & (unlike custom CSS) you can see the results as you tweak them without needing to reload the page (which obviously also decreases server load). However, the point of incognito/private windows is that they don't persist local data created during the browsing session (including Local Storage) across sessions, & many users are using incognito/private windows when accessing e6. As such, these users are limited in their options (although I'd recommend installing the PWA from an incognito/private window, as that stores its data separately from the main browser, & its initial data would be copied from the mostly empty local data from that session). Even a granular system can fail to appease everyone.
snpthecat said:
It's because themes can be accessed by people not logged into their account.I think you can emulate them through custom css, which will be tied to your account.
I'm aware of how the system works. My question was about if it would ever be considered to change theme settings to be stored serverside (I suppose is the right word), and if not, what's preventing it. I supposed I could have worded that.
On top of everything I said prior, we'd have to reimplement everything server-side (no, it's not as simple as copy-pasting it), decide whether the local settings or the server settings take priority, & we'd have to implement any future additions/modifications server-side & client-side. That's a lot of time, expense, & trouble to help a vast minority of users. If we did anything, we'd switch one for the other, & we're not doing that.
