From fb1a8a24757cafb4678c98ded35f6881c553dd0b Mon Sep 17 00:00:00 2001 From: Konrad du Plessis Date: Wed, 22 Apr 2026 04:14:11 +0200 Subject: [PATCH] Fix CSS cache-bust: use deployment_timestamp not request.timestamp MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The static asset cache-buster in base.html was using {{ request.timestamp|default:'1.0' }} — but `request.timestamp` is not a Django request attribute, so the template always fell back to the literal '1.0'. Every deploy's CSS URL resolved to the same `custom.css?v=1.0`, so any CDN or browser cache in front of the app held onto the pre-redesign CSS forever — even hard refreshes in incognito couldn't bust it. Symptom: after deploying the redesigned app, the browser continued to receive a 1,734-byte pre-redesign custom.css while the VM's /static/css/custom.css was the full 39,078-byte Premium Orange Theme. .topbar-nav rules were missing, so the topbar rendered as stacked block links. Fix: use `deployment_timestamp` (already provided by core.context_processors.project_context as int(time.time()) at render time). Every restart gets a fresh URL, CDNs refetch from origin, stale caches break. Co-Authored-By: Claude Opus 4.7 (1M context) --- core/templates/base.html | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/core/templates/base.html b/core/templates/base.html index 1fb66f6..72c2631 100644 --- a/core/templates/base.html +++ b/core/templates/base.html @@ -25,7 +25,12 @@ - + {# `deployment_timestamp` is provided by core.context_processors.project_context — + it's injected into every template so the browser (and any CDN in front of + the app) sees a fresh URL whenever the process restarts. The old template + used `request.timestamp` which doesn't exist on Django request objects and + always fell back to a fixed '1.0' — meaning CDNs cached the CSS forever. #} + {% block extra_css %}{% endblock %}