Django 6-Veröffentlichung

• Das Web-Framework Django 6.0 wurde veröffentlicht, unterstützt Python 3.12 oder höher und stärkt Sicherheit, Templates und asynchrone Funktionalitäten deutlich.
• Die eingebaute Content Security Policy (CSP) ermöglicht Richtlinieneinstellungen, um Inhaltsinjektionen wie XSS besser abzuwehren.
• Mit der Funktion Template Partials können wiederverwendbare Teile innerhalb von Templates definiert werden, wodurch die Code-Modularisierung verbessert wird.
• Ein Background Tasks Framework wurde hinzugefügt und unterstützt die Ausführung asynchroner Aufgaben außerhalb des Anfrage-Antwort-Zyklus.
• Die Einführung der modernen Python-E-Mail-API, das Ende des Supports für MariaDB 10.5 und die Änderung des Standardwerts von DEFAULT_AUTO_FIELD sorgen für Kompatibilitätsanpassungen und Modernisierung.

---

Python-Kompatibilität

• Django 6.0 unterstützt Python 3.12, 3.13, 3.14; pro Serie wird nur der jeweils neueste Release offiziell unterstützt.
• Django 5.2.x ist die letzte Version, die Python 3.10 und 3.11 unterstützt.
• Nach Django 6.0 wird empfohlen, dass Drittanbieter-Apps den Support für Versionen vor Django 5.2 aufgeben.

Wichtige neue Funktionen

Unterstützung für Content Security Policy (CSP)

• Django enthält den CSP-Standard, wodurch der Schutz vor Inhaltsinjektionen wie XSS deutlich verbessert wird.
  • Über ContentSecurityPolicyMiddleware, den csp()-Kontextprozessor und die Einstellung SECURE_CSP lassen sich Richtlinien definieren.
  • Klar definierte und sichere Richtlinienkonfigurationen werden durch Python-Dictionary-basierte Einstellungen unterstützt.
• Mit SECURE_CSP_REPORT_ONLY kann ein Überwachungsmodus gesetzt werden.
• Es gibt einen Dekorator, mit dem Richtlinien pro View überschrieben oder deaktiviert werden können.

Template Partials

• Tags partialdef und partial wurden hinzugefügt, mit denen definierbare Template-Fragmente erstellt und wiederverwendet werden können.
• Mit der Syntax template_name#partial_name können get_template(), render() und {% include %} direkt auf Teile verweisen.
• Für Nutzer des Drittanbieterpakets django-template-partials steht eine Migrationsanleitung bereit.

Background Tasks Framework

• Django erhält ein eingebautes Framework für die Ausführung asynchroner Aufgaben.
  • HTTP-Anfragen und -Antworten werden dabei nicht Teil des Aufrufpfads; E-Mail-Versand oder Datenverarbeitung sind ebenfalls möglich.
  • Aufgaben werden mit dem @task-Dekorator definiert und per enqueue() in die Queue eingereiht.
• Das Backend wird über die Einstellung TASKS festgelegt; es sind zwei Standard-Backends für Entwicklung und Test enthalten.
• Django übernimmt nur die Erstellung und das Enqueueing von Aufgaben, die Ausführung erfolgt durch externe Worker-Prozesse.

Übernahme der modernen Python-E-Mail-API

• Die E-Mail-Verarbeitung in Django nutzt jetzt die moderne E-Mail-API von Python ab Version 3.6 (email.message.EmailMessage).
• Die bisherigen Klassen SafeMIMEText und SafeMIMEMultipart sind veraltet.
• Der Rückgabetyp von EmailMessage.message() wurde auf eine Instanz von Pythons EmailMessage geändert.

Detaillierte Verbesserungen

Admin

• Das Icon-Set Font Awesome Free 6.7.2 wird verwendet.
• Über die Eigenschaft AdminSite.password_change_form kann das Formular für Passwortänderungen im Adminbereich angepasst werden.
• Für messages.DEBUG und messages.INFO wurden eigene Icons und CSS-Stile eingeführt.

Auth

• Die Anzahl der Hash-Wiederholungen für PBKDF2 wurde von 1.000.000 auf 1.200.000 erhöht.

GIS

• Die Eigenschaft GEOSGeometry.hasm erlaubt die Prüfung, ob eine M-Dimension vorhanden ist.
• Die Funktion Rotate unterstützt Rotation um einen angegebenen Winkel.
• Über die Eigenschaft BaseGeometryWidget.base_layer ist eine Anpassung der Kartenkachel-Anbieter möglich.
• Ab MariaDB 12.0.1 werden coveredby, isvalid, GeoHash und IsValid unterstützt.
• Beim Widget-Rendering wurde Inline-JavaScript entfernt; für Anpassungen ist eine Template-Anpassung erforderlich.

