---
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.5"
---

# TYPO3 v14 t3bootstrap — live-design parity

Make a **v14 t3bootstrap-based DDEV build** look like a **reference live site** (usually the old v11
site being replaced), **page by page**. There are two layers, in order:
1. **Structural** — the right content actually *renders* (migration artifacts often hide it).
2. **Visual parity** — typography/colors/spacing/components match the reference.

Compare with **Playwright** ([headed, in the user's visible window]); **read computed values, don't
eyeball**. Brand tokens (colors, fonts, page IDs, label text) are **site-specific** — fill the
placeholders below from the site you're matching; keep a per-project log of what you changed.

## How the v14 t3bootstrap theme works (resolve these first)
- **TypoScript via site sets**, not `sys_template`. The `PAGE` object comes from the theme set,
  declared under `dependencies:` in `config/sites/<SITE_ID>/config.yaml`. (Missing → "No page
  configured for type=0".) flux/vhs are gone in v14; content is `t3bs_*` container CTypes.
- **Sitepackage** `<TEMPLATE_PACKAGE>` (extension key `<TEMPLATE_EXTKEY>`), usually a fork of
  `t3bootstrap/template`, often installed from a `dev-<branch>` git checkout in `vendor/`.
  Content-element overrides live in `EXT:<TEMPLATE_EXTKEY>/Resources/Private/Extensions/
  fluid_styled_content/{Templates,Partials,Layouts}`; per-CType TypoScript auto-imports from
  `Configuration/TypoScript/Lib/ContentElement/*.typoscript`.
- **⚠ Workflow:** edits in a `dev-<branch>` vendor checkout must be **committed & pushed to the
  template repo** before any `composer update <TEMPLATE_PACKAGE>` (else lost). **Code** changes
  (templates/SCSS/TypoScript/tsconfig/JS in the sitepackage) deploy via `composer update`. **Content**
  changes (tt_content, settings.yaml, DB) are project-local and travel via a DB dump, NOT the repo.

## Per-page compare loop
1. Open live `https://<LIVE_HOST>/<path>` and DDEV `https://<DDEV_HOST>/<path>` in Playwright.
   **Cache-bust DDEV with `?cb=N`** (browser caches); `ddev exec vendor/bin/typo3 cache:flush` after
   config/SCSS/template changes (a **hard** flush — also `rm -rf var/cache/*` — for template/TS path
   or on-demand-CSS changes). After editing a **Fluid partial/template**, `cache:flush` alone can
   still serve the old render → also clear `var/cache/code/fluid_template/*` + `var/cache/data/pages/*`.
   - **⚠ `?cb=N` busts the PAGE HTML but NOT the compiled-CSS asset URL.** Playwright caches
     `main.css` across navigations, so `getComputedStyle` may read **stale** styles after a recompile
     (a rule "missing" from the CSSOM though it's on disk). Verify against server truth: in-page
     `fetch(cssUrl,{cache:'no-store'})` and grep the rule, or `grep` the compiled file on disk; don't
     trust the cached DOM. Same for server-rendered HTML — `fetch(url,{cache:'no-store'})` to confirm a
     template change actually took, rather than the cached page.
   - **⚠ The browser may also serve a whole cached DOCUMENT for a URL you believe is new.** Seen with a
     persistent-profile browser: the DOM still showed the pre-change markup while `curl` on the same
     path already returned the new one. Symptom: your fix "doesn't work" in the browser but is provably
     live on the server. Cross-check with an in-page `fetch(location.pathname + '?x=' + Math.random(),
     {cache:'no-store'})` and compare against the DOM before concluding anything about the fix.
   - **⚠⚠ CHECK THE RESPONSE HEADERS BEFORE BELIEVING ANY "still not fixed" REPORT.**
     `curl -sI <url> | grep -iE 'cache-control|expires'`. With `config.sendCacheHeaders = 1` (t3bootstrap
     sets it) and **no `config.cache_period`**, TYPO3 emits its core default lifetime — `CacheLifetime
     Calculator::defaultCacheTimeout = 365 * 86400`, i.e. **`max-age` of ONE YEAR** — to browsers and,
     since the response carries no `private`, to shared proxies. A `max-age` already handed out
     **cannot be revoked**: `cache:flush` clears the SERVER cache only, that client simply stops asking.
     Deploys and editorial changes then never reach returning visitors, and anything rendered INTO the
     document comes back stale with it — including inline JS config (e.g. `ws_slider` writes its whole
     configuration as `let options_slider_<uid> = {...}` in the page), so a long-fixed bug reproduces
     perfectly. Tell-tale: people on YOUR network see every fix, people on the CUSTOMER's network see
     none. Fix at the source — `config.cache_period = 3600` (caps the server cache AND the emitted
     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 `?<mtime>` to CSS/JS URLs).
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.

## Settings vs SCSS decision
- **Setting** (`config/sites/<SITE_ID>/settings.yaml`) for anything mapped in the theme's
  `Configuration/TypoScript/Plugin/Setup/tx_wsscss.typoscript`: `design.color.{primary,secondary,
  body-color,headings-color,header-bg,page-bg,footer-bg,footer-color,footer-headline-color,…}`,
  `design.font.{font-family-base,headings-font-family,font-size-base,h1..h6-font-size}`, plus
  `header.logo`, `footer.logo`, `meta.favicon`. These are injected as SCSS vars, so **editing
  `_variables.scss` for colors/fonts has NO effect** — settings win.
- **SCSS** (a custom partial `@import`ed **last** in `base-layout.scss`; sizes in **rem**) for
  everything with no setting: utility classes, component tweaks, link/hover colors, icon/logo sizing,
  equal-sizing.
- **Webfonts:** no setting → add the Google-Fonts URL to `page.includeCSS` in the theme's
  `HTML/Page/head.typoscript`; a font-downloader ext localizes it.
- **Vanilla-JS components:** register in `page.includeJSFooter` (theme `head.typoscript`), file under
  `Resources/Public/JavaScript/components/`.

---

## Spacing (margin/padding) — a THIRD place, and NEVER your SCSS partial
`t3b_core` ships an **editor-facing** spacing system. Writing a spacing fix into your custom SCSS
silently disables it for that element — this is the single easiest way to break the backend field
without any error appearing.

**Where spacing is resolved**, weakest → strongest:
1. `EXT:t3b_core/Configuration/Yaml/Spacing.yaml` — the steps (`none/xs/s/m/l/xl/xxl`, rem values)
   and global defaults (typically `padding_top`/`padding_bottom` = `l`).
2. `config/sites/<SITE_ID>/spacing.yaml` — per site, itself a cascade:
   `defaults:` → `first:` / `last:` (position in the column) → `ctypes.<CType>:` →
   `containers.<containerCType>:` (each of the latter two may carry its own `defaults/first/last`).
   Field keys: `padding_{top,right,bottom,left}`, `margin_{top,bottom}`. Values: a step key, or a
   per-breakpoint map. There is also a backend module that writes this file.
3. `tt_content.tx_t3b_spacing` — per element, TCA `type: json`, rendered as the "Spacing/Abstände"
   box-model palette: `{"padding_top":"none"}` or `{"padding_top":{"xs":"none","md":"l"}}`.

All of it ends up as `t3b-{p,m}{t,r,b,l}-<step>` utility classes on the frame element.

- **THE TRAP.** A rule such as
  `.page-content > .frame-type-header:first-child + .frame { padding-top: 0 }` has specificity
  (0,4,0) and beats the utility class `.t3b-pt-l` (0,1,0). The editor then picks a spacing step and
  **nothing happens** — no warning, the field simply appears broken. Confirm by simulating an editor:
  swap the class in the browser to the strongest step and read the computed value; if it stays put,
  a CSS rule is winning. → Express spacing in `spacing.yaml` (defaults) or `tx_t3b_spacing`
  (exceptions), never in the SCSS partial.
- **Positional rules leak into containers.** `first`/`last` is computed per
  `(pid, colPos, language, tx_container_parent)`, so a `ctypes.<X>.first` rule ALSO matches elements
  that are first inside a *container column*. Measure the blast radius before writing the rule:
  `SELECT parent.CType, COUNT(*) FROM tt_content c JOIN tt_content parent ON parent.uid=c.tx_container_parent
   WHERE c.CType='<X>' AND c.deleted=0 AND c.tx_container_parent>0 GROUP BY parent.CType;`
  Neutralise with `containers.<containerCType>.first:` re-asserting the extension defaults (harmless
  for other CTypes, since it only restates what they already inherit).
- **The system has no notion of "has a background".** The same frame padding is dead whitespace on a
  plain element but becomes the *inner padding of a band* once the element carries a `bg-*` class —
  so one positional default cannot serve both, and requirements like "less gap under the page title"
  and "more gap inside the grey box" only *look* contradictory. Keep the default, and set the
  exception per element (`{"padding_top":"none"}`) — it stays visible and editable in the backend.
  Find the elements needing it (first element after a page-title header, no band class):
  `… WHERE c1.CType='header' AND c1.colPos=0 AND c2.element_classes NOT LIKE '%bg-%' …` — do this
  before estimating effort, the count is usually far smaller than it looks.
- **When SCSS IS still correct:** the spacing system works per content ELEMENT, never per column. A
  two-column element where one column must stay flush (a background-media image) while the other
  needs an inset can only be solved in CSS — target the inner column (e.g. `.ce-bodytext`), not the
  frame, so you are not overriding anything the editor could have set.
- **Verify from the emitted markup, not the rendering:**
  `curl -s "<url>?cb=$RANDOM" | grep -o 't3b-pt-[a-z]*'`. `spacing.yaml` is read at render time and
  the result is page-cached → `cache:flush` after editing it, and mind the browser's cached
  `main.css` (see the cache section).

**General principle this is an instance of:** when a theme offers an editor-facing control for
something, configure *that* control; a CSS override of it is invisible to the editor, outranks their
input, and turns a self-service setting into a support ticket.

---

## When an editor's SAVE is the cause
Once a site is in the hands of editors, a whole class of "it broke and nobody changed anything" reports
appears. The editor is the **trigger, not the cause**: opening a record and pressing Save makes TYPO3
rewrite parts of it, and whatever was never expressible in the backend gets normalised away.

**Diagnose in this order** — it is much faster than reading CSS:
1. Compare the record's `tstamp` with the date the problem was first noticed. A match points at a save.
2. Diff the record's stored value against what you expect (a `pi_flexform` that grew from 6 to 165
   fields, a `bodytext` that lost its classes). The size alone is usually the giveaway.
3. Only then look at rendering.

**Known mechanisms:**
- **CKEditor drops every class not declared in the RTE preset.** Hand-written classes in `bodytext`
  survive only until someone opens that element and saves. No error, no warning. Check
  `editor.config.style.definitions` in the preset YAML for the class; if it's absent, that's your cause.
  **Fix:** declare the project's classes there (group them with a common name prefix so editors can tell
  them from the framework's), and — where the markup allows it — derive the styling from **structure**
  instead of classes (e.g. `:nth-child(odd|even)` for a strict number/label alternation), so the look
  cannot be lost at all. Audit the blast radius before assuming it's one element:
  `SELECT bodytext FROM tt_content WHERE deleted=0 AND bodytext LIKE '%class=%'` → extract the classes →
  compare against the preset's list. Classes with no CSS anywhere are dead migration residue; ignore those.
- **A FlexForm `select` with no empty item stores its FIRST item on save.** If the options are just
  "yes"/"no", every untouched field silently becomes **yes**. One save can therefore switch on dozens
  of features nobody chose — including ones that break rendering outright. Symptom: a slider/gallery
  that worked for months misbehaves right after an editorial edit, and its stored flexform is suddenly
  huge. **Fix at the source:** give those selects an empty first item (a `selectSingleWithTypoScriptPlaceholder`
  renderType is *designed* for that empty state — it then shows the TypoScript default as placeholder).
  Then clean the affected records; the schema fix alone does not repair stored data.
- **Your own CSS outranking an editor-facing field** — see the spacing section above.

**Two rules that follow:**
- **After adding anything editor-facing, ask what happens when they press Save without touching it.**
  That single question would have caught all three cases above.
- **Give the customer a place, not a person.** When the question is "where can I set this?", the good
  answer is a declared site setting with a label and a category, visible in the backend — not a value
  you maintain in a YAML they never see. Declare it in the sitepackage's
  `Configuration/Sets/<Set>/settings.definitions.yaml` (`type`, `default`, `label`, `description`,
  `category`), wire it into the template via `{$your.setting}`, and *verify it is registered*: a small
  CLI bootstrap printing `$site->getSettings()->get('your.setting')` plus the definition from the set
  registry proves both the value and the backend visibility.

---

## Layer 1 — Structural fixes (content that won't render). Do these FIRST.
These are v11→v14 migration artifacts, not design; they recur across many pages.

- **Stranded `colPos=1` (the #1 recurring bug).** v11 content sitting at `colPos 1` (or 2/3) is not
  rendered by the v14 backend layout → the page looks half-empty though the content is in the DB.
  Find it site-wide:
  `SELECT c.pid,p.title,COUNT(*) FROM tt_content c JOIN pages p ON p.uid=c.pid WHERE c.colPos=1 AND
  c.hidden=0 AND c.deleted=0 AND p.doktype=1 GROUP BY c.pid;` (also check colPos NOT IN the known
  container values 2110xx). **Fix:** `UPDATE tt_content SET colPos=0, sorting=sorting+<OFFSET> WHERE
  pid=<pid> AND colPos=1 AND deleted=0` — offset so moved rows sort AFTER the colPos-0 intro. Add a
  band class via `element_classes` where the live section has a background.
- **Missing templateLayout partial** — "Partial Layouts/List/<X> not found" (news) / "List/<X> not
  found" (address). A v11 custom `templateLayout` (e.g. `List`, `Jobs`, `Lightbox`) has no v14
  partial. **Fix:** port the partial into the sitepackage's news/address `partialRootPaths` dir AND
  register the layout in page TSconfig (`tx_news.templateLayouts { X = X }` /
  `tx_address.templateLayouts`). Empty-list "no results" message can be suppressed by overriding the
  list template for that layout.
- **Template partial PRECEDENCE / shadowing.** Fluid searches `partialRootPaths` **highest-index
  first**. Extensions register at different indices (e.g. `t3bootstrap_news` at `.13`, your
  sitepackage at `.12`) → the higher one **shadows** yours, so your override is dead code (symptom:
  your template edits don't show; a partial you didn't write renders). **Fix:** register the
  sitepackage's paths at a **higher index** (e.g. `.20`), and **base your override on the partial
  that actually renders** (diff it against the reference — don't rewrite from a different base).
- **On-demand component CSS loads AFTER main.css.** `scssComponents:require key="…"` (accordion,
  pagination, carousel, …) injects its stylesheet after your compiled `main.css`, so
  **equal-specificity overrides lose**. Use higher specificity or `!important`, or a direct target
  (e.g. recolour an accordion chevron via `::after { background-image: … }`, not the CSS var).
- **Unregistered custom CType → FE fatal** (empty-`templateName` `InvalidTemplateResourceException`).
  Re-register the CType for v14: TCA override (`addRecordType`/`addTCAcolumns`, guard with
  `defined('TYPO3')`), `tt_content.<ctype> =< lib.contentElement` + `templateName` in
  `Lib/ContentElement/*.typoscript`, and the FSC template/partial. If the old site used the native
  t3b_core rendering (e.g. its `Icon.html` icon-tile partial that parses `path;class;identifier`),
  reuse that instead of porting old code.
- **Content ≠ template.** If a page's content differs from the reference, first check whether it's an
  **editor-managed content divergence** (the dump predates live edits) rather than a template bug —
  don't "fix" the template to reproduce editor content.

## Layer 2 — Visual-parity checklist (run ALL for each page/section)
- **Layout / width:** full-bleed section background (viewport width) with content contained (~container
  width). `full_width=1` wrongly makes the *content* full-width too → keep `full_width=0` and bleed
  only the bg in SCSS: `.<band>{box-shadow:0 0 0 100vw <color>;clip-path:inset(0 -100vw)}`.
- **Typography (rem):** font family + base size/line-height; heading sizes; **card/teaser titles**
  (v14 often defaults bigger/bolder than the old design); teaser text size/weight. The theme's base
  rule is `h1..h6{font-weight:500}`; live is often **400** → override globally in your SCSS (equal
  specificity, appended later → wins). **Page-title spacing:** every frame carries `t3b-pt-l`/`t3b-pb-l`
  (~24px) padding, so a page title gets doubled gaps above/below vs live's ce-header-margin model.
  Scope to `.page-main .page-content > .frame-type-header:first-child`: `margin-top` for the gap ABOVE
  (breadcrumb→title); `padding-bottom:0` + `& + .frame{padding-top:0}` for the gap BELOW.
- **Colors** (settings first): primary/headings/nav/links, body text, section-band bg, footer bg +
  labels. Read the element's *explicit* rule (inheritance assumptions bite).
- **Links & buttons:** underline on/off (match live); base + **exact hover** colors (links→accent,
  buttons→accent bg — read the `:hover` rule). Match the button **base** style (live `.btn-primary`
  is often an *outline* look: white bg + brand border/text, not filled). **Buttons are frequently
  square — no border-radius** on some brands (global `.btn{border-radius:0}`). A "read more"/CTA may
  be a plain link + leading chevron (`::before "\203A"`) on live vs a styled button in v14.
- **Repeated items (cards/teasers/logos/icon tiles):** live usually forces **equal height AND width**
  across the row (`height:100%` in an equal-height row; images `object-fit:cover` + fixed height;
  logo boxes equal size). DDEV often renders ragged — measure siblings, don't assume.
- **background-media hero image** (textmedia with `asBackground`, usually empty text — e.g. section
  landing/"Auftraggeber" pages): the image is a CSS background on a grid column sitting on a grey band.
  Live renders it **flush + container-width**; DDEV insets it (frame `t3b-pt-l/pb-l` padding + a
  `.bg-lightgray` full-bleed). Scope `.frame-type-textmedia:has(.bg-column.col-type-media)`: zero the
  frame padding, drop the full-bleed and move the grey onto `> .container`, media col `padding-left:0`,
  inner `> div{height:100%; background-size:cover}` (+ a `min-height` so an empty-text row still shows).
- **Images / borders:** the `imageborder` field renders Bootstrap's padded grey `.img-thumbnail`;
  restyle to the brand look (`border-color:<c>;border-radius:0;padding:0;background:transparent`).
  Migrated `imageborder`/border flags may be **inverted or on the wrong elements** — verify against
  live and fix in the DB. Divider (`hr.ce-div`) style, footer top border, header separator, decorative
  brand SVG shapes (stripes/polygons) — port from the old partial.
- **Icons:** match the live pixel size (icon box + svg in rem); center (`text-align:center` +
  `margin-inline:auto`); hover → accent.
- **Structural extras (new-but-not-old):** remove v14 extras the old site lacks (empty
  `.card-footer`/`news-meta`, wrappers, unwanted pagination) — **remove from the DOM** (`<f:if>`), not
  `display:none`. Note Bootstrap utilities (`d-none`/`d-sm-block`) are `!important` → out-specify or
  remove the markup.
- **Footer:** columns via `footer.contentPageId`; meta nav via `navigation.footer.enabled` +
  `folderPageId`; disable credits (`footer.creditsEnabled:false` + gate the Copyright partial). The
  `.layout-full .page-footer` rule may out-specify a plain `.page-footer` — match its specificity.
  Footer link columns may be migrated as **RTE `frame-type-text`** (not menu elements) → target the
  text links, excluding `mailto:`/`tel:`, when adding chevrons.
- **Header / navigation:** meta menu = `navigation.meta.enabled` + `folderPageId`; nav alignment/logo
  = `header.logoPosition`. Top-level shortcut items may need to be **toggle-only** (`href="#"`) if the
  live nav doesn't navigate on them. `navigation.main.menuType` is GLOBAL — a per-item mega/dropdown
  mix + the mega's grid/width/padding needs SCSS work (smartmenus writes inline styles on open →
  `!important`). Uppercase mega headers: `text-transform:none` to get title-case. A **persistent green/
  highlighted background** on the current-page item + section header in the mega/dropdowns is
  `--bs-dropdown-link-active-bg` — set it `transparent` (scope to the mega) to remove the "it stays
  highlighted" effect while keeping `--bs-dropdown-link-hover-bg` for transient hover.
- **Hero / carousel (`hero-item`):** the ext injects its own `Hero.html` at a fixed `page.5`
  partialRootPaths index → re-assert your partial at a HIGHER index in `page.typoscript`, or your
  edits don't show. `.carousel-fade` = crossfade vs `.slide` = slide. The `.carousel-indicators` strip
  is a full-width high-z-index bar that steals hover from content beneath — reposition/shrink or
  `pointer-events:none`. Contain-vs-full-bleed per design.
  - **Switching autoplay OFF cannot be done via the interval.** Bootstrap 5's `_updateInterval()` reads
    the interval from the **active slide**, not the container; slides normally carry none → `NaN` →
    it falls back to `defaultInterval`, and `setInterval(fn, false)` means **0 ms**. Measured on 5.3.8:
    `data-bs-interval="false"` produced *3 slide changes in 2 seconds*. An empty interval is worse
    still — that's the "interval type null" JS crash. **Omit `data-bs-ride` instead**: `_maybeEnableCycle()`
    returns immediately, manual controls keep working (measured: 0 changes in 12 s). Keep the interval
    value stored so re-enabling works.
  - Beware the interaction with a **randomised slide order**: with autoplay off, a visitor who doesn't
    click sees exactly one random slide out of N. Raise it before implementing — it may or may not be
    what "manual only" was meant to achieve.
- **Translucent overlays — paint ONE shape:** a translucent box + a separate translucent shape beside
  it can never be seamless (hairline gap or doubled-alpha line). Merge into one element with one
  `clip-path` polygon + one `rgba()`.
- **i18n:** `vendor/bin/typo3 language:update` (composer mode ships no packs → English fallback).
- **Verify:** flush + screenshot with `?cb=N`; confirm by reading computed values.

---

## Cache-safe & content techniques
- **Randomise/shuffle on every reload → client-side JS.** The FE page is cached, so a server-side
  shuffle (`ORDER BY RAND`) freezes one order per cache lifetime. Do it in the browser. To avoid a
  flash, run an **inline `<script>` right after the markup** (before Bootstrap's DOMContentLoaded
  auto-init) rather than a footer component. **Check CSP first** (`curl -D-` for a
  `content-security-policy` header) — if enforced, inline scripts need a nonce; else prefer an external
  component. (Same technique for a shuffled team/address grid.)
- **Responsive per-device image cropping (hero bg):** the bg renders via
  `t3bc:backgroundImage useBootstrapCropVariants=true`, which reads a per-breakpoint cropVariant NAME
  from `settings.breakpoints` (`xs/sm→s576`, `md→s768`, `lg→s992`, `xl→s1200`, `xxl→s1400`). To let
  editors crop per device, add cropVariants with **those exact keys** (page TSconfig
  `TCEFORM.tt_content.<falField>.config.overrideChildTca.columns.crop.config.cropVariants` — page
  TSconfig avoids TCA load-order issues). Base recommended aspect ratios on the element's **measured**
  rendered proportions per breakpoint (measure with Playwright + `browser_resize`), keep a "Frei"
  (free) option.
- **Bulk-create content elements + FAL references** via a bootstrapped CLI PHP script (SystemEnviron-
  mentBuilder + Bootstrap::init + CommandLineUserAuthentication + DataHandler). **Gotcha:** creating a
  `type=file` FAL relation via DataHandler datamap creates the `sys_file_reference` but leaves
  `uid_foreign=0` (child not wired to parent) and the parent counter 0 → after `process_datamap()`,
  read `$dh->substNEWwithIDs[...]` and directly `UPDATE` the ref's `uid_foreign` + set the parent
  file-count column = 1, then `referenceindex:update`. Import images with `$storage->addFile(…,
  DuplicationBehavior::REPLACE)` (or `$storage->getFile('/path')` to index an already-copied file).
  - **Single-element clone WITHOUT DataHandler** (simplest for "add one slide/CE like an existing one"):
    clone the sibling `tt_content` row and its `sys_file_reference` via `ConnectionPool` (unset `uid`,
    repoint the ref's `uid_local`/`uid_foreign`) — the copied file-count column stays correct, so it
    sidesteps the `uid_foreign=0` gotcha entirely.
  - **RTE field rendered escaped by a custom template → literal `<p>` on the page.** Symptom: after an
    editor edits+saves an element (e.g. a hero slide — even just its title), its rich-text field shows
    literal `<p>…</p>` in the FE. Cause: the field is **RTE** (`enableRichtext=true` in TCA — e.g.
    `tx_heroitem.bodytext` in `t3bootstrap/hero-item`), so the backend's RTE→DB transform wraps the value
    in `<p>…</p>` on every save, but the custom Fluid partial renders it as ESCAPED plain text
    (`<p>{…bodytext -> f:format.nl2br()}</p>` or a bare `{…}`) → the tags are escaped and shown. FIX =
    render it as the RTE HTML it is: `{record.data.<field> -> f:format.html()}` (lib.parseFunc_RTE), and
    drop the manual `<p>`/`nl2br`. This renders editor-saved `<p>` correctly AND wraps raw
    (script-imported) text in a paragraph — so no per-slide data cleanup. (A bulk-import script that
    stores RAW text into an RTE field hides this until the first editor save — don't rely on that;
    fix the template.) **General rule:** whenever a custom template renders a field, check the field's TCA
    `enableRichtext` — if true, use `f:format.html`, never bare `{field}` or `f:format.nl2br` (both
    escape). Core/t3b_core templates already do this (e.g. image caption `text_visible`, news `teaser`),
    so the risk is only in your own/overridden partials — sweep them for `nl2br`/bare RTE-field output.
  - **Applying customer copy across DDEV+staging:** key the UPDATE on a stable identifier (e.g. the bg
    **image filename** via `tt_content→sys_file_reference→sys_file`), since row uids differ per env.

## Deploy the design changes
- **Code** (templates/SCSS/TS/tsconfig/JS): commit + push the sitepackage branch, then on the target
  run `composer update <TEMPLATE_PACKAGE>` (NOT plain `composer install` — that keeps the stale locked
  ref) + hard cache flush so SCSS recompiles. ⚠ ws_scss writes the compiled CSS in a **`<theme>/`
  subdir** (`public/typo3temp/assets/css/<theme>/main.css`), so `rm css/*.css` (non-recursive) MISSES
  it and ships a stale `main.css` — remove `css/<theme>/main.css` (or the whole `css/` tree). It
  recompiles on the first frontend hit (behind basic-auth, that's the user's browser reload).
- **Content** (tt_content/settings/DB): travels via a DB dump or replay the same DB edits; keep them
  env-agnostic (e.g. key UPDATEs on stable identifiers like file names, since uids differ per env).