Lohnt es sich noch, auf Joomla zu bauen?

Für eine strukturierte, mehrsprachige Inhaltsseite mit echten Rechteanforderungen bringt es mehr im Kern mit als die meisten Alternativen, und daran hat sich nichts geändert. Für diese Art von Seite ist es eine vernünftige Wahl. Was es nicht leistet, ist transaktionale Geschäftslogik zu halten, was für jedes CMS gilt und wovon diese Seite handelt.

Warum nicht einfach als Joomla-Komponente bauen?

Das ist ein legitimer Weg und manchmal der richtige, besonders wenn die Arbeit nahe an Inhalt und Rechten liegt. Die Überlegung betrifft den Umfang: Eine Komponente trägt Joomlas Annahmen und seinen Lebenszyklus, eine Komponente, die zu einer vollen Anwendung wächst, bedeutet also, dass Sie eine Anwendung innerhalb eines CMS-Release-Zyklus pflegen statt daneben.

Müssen wir die Inhalte auch umziehen?

Meist nicht, und oft sollten Sie es nicht. Joomla kann die Redaktionsoberfläche und Inhaltsquelle bleiben, während die Anwendung daneben entsteht. Die Redaktion behält die Oberfläche und das Rechtemodell, das sie schon hat, und die Migration beschränkt sich auf den Teil, der tatsächlich umziehen musste.

Wie planen wir, wer es danach pflegt?

Diese Frage lohnt früh und auf beiden Seiten der Entscheidung. Joomlas Talentpool ist kleiner als der von WordPress, und eine Laravel-Codebasis braucht eine andere Einstellung als eine Joomla-Codebasis. Wie Sie sich auch entscheiden, die Frage lautet, wer Ihnen in zwei Jahren zur Verfügung steht, und das ist eine Planungsgröße und kein Argument für eine der Optionen.

Joomla oder Laravel: Wenn Inhaltsstruktur nicht reicht

Joomla kann von Haus aus Dinge, für die WordPress Plugins braucht, Zugriffsrechte gehören dazu. Die Grenze liegt dort, wo die Arbeit aufhört Inhalt zu sein und Transaktion wird.

Veröffentlicht am 22. September 20263 Min. LesezeitAktualisiert am 23. September 2026

Über Joomla wird oft unsauber geschrieben, deshalb lohnt es sich, vor dem Argument genau zu sein.

Joomla bringt ein feingranulares Rechtesystem mit, native Mehrsprachigkeit und strukturierte Inhalte mit Kategorien und eigenen Feldern, und nichts davon braucht eine Erweiterung. Auf einer Seite, auf der Redakteure wirklich unterschiedliche Rechte haben und die Inhalte in vier Sprachen existieren, ist das ein echter Vorsprung gegenüber den Alternativen, und es ist der Grund, warum viele institutionelle und öffentliche Seiten darauf laufen.

Das hier ist also keine Seite über eine schwache Plattform. Es ist eine Seite über eine Grenze, die jedes Content-Management-System hat.

Wo die Grenze liegt

Ein CMS modelliert Dokumente und wer sie anfassen darf. Das ist die Abstraktion, und Joomla setzt sie gut um.

Die Grenze ist erreicht, wenn das, was modelliert werden muss, kein Dokument ist. Eine Bestellung mit Zuständen. Ein Antrag mit Freigabekette und Frist. Eine Buchung mit Bestand dahinter. Ein Finanzsatz, der nächstes Jahr noch stimmen muss. Das sind Transaktionen, und eine Transaktion ist kein Dokument mit zusätzlichen Feldern, so überzeugend es auch so aussehen kann.

Das praktische Signal ist auf jeder Plattform dasselbe: Jemand fragt, wo eine Regel lebt, und die Antwort umfasst eine Komponente, ein Plugin, ein Override und ein Template. Nicht weil jemand nachlässig war, sondern weil die Regel nie eine Inhaltsregel war.

Die Frage der Komponente

Joomla hat eine ordentliche Erweiterungsarchitektur, und eine eigene Komponente zu bauen ist eine legitime Antwort. Manchmal ist sie die richtige, besonders wenn die Arbeit nah an Inhalt und Rechten bleibt und davon profitiert, dass die ACL bereits da ist.

Die Überlegung betrifft den Umfang, nicht das Können. Eine Komponente erbt Joomlas Annahmen, seinen Request-Lebenszyklus und seinen Release-Takt. Für etwas in Komponentengröße ist das in Ordnung. Wenn das Gebaute eine Anwendung ist, die zufällig Inhalte braucht, pflegen Sie am Ende eine Anwendung innerhalb eines CMS-Release-Zyklus, und jedes Joomla-Upgrade wird zu einer Frage über Ihre Geschäftslogik.

Das früh zu entscheiden ist deutlich billiger, als es im dritten Jahr zu entdecken.

Was nicht geändert werden muss

Das Ergebnis, das wir am häufigsten empfehlen, ist keine Migration.

Joomla behält die Inhalte, die Redaktion und das Rechtemodell. Die Anwendung - der Teil mit den Transaktionen - entsteht daneben in Laravel und liest über Joomlas API, was sie braucht. Niemand lernt eine Oberfläche neu. Das mehrsprachige Setup, das Sie gebaut haben, wird nicht neu gebaut. Und die Arbeit beschränkt sich auf den Teil, der wirklich ein anderes Werkzeug brauchte.

Wo mehr umziehen muss, zieht es in Phasen um, mit beiden Systemen live, was unsere Art ist, das zu tun, unabhängig davon, wovon umgezogen wird.

Die Wartungsfrage, auf beiden Seiten

Sie gehört laut gestellt und in beide Richtungen, denn sie entscheidet mehr davon als die Architektur.

Joomlas Beitragenden- und Agenturpool ist kleiner als der von WordPress. Eine Laravel-Codebasis braucht wieder eine andere Einstellung. Keines davon ist ein Argument für eine Option, beides sind Eingaben in dieselbe Frage: Wer wird in zwei Jahren verfügbar sein, um das zu pflegen, und kommen Sie an diese Leute heran?

Wenn die ehrliche Antwort lautet, dass auf Ihrer Seite niemand eine Framework-Codebasis übernehmen wird, wiegt das schwerer als jeder Architekturvergleich, und wir sagen das lieber vorher, als etwas zu übergeben, das seinen Pfleger überlebt.

Lautet die Antwort, dass der transaktionale Teil dem Inhaltssystem um ihn herum entwachsen ist, dann ist das eine erste Phase, die die Form schriftlich klärt, bevor etwas gebaut wird.

Dieselbe Grenze, auf dem Inhaltssystem, das die meisten Teams tatsächlich betreiben, steht auf der WordPress-Fassung dieser Seite - wo die Antwort häufiger lautet zu bleiben, aus Gründen, die Joomlas ACL teilweise wegnimmt.