PostgreSQL

• Mit Lexeme-Expressionen wird die Steuerung von Volltext-Suchanfragen verbessert.
• Der Parameter hints wurde bei Erweiterungsoperationen wie CreateExtension hinzugefügt.
• Für Felder, Indizes und Constraints in django.contrib.postgres wurden Systemprüfungen ergänzt.

Staticfiles

• ManifestStaticFilesStorage sorgt für konsistente Pfadsortierung und reduziert unnötige Diffs.
• Der Befehl collectstatic gibt standardmäßig nur eine Zusammenfassung aus; Detailinformationen werden erst ab --verbosity 2 angezeigt.

Sonstiges

• Unterstützung für die Sprache Haitian Creole hinzugefügt.
• Die Kommandos startproject und startapp erzeugen nicht vorhandene Verzeichnisse automatisch.
• Beim shell-Befehl werden Standard-Utilities wie django.conf.settings automatisch importiert.
• Migrationen unterstützen die Serialisierung von zoneinfo.ZoneInfo.
• Neue Aggregate-Funktionen wie StringAgg und AnyValue wurden hinzugefügt.
• Mit AsyncPaginator und AsyncPage steht asynchrone Pagination zur Verfügung.
• In ASGI-Umgebungen wird die Unterstützung für mehrere Cookie-Header in HTTP/2 ergänzt.
• In Templates wurde die Variable forloop.length ergänzt und der querystring-Tag verbessert.
• DiscoverRunner unterstützt parallelisierte Tests im forkserver-Modus.

Inkompatible Änderungen

Datenbank-Backend-API

• BaseDatabaseSchemaEditor und das PostgreSQL-Backend nutzen bei der Spaltelöschung nicht mehr CASCADE.
• Umbenennung von Methoden wie return_insert_columns() zu returning_columns().
• Bei Unterstützung von UPDATE … RETURNING kann DatabaseFeatures.can_return_rows_from_update=True gesetzt werden.

Eingestellte Unterstützung

• Ende der Unterstützung für MariaDB 10.5 (erforderlich ist 10.6+).
• Ende der Unterstützung für Python < 3.12.
  • Mindestversionen wichtiger Bibliotheken: aiosmtpd 1.4.5, bcrypt 4.1.1, Pillow 10.1.0, psycopg 3.1.12 usw.

E-Mail

• Entfernen der Eigenschaften mixed_subtype, alternative_subtype und encoding.
• Aufgrund interner Änderungen ist eine Überprüfung von benutzerdefinierten EmailMessage-Unterklassen erforderlich.

Änderung des Standardwerts von DEFAULT_AUTO_FIELD

• Der Standardwert wurde von AutoField auf BigAutoField geändert.
• Projekte, die die Warnung seit Django 3.2 (models.W042) nicht behoben haben, müssen die Konfiguration ergänzen.

ORM-Ausdrücke

• Die Rückgabeparameter von as_sql() müssen im Tuple-Format vorliegen.

Sonstiges

• Bei JSON-Serialisierung wird stets ein Zeilenumbruch hinzugefügt.
• Mindestversion von asgiref auf 3.9.1 angehoben.

In Kürze zu entfernende Funktionen

django.core.mail API

• Bei get_connection(), send_mail() usw. sollten optionale Argumente nur noch als Schlüsselwortargumente übergeben werden.
• Bei der Erstellung von EmailMessage und EmailMultiAlternatives sind nur die ersten vier Argumente positional erlaubt; alle anderen nur als Schlüsselwortargumente.

Sonstiges

• BaseDatabaseCreation.create_test_db(serialize) veraltet, verwenden Sie serialize_db_to_string().
• StringAgg und OrderableAggMixin nur für PostgreSQL entfallen.
• Das Standardprotokoll von urlize und urlizetrunc wechselt in Django 7.0 auf HTTPS.
• ADMINS und MANAGERS müssen als Liste von E-Mail-Strings angegeben werden, statt als Tupel aus (Name, Adresse).
• Entfall von E-Mail-bezogenen Klassen wie SafeMIMEText, SafeMIMEMultipart und BadHeaderError.

Entfernte Funktionen

