0011 — Joomla-Erweiterung als Companion-Repository, eine Fassung für 5.4 und 6.x

Status: angenommen · Milestone: M7

Kontext

Der zweite Formular-Provider ist Joomla: für Projekte, die Anfragen speichern, im Backend verwalten, exportieren oder in bestehende Prozesse einbinden müssen. Dafür braucht es eine Komponente com_kickastroforms und ein Webservices-Plugin, das die öffentliche Route bereitstellt.

Zwei Fragen sind zu entscheiden, bevor eine Zeile davon entsteht: Wo lebt dieser Code — und welche Joomla-Versionen bedient er?

Entscheidung

Die Erweiterung bekommt ein eigenes Repository mit eigener Versionierung und eigenen Releases. Dieses Repository trägt ausschließlich die Frontend-Seite: den providerunabhängigen Client, den versionierten Vertrag, die Konfiguration, die Contract-Tests und die Dokumentation zur kompatiblen Gateway-Version.

Eine Codebasis bedient Joomla 5.4 LTS und 6.x, minimale Anforderung PHP 8.3. Joomla 4 und älter werden nicht unterstützt.

Die Vertragsversion regelt die Kompatibilität. Jede Release der Erweiterung nennt, welche Vertragsversionen sie bedient. Beim Aktualisieren gilt: erst das Gateway, dann die Website.

Begründung

Warum ein eigenes Repository — anders als beim PHP-Handler. Der PHP-Handler wird mit dist/ zusammen ausgeliefert und liest die erzeugte Allowlist derselben Auslieferung; er hat keinen eigenen Lebenszyklus (ADR 0010). Die Joomla-Erweiterung hat genau das Gegenteil: Sie wird auf einem Server installiert, der schon läuft, aktualisiert sich über einen Update-Server, hängt an Joomla statt an Astro und bedient womöglich mehrere Kundenwebsites gleichzeitig. Sie in dieses Template zu legen hieße, sie in jedes Kundenprojekt zu kopieren, das sie nie benutzt.

Warum keine Unterstützung für Joomla 4. Andere Namespace- und Service-Provider-Struktur, anderer API-Router, PHP-Anforderungen aus einer anderen Zeit. Die Unterstützung wäre nicht ein paar Weichen, sondern eine zweite Fassung.

Warum 5.4 und 6.x gemeinsam gehen. Beide Reihen teilen den Namespace-Aufbau, services/provider.php, SubscriberInterface und den API-Router. Was 6.0 entfernt hat — allen voran Factory::getDbo() —, ist in 5.4 bereits deprecated und lässt sich in einer Fassung vermeiden, die in beiden läuft. Compatibility Shims sind dafür nicht nötig, und wo sie nötig wären, wäre das ein Hinweis, die Anforderung zu streichen statt sie zu überbrücken.

Zwei Reihen parallel zu pflegen ist der Schritt, der aus einer Erweiterung zwei macht — mit zwei Fehlerbildern, zwei Releases und der stillen Gewissheit, dass eine davon seltener geprüft wird.

Warum der Vertrag die Kompatibilität regelt und nicht die Versionsnummer der Erweiterung. Frontend und Gateway werden von verschiedenen Leuten zu verschiedenen Zeitpunkten aktualisiert. Eine Zusage der Form „ab 2.1 kompatibel" wäre nach dem dritten Kundenprojekt niemandem mehr präsent. Die Vertragsversion geht dagegen mit jeder Übermittlung hinaus, und ein Gateway, das sie nicht kennt, lehnt mit invalid_request ab, statt zu raten.

Verworfene Alternativen

Die Erweiterung in diesem Repository, in einem Unterordner. Sie würde in jedes Kundenprojekt kopiert, das aus diesem Template entsteht — auch in die zwanzig, die nie ein Joomla-Backend haben. Und ihre Releases hingen an denen des Starters.

Ein Monorepo für Starter, PHP-Handler und Joomla-Erweiterung. Löst ein Problem, das es nicht gibt, und bringt eines mit: Das Repository ist ein Template. Alles darin wird vervielfältigt.

Nur Joomla 6 unterstützen. Wäre sauberer und ginge an der Wirklichkeit vorbei: Kunden mit laufenden 5.x-Installationen sind genau die Zielgruppe dieses Providers.

Konsequenzen

• Der Starter ist ohne die Erweiterung vollständig — mit provider: 'joomla' konfiguriert er einen Endpunkt, den es noch nicht gibt. Die Dokumentation sagt das deutlich.
• Der Endpunkt ist immer Cross-Origin. Das Gateway muss den Preflight beantworten und Access-Control-Allow-Origin auf die konkrete Adresse setzen — nicht auf *.
• Beide Seiten prüfen gegen dieselbe erzeugte Vertragsdatei. Sie ist damit die einzige Schnittstelle zwischen zwei Repositories, die sich sonst nicht kennen.
• Das Same-Origin-Gateway — der PHP-Endpunkt als echter Proxy vor einem Joomla-Backend — bleibt möglich: submitForm() kennt ohnehin nur Adresse und CORS-Modus.