From 1fd5f77c069e7865fceb7d2fabc85a7064707f2d Mon Sep 17 00:00:00 2001 From: Ilja Melnicenko Date: Mon, 10 Aug 2026 11:24:07 +0200 Subject: [PATCH] Design-Parity-Skill: gecachtes Dokument vor jeder Playwright-Analyse ausschliessen Der Stale-Document-Fall war bisher nur in einer Richtung notiert ("der Fix wirkt nicht, obwohl er auf dem Server liegt"). Die umgekehrte Richtung ist gefaehrlicher: ein gemeldeter Fehler ist NICHT reproduzierbar, weil die gecachte Kopie eine aeltere, funktionierende Konfiguration mitbringt. Konkreter Fall: gemeldet war "der Slider blaettert nicht endlos". Das gecachte HTML enthielt loop:1 und lief unter Pfeilklicks, echten Drags und Frame-fuer-Frame-Messung des Wrapper-Translate einwandfrei durch - alles scheinbare Belege dafuer, dass es keinen Fehler gibt. Ein Cache-Bypass-Fetch derselben URL lieferte loop:false. Mit dem Dokument veralten auch Slide-Zahl und Reihenfolge der Inhaltselemente, was fast als zweiter Defekt gemeldet worden waere. Daher als erste Aktion jeder Untersuchung: fetch(location.href, {cache:'reload'}) und die berichteten Einstellungen daraus mit dem DOM vergleichen, erst danach Verhalten testen. Hinter Basic Auth ist curl kein Ersatz - es bekommt 401, die Credentials liegen im Browserprofil. Co-Authored-By: Claude Opus 5 (1M context) --- typo3-t3bootstrap-live-design-parity/SKILL.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/typo3-t3bootstrap-live-design-parity/SKILL.md b/typo3-t3bootstrap-live-design-parity/SKILL.md index c0cb671..133740d 100644 --- a/typo3-t3bootstrap-live-design-parity/SKILL.md +++ b/typo3-t3bootstrap-live-design-parity/SKILL.md @@ -3,7 +3,7 @@ name: typo3-t3bootstrap-live-design-parity description: "Match a TYPO3 v14 t3bootstrap-based build (local DDEV) to a reference LIVE site page by page — the frontend/design phase after a v11->v14 upgrade. Use when making an upgraded TYPO3 site look like its old/live counterpart, when doing per-page visual parity against a reference URL, when content that exists in the DB isn't rendering after a v11->v14 migration, or when customizing a t3bootstrap sitepackage's templates/SCSS/settings. Covers: the Playwright compare loop (computed style + CSS rule), the settings-vs-SCSS decision, the t3b_core spacing system (spacing.yaml / tx_t3b_spacing) and why spacing must never be fixed in SCSS, recurring structural fixes (stranded colPos, missing templateLayout partials, template partialRootPaths precedence/shadowing, on-demand component CSS, unregistered CTypes), a full visual-parity checklist (layout/width, typography, colors, links/buttons, equal-sizing, icons, borders, footer, header/nav, hero carousel incl. why Bootstrap autoplay cannot be switched off via the interval), diagnosing regressions caused by an editor's SAVE (CKEditor dropping undeclared classes, FlexForm selects with no empty item flipping to "yes"), and cache-safe techniques (full-bleed bands, image-border restyle, responsive crop variants, client-side randomisation, FAL-via-DataHandler). Assumes the site already boots on v14 (see the v11->v14 upgrade skill)." metadata: author: Wappler - version: "1.6" + version: "1.7" --- # TYPO3 v14 t3bootstrap — live-design parity @@ -62,6 +62,21 @@ placeholders below from the site you're matching; keep a per-project log of what max-age), or `sendCacheHeaders = 0` to stop instructing the client at all. Note the lifetimes already issued cannot be recalled: those users need one hard reload. Assets are fine either way (TYPO3 appends `?` to CSS/JS URLs). + - **⚠⚠ START EVERY Playwright INVESTIGATION BY PROVING THE DOCUMENT IS FRESH.** The stale copy + misleads in BOTH directions, and the false-negative is the dangerous one: a reported bug is + **not reproducible** because the cached document carries an OLDER, working configuration. Real + case: "the slider doesn't page endlessly" — the browser's cached HTML had `loop:1` (looped fine + under arrow clicks, real drags, frame-by-frame translate sampling — all "proof" that there was no + bug), while a cache-bypassing fetch of the same URL returned `loop:false`. Everything rendered + INTO the document lies with it: inline JS config, slide COUNT, and content ELEMENT ORDER (the + stale copy showed the slider above the heading, the current page below it — nearly filed as a + second defect). + First action, before touching the DOM: `browser_evaluate` → + `fetch(location.href, {cache:'reload'})`, then grep the answer for the settings the report is + about (`loop:`, `autoplay:`, slide/frame counts) and compare with the DOM. Cheap, one call, and + it decides whether anything you measure afterwards means something. `curl` is NOT a substitute + behind HTTP basic auth (staging) — it returns 401 while the browser holds the credentials. + Test behaviour only after that fetch and the DOM agree. 2. With `browser_evaluate`, capture the real element's **computed style AND its explicit CSS rule** (getComputedStyle + walk `document.styleSheets` for the selector). Don't assume inheritance. 3. Diff vs DDEV → decide **setting vs SCSS** (below) → apply → flush → re-screenshot → verify.