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>
Add a dedicated section on where spacing is resolved (Spacing.yaml ->
per-site spacing.yaml -> tx_t3b_spacing) and why a spacing fix in the
custom SCSS partial silently disables the editor-facing field: the
utility class it emits is (0,1,0) and loses to any contextual rule.
Also covers the first/last-position leak into container columns, the
fact that the system has no notion of "has a background" (so seemingly
contradictory spacing complaints are two different cases), when SCSS is
still the right tool (per-column, not per-element), and how to verify
from the emitted markup instead of the rendering.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Small, generic skill for reading/updating a self-hosted Redmine over its
REST API from the CLI: API-key-in-header auth (never inline the secret),
issues/journals/attachments endpoints, editing a journal note in place,
the collection-ticket pattern, Textile (not Markdown) formatting +
localized statuses, and the team posting-style rules (minimal
customer-visible notes — strike through or "erledigt", never the bug's
cause; don't post unless asked). Distilled from the IVV Redmine notes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Replace the fragile "store raw bodytext only" workaround with the durable
fix: when a custom Fluid partial renders an RTE field (enableRichtext=true,
e.g. tx_heroitem.bodytext), the backend RTE->DB transform wraps it in
<p>…</p> on every editor save, and a bare {field} / f:format.nl2br render
escapes it -> literal <p> on the page. Render RTE fields with f:format.html.
Add the general rule (check TCA enableRichtext; sweep your own/overridden
partials for nl2br/bare RTE output) and note core templates already do this.
Bump to v1.2.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
After a v11->v14 upgrade, non-admin editors often can't edit content
(no edit icons) and/or the Media tab is missing, even though the group
has "edit content" and tables_modify includes tt_content. The upgrade
wizards do not convert the backend group access-lists. Document the fix
for all three facets on be_groups:
1. explicit_allowdeny: v<=11 ":ALLOW"-suffix format vs v12+ exact
inList match (no suffix) — REPLACE strips it; blocks ALL editing.
2. CType allow-list missing renamed v14 names (wst3bootstrap_* -> t3bs_*,
ws_slider, heroitem, news_*, address_*).
3. non_exclude_fields missing v14 fields -> hidden Media tab
(e.g. hero tx_heroitem_bg*).
Includes the read-only recordEditAccessInternals/check/doesUserHaveAccess
CLI diagnosis and the db_mountpoints red-herring note. Bump to v1.1;
extend description + when-to-use for the symptom.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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>
melnicenkoandClaude Opus 5