Alle Abhängigkeiten pinnen; STATICFILES_STORAGE auf STORAGES umstellen

requirements.txt stand durchgehend auf ">=", die gebaute Version hing also am
Kalendertag statt am Repo. Genau daran ist der letzte Deploy gescheitert.
Jetzt exakt die Versionen, gegen die die Suite grün ist und die produktiv
laufen — Updates werden damit zu einer bewussten Änderung mit CI-Lauf.

Django bleibt auf 6.1: dorthin ist die Instanz ohnehin schon gedriftet, es
läuft, und 4.2 LTS ist seit April 2026 aus dem Support.

Dabei ist aufgefallen, dass Django 5.1 STATICFILES_STORAGE entfernt hat. Die
Einstellung stand noch da und wurde stillschweigend ignoriert, womit
whitenoise auf StaticFilesStorage zurückfiel und Assets unkomprimiert
auslieferte — app.js mit 251 KB statt 62 KB bei jedem kalten Laden.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

diora/settings.py

@@ -97,7 +97,23 @@ STATIC_URL = '/static/'
 STATICFILES_DIRS = [BASE_DIR / 'static']
 STATIC_ROOT = BASE_DIR / 'staticfiles'
 
-STATICFILES_STORAGE = 'whitenoise.storage.CompressedManifestStaticFilesStorage'
+# Django 5.1 removed STATICFILES_STORAGE in favour of STORAGES. The old setting
+# sat here being silently ignored, so whitenoise fell back to plain
+# StaticFilesStorage and served everything uncompressed — app.js went out at
+# 251 KB instead of 62 KB on every cold load.
+#
+# The hashed filenames this also generates are inert: no template uses
+# {% static %}, they all hardcode /static/… paths. Cache busting comes from the
+# service worker's CACHE version instead (static/js/sw.js), which is why it is
+# bumped on each release.
+STORAGES = {
+    'default': {
+        'BACKEND': 'django.core.files.storage.FileSystemStorage',
+    },
+    'staticfiles': {
+        'BACKEND': 'whitenoise.storage.CompressedManifestStaticFilesStorage',
+    },
+}
 
 MEDIA_URL = '/media/'
 MEDIA_ROOT = BASE_DIR / 'media'

requirements.txt

@@ -1,13 +1,18 @@
-django>=4.2
-pylast>=5.2
-requests>=2.31
-python-dotenv>=1.0
-whitenoise>=6.6
-feedparser>=6.0
-gevent>=24.0
-# Pinned: 26.2.0 ships ggevent.py importing packaging.version while declaring
-# no dependencies at all, so the gevent worker dies at boot unless packaging is
-# installed explicitly. Both stay pinned here rather than being pulled in bare
-# by the Dockerfile, so a rebuild cannot silently change the worker again.
+# Pinned to exact versions. These are what production runs and what the test
+# suite is green against — with `>=` the image you get depends on the day you
+# build it, which is how a rebuild once swapped in a gunicorn that could not
+# boot the gevent worker at all.
+#
+# Nothing here updates on its own any more, so bump deliberately: change a
+# version, let CI run, then deploy.
+Django==6.1
+pylast==7.1.0
+requests==2.34.2
+python-dotenv==1.2.3
+whitenoise==6.12.0
+feedparser==6.0.14
+gevent==26.8.0
+# gunicorn 26.2.0 imports packaging.version in ggevent.py while declaring no
+# dependencies of its own, so packaging has to be requested explicitly.
 gunicorn==26.2.0
-packaging>=24.0
+packaging==26.3