• Positionsargument-Unterstützung von BaseConstraint entfernt.
• Entfernung von DjangoDivFormRenderer und Jinja2DivFormRenderer.
• Entfall der Unterstützung für den Datenbanktreiber cx_Oracle.
• Standard-Schema von forms.URLField: von "http" auf "https" geändert.
• Positionsargumente von Model.save() und Model.asave() entfernt.
• ModelAdmin.log_deletion() und LogEntryManager.log_action() entfernt.
• Modul django.utils.itercompat entfernt.
• Methoden GeoIP2.coords() und GeoIP2.open() entfernt.
• Entfernen von ForeignObject.get_joining_columns() und zugehörigen Methoden.

---

Django 6.0 erhöht durch Sicherheitsverbesserungen, asynchrone Verarbeitung und die Einführung einer modernen E-Mail-API sowohl die Stabilität als auch die Skalierbarkeit des Frameworks und definiert den klaren Übergang auf Python 3.12+.

[GN⁺]

Hacker-News-Kommentare

• In einer Organisation, in der ich früher gearbeitet habe, gab es eine „moderne“ Codebasis mit NodeJS+React und eine fast 15 Jahre alte Django-Legacy-App auf Basis von Python 2.7
  Anfangs hatte ich Sorge, dass der alte Code schmerzhaft sein würde, aber es war eher das Gegenteil
  Die Django-App hat richtig Spaß gemacht, und auch das Aufräumen war wirklich unterhaltsam. Wenn sie irgendwann durch ein neues Go/React-Rewrite ersetzt wird, werde ich das wohl bedauern

  • Ich verstehe nicht, warum man sie überhaupt ersetzen will. Wenn es nicht kaputt ist, muss man es auch nicht ändern

• Glückwunsch an das Django-Team
  Ich pflege seit Langem eine Starter-App auf Basis von Docker Compose mit Django + Celery + Postgres + Redis + esbuild + Tailwind und habe sie kürzlich auf Django 6.0 aktualisiert
  Sie ist im GitHub-Repository zu finden
  CSP-Konfiguration habe ich bisher noch nicht standardmäßig eingebaut, will das aber nach etwas mehr Prüfung ergänzen

  • Ich wollte es als Lesezeichen speichern und habe dann festgestellt, dass ich es schon im Dezember 2023 gespeichert hatte
  • Nicks Repositories sind immer Spitzenklasse. Ich zitiere sie auch in meinen eigenen Unterlagen häufig. Danke, dass du sie öffentlich teilst
  • Ich habe dieses Template vor ein paar Jahren in einem Projekt verwendet, und es war wirklich hervorragend
  • Als ich neulich die uv-Ergänzung gesehen habe, hatte ich direkt den Eindruck, dass es weiterhin konsequent gepflegt wird

• Djangos „batteries included“-Philosophie passt perfekt zu AI-Code-Generierung
  Admin-Panel, Login, Passwort-Reset und andere Grundfunktionen sind bereits sauber vorhanden, sodass AI auch mit einer kleinen Codebasis vollständige Websites erstellen kann
  Der Code ist klein und klar, daher kann AI ihn auch leicht iterativ verbessern

  • Die Stärke von Django ist eine für Menschen gut lesbare Codestruktur
    Statt riesiger Komponenten gibt es klare Modelle und Templates, was auch Reviews von AI-generiertem Code erleichtert
    Außerdem existiert Django Admin als unabhängige Ground Truth, sodass man auch dann mit den Daten arbeiten kann, wenn das Frontend kaputtgeht
    Schade ist nur, dass das Python-Ökosystem das gevent-Modell nicht übernommen hat. Dann wäre der Wechsel zu Async viel reibungsloser gewesen
  • Dank Djangos INSTALLED_APPS-Struktur lassen sich Funktionen sehr leicht appweise hinzufügen oder entfernen
    Das ist deutlich integrierter als lose gekoppelte Frameworks wie Flask oder FastAPI
    Dieser Unterschied reduziert am Ende viele kleine Reibungen (papercuts)
  • Ich habe sowohl Django als auch Rails verwendet, und beim Testen mit Claude Code hat Rails deutlich besser funktioniert
    Ich habe eine alte .NET-App neu geschrieben; Rails hat sie fast perfekt konvertiert, während Django damit Schwierigkeiten hatte
  • Tatsächlich bietet Ruby on Rails schon seit Langem standardmäßig verschiedene Funktionen wie CSP und Background Worker an
  • Django wird in Open-Source-Projekten schon so lange verwendet, dass es reichlich Code-Daten gibt, auf denen AI trainieren kann

