Joomla und Next.js: Headless, ohne die ACL zu verlieren

Joomla wird in der Headless-Diskussion meist ausgelassen, und das ist nicht mehr aktuell. Joomla 4 brachte eine Web-Services-API in den Kern - Artikel, Kategorien, Benutzer, mit Token-Authentifizierung - und Joomla 5 hat darauf aufgebaut. Das ist eine REST-API, die als Teil der Plattform gepflegt wird und nicht als Erweiterung, die jemand am Leben halten muss, und genau das macht daraus eine echte Architektur statt einer cleveren Idee.

Was zu behalten sich lohnt

Zwei Dinge, und sie sind der Grund, warum diese Kombination interessant ist statt beliebig.

Die Zugriffssteuerung. Joomlas ACL ist im Kern feingranular: Gruppen, Zugriffsebenen, Rechte je Aktion bis auf einzelne Elemente hinunter. Wenn Sie eine echte redaktionelle Hierarchie haben - Autoren, Prüfer, Abteilungen, die nur ihren eigenen Bereich anfassen dürfen -, ist dieses Modell bereits gebaut und anderswo teuer nachzubilden.

Das mehrsprachige Setup. Nativ, mit Verknüpfungen zwischen übersetzten Elementen, und ohne Plugin. Wer dasselbe anderswo aus Einzelteilen zusammengesetzt hat, weiß, was das wert ist.

Beides überlebt den Umzug des Frontends. Das ist der Punkt an dieser Vorgehensweise.

Was sich ändert und was Sie entwerfen müssen

Das Rendering zieht um, also ist das Rendering-Modell das, was man zuerst versteht. Welche Routen statisch sind, welche bei einer Veröffentlichung revalidieren, welche dynamisch sein müssen, weil sie davon abhängen, wer fragt.

Zwei Dinge brauchen ausdrücklichen Entwurf statt Annahme.

Sichtbarkeitsrechte. Die ACL entscheidet weiterhin, wer bearbeiten darf. Wer ein Element sehen darf, muss nun auch vom Frontend durchgesetzt werden, diese Logik existiert also an zwei Stellen und sie müssen übereinstimmen. Entscheiden Sie, wo die Prüfung stattfindet, und schreiben Sie es auf.

Sprach-Routing. Die Verknüpfungen kommen über die API, und das Frontend bildet sie auf seine Routen ab. Hreflang aus diesen Verknüpfungen abzuleiten statt aus einer Liste in einer Konfigurationsdatei ist das, was verhindert, dass die Site Übersetzungen ankündigt, die es nicht gibt - und das ist der häufigste Weg, auf dem das schiefgeht.

Was es kostet

Die Template-Bedienung. Modulpositionen, der Menümanager, Dinge ohne Entwickler anordnen. Ein Teil kommt über die Art zurück, wie das Frontend gebaut wird, und es ist ein Gespräch, das vor dem Projekt mit der Redaktion zu führen ist und nicht danach.

Die Vorschau. Sie entscheidet, ob die Redaktion dem System weiter vertraut. Kann ein Entwurf nicht so gesehen werden, wie er erscheinen wird, gilt das Projekt aus Gründen als gescheitert, die mit Rendering nichts zu tun haben. Es ist die spezifische Fehlerart jedes Headless-CMS-Projekts, keine Joomla-Eigenheit.

Erweiterungen, die rendern. Alles, was per HTML-Ausgabe in ein Template funktionierte, gilt nicht mehr. Jedes wird zur Entscheidung: gegen die API neu bauen, ersetzen oder bewusst streichen.

Wann man das Template in Ruhe lässt

Besteht die Site aus Artikeln und Seiten und macht das Template seinen Job, liegen die günstigeren Gewinne woanders. Bilder, Schriften, die Skripte, die sich angesammelt haben. Das ist meistens die ganze langsame Seite, und es kostet eine Woche statt eines Projekts.

Headless verdient seinen Platz, wenn das Frontend mehr sein muss als ein Template: ein Anwendungsbereich hinter einem Login, ein Design System, das mit einem Produkt geteilt wird, oder Rendering-Verhalten, das das Template nicht ausdrücken kann. Bis dahin ist eine Joomla-Site mit gepflegtem Template und funktionierender ACL eine Site in gutem Zustand, und es gibt keinen Preis dafür, sie zu ersetzen.