#33690 closed New feature (fixed)
Allow disabling admin module dark theme
Reported by: | nv35 | Owned by: | Sarah Abderemane |
---|---|---|---|
Component: | contrib.admin | Version: | 4.0 |
Severity: | Normal | Keywords: | dark theme |
Cc: | Sarah Abderemane, Jeff Triplett, Florian Demmer | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | yes |
Description
Since #31259, dark theme had been added to admin interface and enabled by default to follow OS environment theme.
Some sites may want to have the possibility to keep the light theme for all users, ie. for compatibility with custom forms/views/charts... that don't render well under dark theme.
Having possibility to disable dark theme for the whole admin site would be a good start.
There are already some stackoverflow questions about that, and multiple django plugins to do that. They basically just force light theme in css, while a more evolved one stores user preference in database.
https://stackoverflow.com/questions/67193106/disable-prefers-color-scheme-dark-in-django-admin
https://stackoverflow.com/questions/68159768/disable-dark-mode-in-django-admin
https://pypi.org/project/django-non-dark-admin/
https://pypi.org/project/django-light/
Change History (17)
comment:1 by , 2 years ago
Cc: | added |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 2 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
I have done that on the related PR, it's taking the default os preference and there is a button to force the switch over system preference. I just need to do some improvements suggested in the PR.
I add the user preference in the local storage for djangoproject.com but for the admin it can be in the database or same as djangoproject.com, in local storage or other suggestion.
What do you think ?
As the admin has already a dark theme, I can handle it, before the change for djangoproject.com and adjust if needed.
comment:3 by , 2 years ago
Hi Sarah. I think local storage is fine (great even). Thanks!
It'll be a while before djangoproject.com is able to use it directly, but if we were able to put the JS for the toggle in a single script, folks could add it to their pages to use site-wide, and not every Django project would need to re-invent this same thing... 🤔
(We could copy to djangoproject.com, to remove once we get to e.g. Django 4.2).
comment:4 by , 2 years ago
Hi, thanks for your replies. I guess there are 2 different features that are missing :
- possibility to disable dark theme completely on a site
- give the user the possibility to switch between dark and light, and store the choice
I've created ticket initially for the first one, perhaps a second ticket have to be created for the other? Thanks
comment:5 by , 2 years ago
Cc: | added |
---|
comment:6 by , 2 years ago
Hi nv35,
I've created ticket initially for the first one, perhaps a second ticket have to be created for the other?
No need to create another ticket, in my opinion, it's only the fact that your ticket involved to be sure that it will fit everyone.
give the user the possibility to switch between dark and light, and store the choice
By doing this, you will have a way to disable the dark theme, even if you have set your os preference on the dark theme, and the theme change will be visible to everyone on the admin.
comment:8 by , 2 years ago
Has patch: | set |
---|
comment:9 by , 2 years ago
Patch needs improvement: | set |
---|
comment:10 by , 2 years ago
Patch needs improvement: | unset |
---|
It looks like comments have been addressed. Unchecking PNI for another review.
comment:11 by , 2 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
This keeps coming up so we should likely accept the change here.
There's a related PR for djangoproject.com https://github.com/django/djangoproject.com/pull/1158 — whatever switch we develop for there should be applied here too.
There was some discussion on Twitter where the consensus seemed to be to Follow the system setting, but allow an override — that should guide implementation.
(e.g. https://twitter.com/webology/status/1514760882605109276)