• Das Feature template partials in diesem Release sieht ziemlich gut aus
  Der Stand der Typannotationen (type annotations) ist aber weiterhin unangenehm
  django-stubs braucht ein mypy-Plugin, django-types ist ein Fork für pyright, bleibt aber nicht gut synchronisiert
  pylance verwendet außerdem noch einen eigenen Fork
  Ich hoffe, dass in der nächsten Version wenigstens grundlegende Typen wie HttpRequest, HttpResponse, View und Model offiziell enthalten sind

• Dank Django hat Webentwicklung wirklich Spaß gemacht
  Selbst wenn ich zu anderen Frameworks wechsle, lande ich am Ende immer wieder bei Django. Eine Entscheidung, die ich nie bereut habe

  • Mit Ruby on Rails hatte ich dieselbe Erfahrung
    Auch wenn ich andere Frameworks ausprobiere, komme ich wegen der Bequemlichkeit von Rails immer wieder zurück
    Nur dass Rails keine standardmäßige Admin-UI hat, ist etwas schade
  • Wenn man nur auf das Backend schaut, ist Django großartig, aber aus Frontend-Sicht ist es noch auf Steinzeitniveau
    Wer einen vollständigen Full-Stack will, sollte sich eher Laravel oder Rails anschauen
  • Ehrlich gesagt verstehe ich den Reiz von Django nicht so ganz
    Ich mache seit der PHP-Zeit Webentwicklung, und Django fühlte sich für mich immer nur ganz okay an

• Django war mein erstes großes Freelance-Projekt, und es fühlt sich für mich immer noch vertraut an
  Ich habe viele experimentelle Dinge ausprobiert, und es hat immer gut funktioniert. Danke an Django

• Ich nutze Django seit fast 15 Jahren nahezu exklusiv
  Ich habe viele andere Frameworks ausprobiert, aber keines hat sich so richtig angefühlt wie Django
  In diesem Release wurde zwar ein Task-Framework hinzugefügt, aber schade, dass weder Backend noch Worker enthalten sind
  Lieber wäre mir, wenn es in der nächsten Version in vollständiger Form enthalten wäre

  • Ich frage mich, ob Django überhaupt vorhat, diese Grenze zu überschreiten. Nach der Framework-Philosophie scheint die Wahrung von Abgrenzungen wichtig zu sein
  • Perfektion darf nicht der Feind des Guten sein. Django ist am Ende ein Framework für „Perfektionisten mit Deadline“

• Djangos batteries-included-Ansatz macht es unabhängig von der Größe für praktisch jedes Projekt geeignet
  Großes Lob an das Team und die Mitwirkenden

• Ich frage mich, wie wir eigentlich in das SPA-Zeitalter geraten sind. Wollte man einfach nur Lade-Spinner loswerden, oder gab es tiefere Gründe?

  • Einer der Hauptgründe war das Aufkommen mobiler Apps
    Als Web, iOS und Android ein gemeinsames Backend nutzen sollten, verbreitete sich das SPA-Muster ganz natürlich
    Ich baue zwar immer noch SPAs, würde aber irgendwann gern ein großes Projekt mit Django + htmx machen
  • Früher bin ich bei Datenvisualisierung mit Angular auf SPAs umgestiegen
    Dass es sich ohne Seiten-Reload wie eine App anfühlte, war reizvoll, aber in der Praxis brauchte man doch oft einen erzwungenen Reload
    Trotzdem halte ich die Trennung von Daten und Darstellung für elegant
  • Das Web wurde ursprünglich zum Rendern von Dokumenten geschaffen, aber die Nutzer wollten Apps
    Deshalb gab es immer wieder Versuche, Dokumente mit JS in Apps zu verwandeln
  • In Zeiten langsamer Internetverbindungen und träger Backend-Validierung wurde zunächst für die Formularvalidierung JS ergänzt, wodurch alles komplexer wurde
    Schließlich trennte man Frontend und Backend, und es entstanden API-Verträge und Validierungsprozesse
    Später kam wieder der Trend auf, das Ganze mit Server Components zusammenzuführen, und genau an diesem Punkt stehen wir heute
    Ein Beispiel für Webformulare alter Schule gibt es unter diesem Link
  • Templates wie in Django oder Rails hatten zu wenig Typsicherheit
    Deshalb bevorzuge ich heute einen TypeScript-basierten Build-Prozess

• Jedes Mal, wenn ich Django nutze, empfinde ich einfach Freude. Das ist alles