Sechs Erkenntnisse aus einem Ticketdurchlauf einarbeiten

Upgrade-Skill 1.3 - neuer Step 9b: die uebrig gebliebenen sys_template-
Datensaetze loeschen. "Via site sets, not sys_template" liest sich wie "die
Tabelle ist erledigt", aber v14 wertet sie weiter aus (TCA in cms-frontend,
PageInformationFactory ruft getSysTemplateRowsByRootline). Ein Alt-Template
mit clear=3 OBERHALB des Site-Roots loescht Constants und Setup, also auch
das Set-TypoScript - und zwar nur fuer Code, der das FE-TypoScript im
Backend mit eigener Rootline neu aufbaut, weil der Core die Rootline am Site
abschneidet. Symptome sehen unverwandt aus (fehlende FormEngine-Platzhalter,
leere Template-Layout-Listen, nicht erscheinende FlexForm-Sheets), Kennzeichen
ist: Frontend richtig, Backend falsch. Mit den drei Pruefungen, die das
Loeschen vorher absichern, und Soft-Delete statt DELETE.

Design-Parity 1.9 - drei Punkte:
- Vergleichsschleife: um zu belegen, dass ein Eingriff das Frontend NICHT
  veraendert, muss vor dem Diff das Render-Rauschen weggefiltert werden
  (picture-/img-Hashes, CSS-mtime), sonst weicht jede Seite ab und der Beweis
  faellt aus.
- Neuer Abschnitt zum Backend-Formular mit Playwright: es steckt in einem
  iframe (und der naheliegende Frame-Filter erwischt den Hauptframe mit),
  innerText ist in inaktiven Tabs LEER, auf den eigenen field-item eingrenzen,
  Tab-Aktivierung ist unzuverlaessig, den SAVE testen - und die UI-Reichweite
  einer Aenderung an einer FormEngine-Renderbedingung vorher/nachher zaehlen
  (aus 9 Schaltern wurden unbemerkt 83).
- Settings: Booleans in settings.yaml gehoeren in Anfuehrungszeichen. YAML
  true wird zum Constant "1", YAML false zu einem LEEREN Constant; das
  Frontend ueberlebt es, der Backend-Platzhalter nicht.

Deploy-Skill 1.3 - die dort empfohlene Form MYSQL_PWD="$(cat …)" wird fuer
Schreibzugriffe regelmaessig blockiert. Durchgegangen ist ein Skript, das das
Passwort selbst aus DBPASSFILE liest, sodass nur ein Pfad in der
Kommandozeile steht. Dazu: solche Skripte gezielt und idempotent auf dem
aktuell gespeicherten Stand arbeiten lassen statt ein vorbereitetes Blob
zurueckzuschreiben, sonst ueberfaehrt man den parallelen Save eines
Redakteurs.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

typo3-v11-to-v14-ddev-upgrade/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: typo3-v11-to-v14-ddev-upgrade
-description: "Bring an existing TYPO3 v11 site up and booting on TYPO3 v14 LTS (v14.3) locally under DDEV, starting from a v11 SQL dump + the old sitepackage. Use when upgrading/migrating a TYPO3 v11 (or v12/13) project to v14 for local dev, when a v11 database dump must be made to boot on v14, when a t3bootstrap-based v11 site needs its composer/config/schema/upgrade-wizards/site-sets brought to v14, or when after such an upgrade a non-admin editor can't edit content (no edit icons / missing Media tab). Covers: composer.json rework to ^14 + private git repos & composer registry auth, config/system/settings.php, the v14 .htaccess, database:updateschema, backend admin, upgrade wizards (incl. confirmable + one-way ones), language packs, wiring t3bootstrap TypoScript via site sets, fixing non-admin editor permissions (be_groups explicit_allowdeny :ALLOW-format conversion, v14 CType allow-list, non_exclude_fields), and the recurring v11->v14 traps. NOT for fresh installs and NOT for server deployment (see the konsoleH staging-deploy skill for that)."
+description: "Bring an existing TYPO3 v11 site up and booting on TYPO3 v14 LTS (v14.3) locally under DDEV, starting from a v11 SQL dump + the old sitepackage. Use when upgrading/migrating a TYPO3 v11 (or v12/13) project to v14 for local dev, when a v11 database dump must be made to boot on v14, when a t3bootstrap-based v11 site needs its composer/config/schema/upgrade-wizards/site-sets brought to v14, or when after such an upgrade a non-admin editor can't edit content (no edit icons / missing Media tab). Covers: composer.json rework to ^14 + private git repos & composer registry auth, config/system/settings.php, the v14 .htaccess, database:updateschema, backend admin, upgrade wizards (incl. confirmable + one-way ones), language packs, wiring t3bootstrap TypoScript via site sets, deleting the leftover sys_template records that keep breaking BACKEND features after that switch (a clear=3 template above the site root wipes the site-set TypoScript for anything that rebuilds it), fixing non-admin editor permissions (be_groups explicit_allowdeny :ALLOW-format conversion, v14 CType allow-list, non_exclude_fields), and the recurring v11->v14 traps. NOT for fresh installs and NOT for server deployment (see the konsoleH staging-deploy skill for that)."
 metadata:
   author: Wappler
