Improved font customization in the admin

[Antonio Cavedoni]

The admin is pretty flexible when it comes to formatting. One can extend the extrastyle block in the admin/base_site.html (which is actually defined in admin/base.html) and override / inject whatever one may need in the stylesheet. However, when it comes to customizing the fonts in the admin, there currently is a big limitation due to the way the admin fonts (Roboto) are being loaded. admin/css/base.css is referenced in a non-extendable section of admin/base.html, and the first thing it does is to @import fonts.css, which in turn loads a bunch of woff files for Roboto. If one were to customize the fonts in their admin, they would still find themselves loading these woffs, even if unused.

So I propose we remove the @import in admin/css/base.css and replace it with a <link rel="stylesheet"> inside an overridable block in base.html. Right now I called it adminfonts for lack of a better name.

With that in place, a project can extend base_site.html, empty out adminfonts and add whatever color / font customizations in the existing extrastyle block.

This change would also offer some greater flexibility for users to at least improve the situation for themselves when it comes to Django’s default international font challenges—see issue #29122, for instance.

[Antonio Cavedoni]

Patch for #29936 created on git master as of 75dfa92a05c7161edd0ba7bc9ceab9b54d3383db

[Tim Graham]

Couldn't you override the fonts.css static file?

[Antonio Cavedoni]

Replying to Tim Graham:

Couldn't you override the fonts.css static file?

Not really, because it’s hardcoded through an @import rule into the admin base.css. You could have your own copy of either fonts.css or the base.css file, but one would lose the convenience of being able to update Django with no modifications.

[Antonio Cavedoni]

I created a pull request with the proposed change: ​https://github.com/django/django/pull/10631

[Tim Graham]

In the ticket description you said, a use case is to "empty out adminfonts" -- is that different from overriding fonts.css with an empty file? I'm still trying to understand a use case that requires the additional template block.

[Antonio Cavedoni]

It achieves the same thing but—I argue—in a more elegant way. Unless I’m overlooking something obvious, overriding fonts.css with an empty file essentially means maintaining one’s fork of Django. Even if it’s just running a ln -s operation, it means having to do that after every Django update / install. My solution avoids that by making the very import of fonts.css an extendable (overridable) block so it can all be done at the project / application level. Does that make the patch clearer?

[Antonio Cavedoni]

(Whatever the outcome, thanks for your continued attention to this admittedly minor issue, Tim.)

[Tim Graham]

You can override a static file by creating one with the same path in an app that comes before the admin in INSTALLED_APPS.

[Carlton Gibson]

Or indeed using STATICFILES_DIRS. (With the default STATICFILES_FINDERS, any files there will be found before any app folders are searched, so before contrib.admin’s

I note there's no explicit staticfiles version of the "Overriding templates" How-to. (The theory is essentially the same...) Maybe this issue coming up is a hint that the Documentation could do with a patch there.

[Antonio Cavedoni]

Doesn’t that hold true only if you’re serving the static files via Django? In other words, if you serve the admin static files via some other server, Django isn’t even involved and no overriding can take place, correct?

[Tim Graham]

Do you gather your static files without collectstatic? That's where the overriding of static files takes place.

[Antonio Cavedoni]

I see, I wasn’t aware of the interaction between app loading / overriding and collectstatic. Awesome! Thanks, Tim & Carlton, and sorry for the noise.

[Carlton Gibson]

#33878 (for Django 4.2) added --font-family-primary and --font-family-monospace variables that can be overridden as per ​Theming support docs.