Design-Paritaet 1.5 -> 1.6:
- Site-Set-page.tsconfig erreicht keine Datensaetze in Ordnern neben dem
Site-Root; solche Konfiguration gehoert in die globale page.tsconfig
der Extension. Symptom ist, dass eine TCEFORM-Aenderung genau fuer
einen Datensatztyp wirkungslos bleibt.
- Angebotene und gerenderte Crop-Variante koennen auseinanderlaufen,
dann beschneidet die Redaktion ins Leere.
- Feste Bildhoehe laesst das Seitenverhaeltnis ueber die Breakpoints
wandern, sodass kein Zuschnitt mehr ueberall passt; aspect-ratio statt
fester Hoehe.
- Umbrechende Labels brauchen eine reservierte Zeilenhoehe, sonst
springt der Rhythmus des Rasters; dabei die Untermarge des Absatzes
neutralisieren und die schmalste Geraetebreite pruefen, nicht nur 360.
- :has() laesst sich nicht in :has() verschachteln, die Regel wird
komplett verworfen - ohne jede Fehlermeldung.
- Neuer Abschnitt zu Meldungen, die Rasterartefakte statt Fehler sind:
gegen die Referenzseite pruefen, ueber mehrere Zoomstufen UND
Subpixel-Versaetze messen, das Ganze per Canvas in einem Durchgang -
und rechtzeitig sagen, dass Geometrie es nicht loest.
v11->v14 1.1 -> 1.2:
- Ein "verlorenes" Feld ist oft ein umgebautes Feld; zwei Spalten werden
gern zu einem Feld plus Schalter. Erst das neue Modell pruefen, bevor
man eine fremde Extension patcht - dann ist es eine Datenmigration.
Dazu die abgesicherte UPDATE-Bedingung und der Hinweis, dass Fluid
keinen !-Operator kennt.
- Vor "Regression" gegen die Referenzseite pruefen: zwei Tickets zum
selben fehlenden Element koennen Verlust und Neuwunsch sein.
Cutover 1.1 -> 1.2:
- Eingebettete Fremddienste sperren sich per frame-ancestors oft gegen
Staging. Solche Tests sind dort in keinem Browser moeglich; frueh
klaeren, den eigenen Anteil trotzdem pruefen.
Redmine 1.3 -> 1.4:
- Textile beendet den Durchstrich am ersten Bindestrich im Text, ein
Pfeil laesst also die Handlungsaufforderung ungestrichen stehen; HTML
hilft nicht, Redmine escapt es. Und das Ergebnis nachsehen, die API
bestaetigt nur die Speicherung.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Design-Paritaet 1.4 -> 1.5: neuer Warnpunkt in der Vergleichsschleife.
Bevor man eine Rueckmeldung "immer noch nicht behoben" fuer bare Muenze
nimmt, gehoeren die Response-Header geprueft. Ohne config.cache_period
liefert TYPO3 seinen Core-Default von einem Jahr als max-age aus, und
config.sendCacheHeaders = 1 (von t3bootstrap gesetzt) reicht ihn an
Browser und Proxys weiter. Eine erteilte Frist ist nicht widerrufbar,
ein serverseitiges cache:flush erreicht solche Clients also nie. Da
Erweiterungen ihre Konfiguration teils als Inline-JS in die Seite
schreiben, reproduziert eine alte Kopie laengst behobene Fehler exakt.
Cutover 1.0 -> 1.1: derselbe Punkt als Go-live-Pruefung in Phase 2.
Dort wiegt er schwerer, weil nach dem Livegang jeder Besucher mit einer
bereits erteilten Jahresfrist festhaengt.
Beides stammt aus einem realen Fall: Rueckmeldungen aus dem Kundennetz
meldeten Fehler weiter, die im Agenturnetz nachweislich behoben waren.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Das Go-live ist eine eigene Aufgabe, nicht der letzte Schritt des
Staging-Deployments: oeffentlich, schwer umkehrbar, anderes Risiko.
Phasen: Cutover-Modell waehlen; aufraeumen, was nicht mit auf live darf
(DB-Dumps, Einmal-Skripte, .bak-Configs, Fehlerlogs); umgebungsabhaengige
Konfiguration (trustedHostsPattern, displayErrors, site base, DB-Zugang,
Mail); Staging-Sperren entfernen (Basic-Auth, noindex, Testkonten);
Redirects/Scheduler/Sprachpakete/SSL; Verifikation und Rueckweg.
Die Beispiele stammen aus einem realen Staging-Account: ~26 MB Dumps und
Ticket-Sicherungen im Home, eine .bak-Config im Projektbaum, Basic-Auth
in public/.htaccess, displayErrors=1 und ein auf die Staging-Domain
gepinntes trustedHostsPattern.
Die konsoleH-Deploy-Skill (jetzt 1.1) verweist am Ende darauf und benennt
die beiden Artefakte, die sie selbst erzeugt und die nicht mitwandern
duerfen.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
melnicenkoandClaude Opus 5