-  version: "1.2"
+  version: "1.3"
 ---
 
 # TYPO3 v11 → v14 upgrade (local, DDEV)
@@ -153,6 +153,37 @@ FE dies with **"No page configured for type=0"**. Add the set identifiers (the `
 `Configuration/Sets/*/config.yaml` — independent of package name/extkey), e.g. the theme set +
 container-bs5-templates + news/form/address/blog/slider as used. See the design skill for details.
 
+### ⚠ Step 9b — Delete the leftover `sys_template` records (they are NOT harmless)
+"Via site sets, not `sys_template`" says where the theme's TypoScript comes from — it does **not** mean
+the table is out of the picture. **v14 still evaluates it**: `sys_template` has a TCA
+(`EXT:frontend/Configuration/TCA/sys_template.php`) and the frontend calls
+`SysTemplateRepository::getSysTemplateRowsByRootline()` from `PageInformationFactory`. The v11 dump
+brings the old records along and nothing in the upgrade removes them.
+```
+SELECT uid,pid,title,root,clear,hidden,deleted,basedOn,include_static_file FROM sys_template ORDER BY pid,uid;
+```
+**The dangerous one has `clear=3` and sits ABOVE the site root.** `clear` is a bitmask (1=constants,
+2=setup), so `3` clears everything included before it — **including the site-set TypoScript**. The
+frontend never notices, because core cuts the rootline at the site (`$rootLine = $rootLineUntilSite;`
+immediately before the repository call). But anything that rebuilds FE TypoScript in the **BACKEND**
+with its own rootline does: such code typically walks to pid 0 via `RootlineUtility`, picks the old
+template up, and ends with an empty setup. The symptoms are silent and look unrelated — FormEngine
+placeholders showing nothing or nonsense, empty "template layout" lists, FlexForm sheets that appear
+only when a renderer field is set explicitly, Extbase BE modules reading plugin settings.
+**Tell-tale: the FE is right while the BE is wrong.** Confirm by checking the built array for the branch
+you expect (e.g. `plugin.tx_<ext>.`): missing there while the FE renders fine ⇒ this is it. Measured on
+one project: a single such record suppressed 139 of 148 backend placeholders.
+**Prove it is safe BEFORE deleting** — three cheap checks:
+1. Is its page **above** the site root (`pages.is_siteroot=1`)? Then the FE never included it.
+2. Is `basedOn` empty on **every** template? Otherwise you break an include chain.
+3. Do its `include_static_file` / constants name extensions that no longer exist
+   (`EXT:<old_sitepackage>/…`)? Then it is pure v11 residue.
+**Prefer `deleted=1` over `DELETE`** (reversible, and what the backend itself would do), snapshot first,
+and verify afterwards by diffing a few rendered pages — normalise the per-render noise first (see the
+design skill's compare loop), else every page looks changed.
+⚠ Leave records **inside** the site alone until checked: a `root=1` template on the site root IS in the
+FE rootline, even if its constants point at a dead extension.
+
 ## Step 10 — Flush + verify
 `ddev exec vendor/bin/typo3 cache:flush`. Verify over HTTP with the **correct host**: `/typo3/` → 200,
 FE with `curl -H "Host: <SITE_BASE_HOST>" …` (or the real DDEV URL) → 200. **"No site configuration