27 Jun 2025
Django community aggregator: Community blog posts
Django News - Fellow Deadline, Native Pooling, and Debugging in Production - Jun 27th 2025
News
⭐ DSF calls for applicants for a Django Fellow [last call]
Applications for the new Django Fellow position are open until midnight AOE on July 1st.
Updates to Django
Today 'Updates to Django' is presented by Pradhvan from the Djangonaut Space!🚀
Last week we had 14 pull requests merged into Django by 8 different contributors - including 1 first-time contributor! Congratulations to lukas-komischke-ameos for having their first commit merged into Django - welcome on board! 🎉
This week's Django highlights 🌟
PostgreSQL safety check: Added a helpful system check to catch when you forget django.contrib.postgres
in INSTALLED_APPS
, saving developers from confusing database errors.
Cleaner column aliases: Use of %
in column aliases is now deprecated.
Better content negotiation: Media type selection now properly considers quality values when choosing the preferred type for more reliable API responses.
Special shoutout to Clifford Gama who brought closure to ticket #32770 after 4 years. 🦄💜
Django Newsletter
Wagtail CMS
htmx accessibility gaps: data and recommendations
Analysis of htmx accessibility in Django sites reveals mixed Lighthouse scores, with specific ARIA gaps, and recommends using UI components, testing tools, and implementing carefully.
Sponsored Link 1
Scout Monitoring: Logs, Traces, Error (coming soon). Made for devs who own products, not just tickets.
Articles
Disable runserver warning in Django 5.2
Use the DJANGO_RUNSERVER_HIDE_WARNING=true
environment variable in Django 5.2 (including via django-environ .env files) to suppress the default development server warning.
Production-ready cache-busting for Django and Tailwind CSS
Use a custom ManifestStaticFilesStorage
to skip hashing Tailwind's source.css so django-tailwind-cli builds produce cache-busted tailwind.css via a two-step tailwind build and collectstatic
for Django projects.
Native connection pooling in Django 5 with PostgreSQL
Django 5 adds native PostgreSQL connection pooling via OPTIONS pool=True
in DATABASES
, eliminating external tools like PgBouncer and delivering over fivefold performance gains.
Markdown Virtual Table: Implementing SELECT
Demonstrates using custom Django schema editor hooks to register a Rust-based SQLite virtual table for Markdown content and frontmatter as unmanaged models.
Django: Introducing inline-snapshot-django
Inline snapshot Django provides snapshot testing of SQL queries in Django tests, automating fingerprint capture and inline updates with a Rust-based SQL fingerprinting engine.
Switching pip to uv in a Dockerized Flask / Django App
Switch from pip to uv in Dockerized Django apps to replace requirements.txt with pyproject.toml
, leverage uv lock/sync commands for faster, deterministic builds.
How to Migrate your Python & Django Projects to uv
Migrate Django projects from requirements files to uv by defining dependencies in pyproject.toml, syncing environments locally, in Docker, and CI with pre-commit integration.
DjangoCon Videos
KEYNOTE The Most Bizarre Software Bugs in History - Mia Bajić
We've all heard that we should test our software, but what happens when we don't? Sometimes, it leads to strange and unexplainable events.
Is 'testing more' always the right solution? What do these bugs reveal about software and its failures? And how can we use these lessons to build more resilient systems? Let's take a look at the most bizarre software bugs in history.
KEYNOTE Django for Data Science: Deploying Machine Learning Models with Django - Will Vincent
A keynote talk on learning how to train your own ML model and publicly share it using Django. Comes with a demo website and GitHub repos with source code for the ML model and Django website.
How to Enjoy Debugging in Production - Karen Tracey
While launch day is often anticipated as a satisfying completion to a project, the reality is often different. Real users in the production environment may test our code in unanticipated ways, leading to surprising bugs that need to be addressed, often under time pressure and with fewer debugging resources than we're used to having in our development environment.
Podcasts
Abstractions: Perverse Cargo Cult
Django made the Abstractions podcast this week with their guidance on AI-assisted security reports commit.
Django News Jobs
Django Fellow at Django Software Foundation
Senior/Staff Software Engineer at Clerq 🆕
Full Stack Software Engineer at Switchboard
Senior Software Engineer at Simons Foundation
Django Newsletter
Projects
django-wiki/django-nyt
Notification system for Django with batteries included: Email digests, user settings, JSON API.
charettes/django-fk-constraint
Django app providing a foreign key constraint support multiple fields.
Sponsorship
🌟 Sponsor Django News
Looking to reach over 4,200 active Django developers? This summer, promote your product or service while supporting the Django community. Sponsorship spots are available now!
View Sponsorship Opportunities →
Django Newsletter
This RSS feed is published on https://django-news.com/. You can also subscribe via email.
27 Jun 2025 3:00pm GMT
Django: hide the development server warning
From Django 5.2 (April 2025), the runserver
management command outputs a warning:
$ ./manage.py runserver
...
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
WARNING: This is a development server. Do not use it in a production setting. Use a production WSGI or ASGI server instead.
For more information on production servers see: https://docs.djangoproject.com/en/5.2/howto/deployment/
The warning uses bold, yellow text for emphasis.
Here's the relevant release note:
A new warning is displayed when running
runserver
, indicating that it is unsuitable for production. This warning can be suppressed by setting theDJANGO_RUNSERVER_HIDE_WARNING
environment variable to"true"
.
I think the warning is somewhat useful for new users, who do sometimes skip the deployment checklist that states that runserver
is not designed for production use. That said, the warning is rather annoying for the majority of users who have correctly set up a production server. I also fear it will lead to warning fatigue, normalizing that runserver
outputs lots of warning text, making it easier to skip over other, more pressing messages that may be logged.
If you've set up your production environment to use a secure server, like gunicorn, then you probably want to hide this warning. As the release note states, you can do this by setting the environment variable DJANGO_RUNSERVER_HIDE_WARNING
to "true"
.
While you can manage environment variables in a bunch of different ways, I think the simplest method here is to set it at the top of your settings file:
import os
# Hide development server warning
# https://docs.djangoproject.com/en/stable/ref/django-admin/#envvar-DJANGO_RUNSERVER_HIDE_WARNING
os.environ["DJANGO_RUNSERVER_HIDE_WARNING"] = "true"
(I would rather this warning was configured with a setting, or it came through the system check framework, but that's a change for a future Django release, at most.)
With those lines in place, runserver
will be a little bit more peaceful:
$ ./manage.py runserver
...
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
27 Jun 2025 4:00am GMT
26 Jun 2025
Django community aggregator: Community blog posts
Production-ready cache-busting for Django and Tailwind CSS
I'm a big fan of the django-tailwind-cli package. It makes integrating Tailwind CSS into a Django project incredibly simple. By managing the Tailwind watcher process for you, it streamlines development, especially when paired with django-browser-reload for live updates. It's a fantastic developer experience.
However, when I first deployed a project using this setup, I ran into a classic problem: caching. You see, django-tailwind-cli
creates a single tailwind.css
file that you load in your base template. In production, browsers and CDNs will aggressively cache this file to improve performance. This is normally a good thing! But when you deploy an update, like adding a new Tailwind class to a template, your users might not see the changes. Their browser will continue to serve the old, cached tailwind.css file
, leading to broken or outdated styling.
Luckily, Django has a built-in cache-busting mechanism in the form of ManifestStaticFilesStorage
. But, there's one important caveat: you can't use this class directly. The Tailwind build process relies on a source file (typically css/source.css
) that contains this line:
@import "tailwindcss";
When collectstatic
runs, ManifestStaticFilesStorage
tries to be helpful and process this file, too. It attempts to find and hash source.css
, and it also attempts to hash the imported tailwindcss
, which won't work.
The solution is to create a custom storage class that tells Django to leave source.css
alone.
storage.py
from django.contrib.staticfiles.storage import ManifestStaticFilesStorage
class CustomManifestStaticFilesStorage(ManifestStaticFilesStorage):
def hashed_name(self, name, content=None, filename=None):
# Skip hashing for source.css - it's only used during Tailwind compilation
if name == 'css/source.css':
return name
return super().hashed_name(name, content, filename)
def post_process(self, paths, **options):
# Exclude source.css from post-processing
paths = {k: v for k, v in paths.items() if k != 'css/source.css'}
return super().post_process(paths, **options)
Then configure it in settings.py
:
settings.py
STATIC_ROOT = BASE_DIR / "static_root"
STATIC_URL = "/static/"
STORAGES = {
"default": {
"BACKEND": "django.core.files.storage.FileSystemStorage",
},
"staticfiles": {
"BACKEND": "django.contrib.staticfiles.storage.StaticFilesStorage"
if DEBUG else "storage.CustomManifestStaticFilesStorage",
},
}
The last thing to do is update your base template. Replace the {% tailwind_css %}
tag with:
base.html
<link rel="preload" href="{% static 'css/tailwind.css' %}" as="style">
<link href="{% static 'css/tailwind.css' %}" rel="stylesheet" />
With everything configured, your deployment process for static files will now be a two-step command:
./manage.py tailwind build
./manage.py collectstatic --noinput
First, tailwind build
creates the final tailwind.css
file. Then, collectstatic
picks it up, hashes it with a unique name like tailwind.4e3e58f1a4a4.css
, and places it in your STATIC_ROOT
directory, ready to be served.
That's it! Your Tailwind styles are now production-ready and properly cache-busted.
26 Jun 2025 5:32pm GMT