Thin Custom-PHP Adapter solcom_editorial für State-abhängige Form-Sichtbarkeit

Kontext

Das PRD Publishing Workflows Konfiguration (2026-05-13) hält fest: „Alle vier Implementierungsmodule sind reine Drupal-Konfiguration (YAML). Kein Custom-PHP, keine Modul-Entwicklung." Im Zuge der Umsetzung sind zwei UI-Anforderungen aufgetaucht, die diese Vorgabe brechen würden, wenn man sie wörtlich nimmt:

1. Moderation-State-Dropdown zeigt unzulässige Zielzustände. Der Scheduler-Felder publish_state und unpublish_state listet per default alle Workflow-States, auch solche, in die der aktuelle User aus dem aktuellen State nicht transitionieren darf. Das ist verwirrend und führt zu Validation-Errors beim Speichern.
2. Scheduler-Datumsfeld publish_on / unpublish_on nur für berechtigte Rollen. PRD §Modul 3: „Das Scheduler-Datumsfeld wird nur für Rollen mit Publish-Berechtigung angezeigt — content_editor sieht es nicht." Drupal kennt dafür keine native Permission-pro-Field-Lösung im Standard-Form-Display. Das field_permissions-Contrib-Modul wäre die Alternative, würde aber ein zusätzliches Modul mit größerem Footprint einführen.

Beide Punkte sind Spec-Anforderungen, nicht Goldplating. Eine pure Config-Lösung existiert nicht.

Entscheidung

Wir bauen ein Custom-Modul web/modules/custom/solcom_editorial/ mit genau einem Hook (hook_form_alter) und einer Helper-Funktion. Das Modul:

• Versteckt publish_on und unpublish_on für User ohne Permission schedule publishing of nodes.
• Versteckt publish_state und unpublish_state, wenn der aktuelle User von der aktuellen Moderation-State aus keine gültige Transition zu einem Published-State hat (geprüft via content_moderation.state_transition_validation).
• Nutzt ausschließlich öffentliche Drupal-APIs (ModerationInformationInterface, StateTransitionValidationInterface) — keine privaten Contrib-Funktionen.
• Hat core_version_requirement: ^10 || ^11 für Portabilität.

Die PRD-Vorgabe „kein Custom-PHP" wird damit zu „kein Custom-PHP außer einem dünnen Form-Adapter" abgeschwächt. Begründung: Die Spec selbst (PRD §Modul 3) verlangt Permission-gesteuertes Form-Verhalten, das in Drupal ohne Custom-PHP nicht zu erreichen ist.

Rejected alternatives

• Keine UI-Adaption, alle Felder immer sichtbar. Spec-konform für „kein Custom-PHP", aber widerspricht der gleichen Spec in §Modul 3 (Datumsfeld-Sichtbarkeit) — interner Spec-Konflikt, der Verlierer wäre die UX.
• Contrib-Modul field_permissions einsetzen. Würde Field-Permissions pro Rolle ermöglichen, deckt aber den State-abhängigen Dropdown-Filter nicht ab — also wäre Custom-PHP weiterhin nötig für den zweiten Use-Case. Außerdem zusätzliche Modul-Dependency mit eigener Config-Surface.
• Separates Form-Display je Rolle. Drupal unterstützt das nicht nativ; man müsste über View-Modes und Role-basierte Form-Mode-Auswahl gehen, was wiederum Custom-PHP erfordern würde. Mehr Komplexität, kein UI-Gewinn.

Consequences

• Die PRD-Vorgabe „rein YAML" ist nicht mehr wortwörtlich gültig — sie bleibt Leitlinie, der dünne Adapter ist die dokumentierte Ausnahme.
• Das Modul ist getestet (Kernel-Test für Transition-Validierung, Functional-Test für Permission-gesteuertes Hiding) — siehe web/modules/custom/solcom_editorial/tests/.
• Erweiterungen am Editorial-UI (z. B. Inline-Status-Anzeige im Node-Header) sind nicht automatisch durch dieses ADR gedeckt — jede weitere Custom-PHP-Logik braucht eine eigene Begründung.
• Bei einer Drupal-Major-Migration (z. B. auf 12) muss core_version_requirement angepasst und das Modul gegen die neue API geprüft werden.