27 Jun 2025

feedDjango 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.

djangoproject.com

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.

wagtail.org

Sponsored Link 1

Scout Monitoring: Logs, Traces, Error (coming soon). Made for devs who own products, not just tickets.

scoutapm.com

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.

pecar.me

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.

loopwerk.io

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.

peterbe.com

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.

paultraylor.net

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.

adamj.eu

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.

nickjanetakis.com

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.

caktusgroup.com

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.

djangotv.com

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.

djangotv.com

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.

djangotv.com

Podcasts

Abstractions: Perverse Cargo Cult

Django made the Abstractions podcast this week with their guidance on AI-assisted security reports commit.

arrowloop.com

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.

github.com

charettes/django-fk-constraint

Django app providing a foreign key constraint support multiple fields.

github.com

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 the DJANGO_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.

Fin

May your server run smoothly and securely,

-Adam

27 Jun 2025 4:00am GMT

26 Jun 2025

feedDjango 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