Nachtrag zur Rollenuebersicht: Ranju gehoert ebenfalls zur
Entwicklungsseite, ein ihr zugewiesenes Ticket ist also technisch und
nicht redaktionell.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Der Bearbeiter eines Tickets sagt, um welche ART von Arbeit es geht.
Die Rollen sind ueber alle TYPO3-Projekte hinweg dieselben, deshalb
gehoeren sie in die Skill und nicht in ein Projektgedaechtnis, das nur
fuer ein Projekt geladen wird.
Festgehalten: Ilja und Sven entwickeln, Corinna macht Design und den
Grossteil der redaktionellen Arbeit, Eva fuehrt das Projekt und aendert
redaktionell im Kleinen. Daraus folgen zwei Regeln, die sich in der
Praxis bewaehrt haben: ein redaktionelles Ticket nicht stillschweigend
selbst erledigen, aber CSS und Code auch dann uebernehmen, wenn das
Ticket jemand anderem zugewiesen ist - Tickets mischen beides oft, also
nach der Natur der einzelnen Punkte aufteilen und sagen, welche Haelfte
man liegen laesst.
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>
Neuer Abschnitt "When an editor's SAVE is the cause". Sobald Redakteure
an einer Seite arbeiten, taucht eine eigene Fehlerklasse auf: "es ist
kaputt und niemand hat etwas geaendert". Der Redakteur ist der Ausloeser,
nicht die Ursache — beim Speichern schreibt TYPO3 Teile des Datensatzes
neu, und was im Backend nicht ausdrueckbar war, wird wegnormalisiert.
Enthaelt die Diagnose-Reihenfolge (tstamp gegen Meldedatum, gespeicherten
Wert gegen Erwartung, erst dann Rendering) und die zwei bekannten
Mechanismen: CKEditor verwirft jede nicht im RTE-Preset deklarierte
Klasse, und ein FlexForm-select ohne leeren Eintrag speichert seinen
ERSTEN Eintrag — bei ja/nein also ueberall "ja". Dazu die Abhilfen,
inklusive Styling ueber Struktur statt Klassen, und die Query fuer die
Reichweite.
Zwei abgeleitete Regeln: nach jeder redaktionell sichtbaren Neuerung
fragen, was ein Speichern ohne Aenderung bewirkt; und auf "wo kann ich
das einstellen?" mit einem Ort antworten statt mit einer Person, also
einer deklarierten Site-Einstellung samt Pruefrezept.
Ausserdem: Bootstrap-Carousel-Autoplay laesst sich nicht ueber das
Intervall abschalten (Messwerte, Begruendung, data-bs-ride weglassen),
Hinweis auf die Wechselwirkung mit zufaelliger Slide-Reihenfolge, und
die Cache-Falle um ein komplett gecachtes Dokument erweitert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Notiz und Status setzen ist in Ordnung, assigned_to_id nicht anfassen —
das entscheidet der User selbst.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Zwei Ergaenzungen zu den Posting-Regeln: keine Icons, Emoji oder
dekorativen Symbole im Ticket-Text, und als Norm zwei bis drei Saetze
ohne Commit-Hashes, Dateinamen oder Messwerte. Der Kunde hat nicht
gefragt, wie etwas geloest wurde, sondern ob.
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>
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