From 05db592836260b0738a511bf4d9057f70feda355 Mon Sep 17 00:00:00 2001 From: Mischa Date: Sun, 5 Jul 2026 14:55:05 +0200 Subject: [PATCH] fix(cache): revalidate pages/media instead of 7-day browser cache MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit system.pages.expires was 604800 (Grav default), so browsers cached feed HTML and entry media for a week with no revalidation — deleted entries lingered as ghost cards (images 404), and edited/new photos didn't appear until a hard refresh. Set expires: 0 → Cache-Control: no-cache, must-revalidate. With etag already on, an unchanged page returns a cheap 304; changed content shows immediately. Also fixes reorder staleness (photo-N.jpg is reused across reorders at the same URL). The server-side page cache (cache.enabled) is untouched. Co-Authored-By: Claude Opus 4.8 --- config/system.yaml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/config/system.yaml b/config/system.yaml index 558b5bc..35b6dbf 100644 --- a/config/system.yaml +++ b/config/system.yaml @@ -76,7 +76,13 @@ pages: - rss - atom append_url_extension: null - expires: 604800 + # expires: 0 → Cache-Control: max-age=0, so the browser (and any CDN) revalidates + # each load instead of serving up to 7 days stale. With etag on, an unchanged + # page returns a cheap 304; an edited/deleted/new entry shows immediately. This + # matters because the owner edits the live site and entry media reuses filenames + # (photo-N.jpg) across reorders. Server-side page cache (cache.enabled) is + # unaffected and still does the heavy lifting. + expires: 0 cache_control: null last_modified: false etag: true