Jeder DB-Dump enthaelt be_users, der DDEV-Admin reist beim ersten Import also
mit auf den Server. Sein Passwort ist typischerweise ein Wegwerfpasswort
(admin, password, Projektname), weil lokal niemand sonst herankommt. Auf
Staging sitzt es hinter Basic Auth, und beim Go-live wird genau diese Sperre
entfernt - dann steht ein trivial erratbarer Admin an einem oeffentlichen
/typo3/.
Deploy-Skill: nach dem Import be_users auflisten und dem Entwickler
ausdruecklich sagen, dass sein lokaler Admin NICHT mitkommen soll;
deaktivieren, loeschen oder neues starkes Passwort, aber nie so lassen.
be_sessions ebenfalls leeren, sonst bleibt ein kopiertes Session-Cookie
gueltig.
Cutover-Skill: als eigener Punkt in "Test accounts", weil das Entfernen der
Basic-Auth-Sperre in derselben Phase passiert. Mit dem Hinweis, das mit dem
Entwickler zu klaeren statt es zu entscheiden - es ist sein Account, und im
selben Dump koennen Agentur-Accounts stecken, die bleiben muessen. lastlogin
als Unterscheidungsmerkmal, und danach von aussen pruefen, dass der Login
wirklich fehlschlaegt.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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