Repository navigation
fix: single album page cache entry, working 304s, hero template in dark theme - #137
Conversation
…and invalidation The album page was rendered from the album_<id> entry while a second, partially built album:<slug> entry was written by every warm. That second entry was never rendered, but CacheMiddleware took the page ETag from it, so the validator did not follow the page: a settings change that altered the album layout left the ETag unchanged. PageCacheService::albumPageKey() is now the single key format. The ETag is read from that entry (a ?template=N request falls back to hashing the body), invalidateAlbum() targets it, and the partial album warm is removed: home and galleries are still pre-built, album pages are cached on their first anonymous visit and rebuilt single-flight after an edit. cache:warm keeps accepting --albums and says so; the admin Cache page clears album entries instead of pretending to regenerate them. The file backend now lists and clears every page entry, not just home and galleries. ETag comparison also ignores the -gzip / -br suffix Apache appends when it compresses the response; with it, a compressed page could never revalidate to 304. e2e: ECA-03 in album-edit-cache.spec.js covers the 304 on an unchanged page and the 200 after a layout change.
The readability veil over the hero image was a fixed white gradient and the panel forced dark text, while the category, tag and date pills inside it switched to their dark styles: dark pills with dark text on a white panel, and album body text that turned light on white. The veil now uses the theme surface colour (--color-bg-secondary-rgb), so the panel is white in the light theme and near-black in the dark one and everything inside uses its normal light/dark styles. The .preserve-light-text override, only used here, is removed. Light theme rendering is unchanged.
The test only read the admin layout, so a plugin subtitle going back to a fixed string, or a language pack missing a plugin key, would have gone unnoticed (the trans() default hides a missing key).
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
WalkthroughLe cache album passano a chiavi basate sull’ID e non vengono più preriscaldate. Le richieste anonime generano le pagine album e gli ETag considerano i parametri query. Il pannello hero adatta i propri stili al tema. I test delle traduzioni includono anche i plugin. ChangesCache delle pagine
Tema del pannello hero
Traduzioni della sidebar
Priority: ➖ Normal Estimated code review effort: 4 (Complex) | ~45 minutes Change: Bug fix Sequence Diagram(s)sequenceDiagram
participant ClientAnonimo
participant CacheMiddleware
participant PageCacheService
participant PageController
ClientAnonimo->>CacheMiddleware: Richiede la pagina album con i parametri query
CacheMiddleware->>PageCacheService: Risolve la chiave album dallo slug
PageCacheService-->>CacheMiddleware: Restituisce la chiave o null
CacheMiddleware->>PageController: Prosegue la richiesta
PageController->>PageCacheService: Legge o salva la pagina con albumPageKey
PageCacheService-->>PageController: Restituisce o registra la pagina
CacheMiddleware-->>ClientAnonimo: Restituisce la risposta con l'ETag
Suggested reviewers: Merge Risk: ⚪ Minimal · up to
|
Follow-up to #132 and #136: two loose ends I noted while reviewing, plus what turned up while fixing them.
1. One cache entry per album page
The album page was rendered from the
album_<id>entry, while every warm wrote a second, partially builtalbum:<slug>entry. That second entry was never rendered, butCacheMiddlewaretook the page ETag from it, so the validator did not follow the page: a settings change that altered the album layout left the ETag unchanged.PageCacheService::albumPageKey()is now the single key format, used byPageController(render),CacheMiddleware(ETag) andinvalidateAlbum(). A?template=Nrequest falls back to hashing the body.buildGalleriesCache()already does when it cannot reproduce the live page faithfully.cache:warmkeeps accepting--albumsand says album pages need no pre-build; the admin Cache page clears album entries instead of reporting a regeneration that never fed the page.2. 304 never happened behind a compressing Apache
Apache appends
-gzip/-brto the ETag when it compresses the response, and the browser sends that back inIf-None-Match. The comparison did not strip the suffix, so a compressed page could never revalidate to 304.normalizeEtag()now ignores the content-coding suffix.3. Hero album template in the dark theme
The readability veil over the hero image was a fixed white gradient and the panel forced dark text, while the pills inside switched to their dark styles: dark pills with dark text on a white panel, and body text that turned light on white. The veil now uses the theme surface colour (
--color-bg-secondary-rgb), so the panel follows the theme and everything inside uses its normal styles. The.preserve-light-textoverride, only used here, is removed. Light theme rendering is unchanged.4. Test coverage
album-edit-cache.spec.jsECA-03: 304 on an unchanged album page, 200 with a new ETag after a layout change.HeroPanelThemeTest: the hero veil must use the theme surface colour.AdminSidebarTranslationsTestnow also covers the two bundled plugins (CodeRabbit's note on Translate admin sidebar subtitles in English and Italian #128).Verification
app/(two baseline entries for the removedPageCacheService::warm()dropped).--config auto, baseline v1.4.23): no new findings.Home template: classicscreenshot spec, which fails the same way on v1.4.23 when it runs right afteralbum-state-transitions: the analytics beacon hits its 60/min per-IP limit, the 429 keeps the page from reaching network idle. Not caused by this PR.Summary by CodeRabbit
--albums.