Commit Graph
4 Commits
Author SHA1 Message Date
melnicenkoandClaude Opus 5 00b3a1a15a 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>
2026-08-10 13:14:02 +02:00
melnicenkoandClaude Opus 5 38b9ae49e5 Deploy- und Cutover-Skill: lokaler Admin-Account darf nicht mitwandern
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>
2026-08-10 12:20:29 +02:00
melnicenkoandClaude Opus 5 52df6752d9 Neue Skill: typo3-staging-to-live-cutover
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>
2026-08-06 13:45:32 +02:00
melnicenkoandClaude Opus 4.8 4e4af79e4f Initial commit: TYPO3 v11→v14 upgrade / design-parity / konsoleH-deploy skills
Three reusable, placeholder-based Claude Code skills distilled from the IVV
Aachen TYPO3 v11→v14 project:
- typo3-v11-to-v14-ddev-upgrade
- typo3-t3bootstrap-live-design-parity (v1.1)
- typo3-konsoleh-staging-deploy

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-20 12:01:06 +02:00