Das richtige CMS für die richtige Aufgabe

Es gibt nicht das eine beste „Content-Management-System“ (CMS), den „Motor“, der eine Website antreibt. Es gibt nur das richtige für ein bestimmtes Projekt, ein bestimmtes Team und eine bestimmte redaktionelle Realität. Welches System man wählt, hängt letztlich vom jeweiligen Projekt ab.

Um es klarzustellen: Dies ist kein Vergleichsartikel. Wir sind nicht hier, um Ihnen zu sagen, dass X besser ist als Y. Stattdessen schildert dieser Artikel, wie wir tatsächlich arbeiten und warum wir uns bewusst dafür entschieden haben, Kompetenz über mehrere Stacks hinweg aufzubauen, statt uns auf einen einzigen festzulegen.

Die WordPress-Standardlösung und ihre Grenzen

Viele Agenturen konzentrieren sich aus guten Gründen auf WordPress: Es verfügt über ein enormes Ökosystem, einen nahezu universellen Bekanntheitsgrad bei Kunden und eine niedrige Einstiegshürde für nicht-technische Redakteure. Wir haben Websites mit WordPress gebaut und werden dies auch weiterhin tun.

Aber WordPress hat eine Anziehungskraft, die ein Projekt verzerren kann. Wenn jedes Problem nach einem Plugin zu verlangen scheint, landet man bei plugin-abhängigen Architekturen, die schwer zu warten, von Haus aus langsam und strukturell durch das begrenzt sind, was das Ökosystem zufällig hergibt. Das CMS beginnt, das Produkt zu formen, statt ihm zu dienen. Funktionen werden um das herum konzipiert, was verfügbar ist, statt um das, was angemessen wäre; WordPress wird verbogen und verzerrt, um den oft wechselnden Anforderungen des Kunden gerecht zu werden. Technische Schulden häufen sich still und leise hinter einer vertrauten Oberfläche an.

Dann ist da noch die Frage der Langlebigkeit. WordPress-Sites, die auf einem Stapel von Drittanbieter-Plugins aufbauen, sind nur so zuverlässig wie der langsamste Maintainer in der Kette. Ein Plugin, das von seinem Autor aufgegeben wird, ein Theme-Framework, das keine Sicherheitsupdates mehr erhält, ein Page-Builder, der sein Datenmodell in einer Hauptversion neu schreibt: Das sind keine hypothetischen Risiken. Sie gehören zum normalen Lebenszyklus eines WordPress-Projekts, das nicht auf langfristige Eigentümerschaft ausgelegt wurde.

Die Frage, die wir uns vor Beginn eines jeden Projekts stellen, lautet: Passt es zu WordPress, oder zwingen wir WordPress, zu diesem Projekt zu passen? Wenn wir eindeutig Letzteres tun, ist es Zeit, etwas anderes in Betracht zu ziehen. Wir waren schon dort!

Vier Werkzeuge, vier Arten von Lösungen

In den letzten Jahren haben sich vier Plattformen einen festen Platz in unserer Arbeitsweise beim Bau von Websites erarbeitet. Das sind WordPress, Laravel, Statamic und – nicht zuletzt – ProcessWire.

WordPress: für content-getriebene Sites mit nicht-technischen Redakteuren

Wenn eine Site primär redaktionell ist, wenn das Kundenteam eigenständig publizieren wird und wenn sich das Content-Modell vernünftig auf Seiten, Beiträge und benutzerdefinierte Felder abbilden lässt, ist WordPress nach wie vor die pragmatischste Wahl. Die Bearbeitungserfahrung ist vertraut, das Plugin-Ökosystem deckt die meisten Anforderungen ohne individuelle Entwicklung ab, und Kunden können nach der Übergabe wirklich eigenständig arbeiten.

Wir setzen es für öffentliche Websites von Institutionen und Organisationen ein, bei denen das Content-Volumen hoch ist und das Redaktionsteam keinen Entwickler in der Nähe hat. Die Einrichtungszeit ist gering, der Hosting-Markt ist wettbewerbsfähig, und das Wissen, das zum täglichen Betrieb der Site nötig ist, ist weit verbreitet.

Aber es gibt definitiv Kompromisse. WordPress trägt architektonische Altlasten mit sich, die Performance und Sicherheit zu dauerhaft relevanten Themen machen. Alles, was signifikant vom Standard-Content-Modell abweicht, erfordert entweder einen Plugin-Kompromiss oder erheblichen Eigenaufwand, was die Projektkosten erhöht. Und die Bearbeitungserfahrung ist zwar vertraut, aber nicht besonders ausgefeilt. Für das richtige Projekt ist es immer noch der effizienteste Weg vom Briefing zur fertigen Site. Für das falsche bringt es Reibungsverluste mit sich, die sich mit der Zeit summieren.

Darüber hinaus gibt es einen Grund, sich für WordPress zu entscheiden, der in einer eigenen Kategorie steht: WooCommerce. Für Kunden, die einen Online-Shop mit echter Komplexität benötigen – etwa mit individuellen Produkttypen, bedingter Preisgestaltung, Abo-Logik, Stufen für Geschäftskonten oder tiefer Integration in eine bestehende redaktionelle Site – besetzt WooCommerce einen nützlichen Mittelweg. Shopify ist schneller startklar, sperrt einen aber schnell ein, sobald die Anforderungen vom Standardmodell aus Katalog und Checkout abweichen. Vollwertige E-Commerce-Frameworks wie Magento oder ein Laravel-basiertes System wie Bagisto oder Lunar sind für echte Skalierung gebaut und bringen entsprechende Komplexität bei Einrichtung, Wartung und Hosting mit.

WooCommerce liegt zwischen diesen beiden Extremen: ein ernstzunehmender Shop auf einer Plattform, die die meisten Kunden bereits kennen, mit einem Plugin-Ökosystem, das ein breites Spektrum kommerzieller Anforderungen abdeckt, ohne dass zwingend eine maßgeschneiderte Lösung in Auftrag gegeben werden muss. Es ist nicht für jeden Shop die richtige Antwort, aber es könnte genau das Richtige sein, wenn man mit den passenden Erwartungen herangeht.

Laravel: für komplexe Systeme und Webanwendungen

Manches, was wir bauen, ist eigentlich gar keine Website. Es ist eine datengetriebene Anwendung mit öffentlichem Gesicht: ein Mitgliederportal, ein Branchenregister, ein Workflow-System mit rollenbasiertem Zugriff, komplexe Beziehungen zwischen Entitäten und Geschäftslogik, die kein CMS auszudrücken vorgesehen war.

Für solche Projekte bauen wir mit dem PHP-Framework Laravel, das weithin zur Erstellung von Webanwendungen genutzt wird. Es folgt dem MVC-Muster (Model, View, Controller), verfügt über ein ausdrucksstarkes ORM (Eloquent), ein sauberes Routing- und Middleware-System sowie ein großes Ökosystem an First-Party-Paketen. Es siedelt sich in dem Raum zwischen dem Schreiben eines eigenen, vollständigen CMS – eine Übung, die man am besten denen überlässt, die zu viel Zeit haben, glauben Sie uns! – und einem CMS an, bei dem die Struktur Ihrer Daten für Sie entschieden wird. Mit Laravel erhält man starke Konventionen und exzellentes Tooling, ohne an ein Content-Modell gebunden zu sein, das jemand anderes entworfen hat, wie es bei WordPress der Fall ist.

Mit Laravel ist das Datenmodell genau das, was es sein muss. Die Geschäftslogik lebt in der Anwendungsschicht, nicht in Notlösungen über Feldkonfigurationen. Beziehungen zwischen Entitäten werden so ausgedrückt, wie sie tatsächlich existieren, und nicht über Taxonomien oder benutzerdefinierte Beitragstypen angenähert. Für eine ausgereifte, flexible Admin-Oberfläche setzen wir auf Nova, sodass wir kein komplettes Backend von Grund auf neu bauen müssen. Sowohl für Entwickler als auch für Endnutzer lässt sich mit Laravel + Nova hervorragend arbeiten.

Dies ist die leistungsfähigste Option, um eine große, moderne Website zu bauen, aber auch die teuerste. Sie erfordert ein echtes Entwicklungsengagement, bringt etwas hervor, das in keiner Hinsicht von der Stange ist, und legt die langfristige Eigentümerschaft klar in die Hände der Agentur, sofern der Kunde nicht über nennenswerte eigene Entwicklungskapazitäten verfügt. Es ist die richtige Wahl, wenn das Projekt sie wirklich benötigt.

Ein Beispiel ist eine White-Label-Plattform für Energietarife, die wir für einen Kunden aus der Versorgungsbranche gebaut haben. Das System erlaubt es Partnern, anpassbare Tarifvergleichs-Widgets über ein Script-Tag und einen API-Schlüssel in ihre eigenen Websites einzubetten. Jeder Partner hat seine eigene Projektkonfiguration im Nova-Admin-Panel: Branding, Checkout-URLs, Tarifüberschreibungen, benutzerdefinierte Feldwerte und Widget-Verhalten.

Das Backend für dieses Projekt verarbeitet versionierte REST-Endpunkte, Tarifabfragen auf Basis von Postleitzahlen und ein flexibles Override-System, das es nicht-technischen Administratoren ermöglicht, die Preisanzeige und das Button-Verhalten anzupassen, ohne Code anzufassen. Nichts davon lässt sich in irgendeinem CMS von der Stange sinnvoll abbilden. Das Datenmodell, die Mandantenfähigkeit, die API-Schicht und die Admin-Oberfläche mussten alle rund um die tatsächlichen Anforderungen entworfen werden, statt aus etwas adaptiert zu werden, das für das Veröffentlichen von Artikeln gebaut wurde.

Statamic: für redaktionelle Sites, die ein ordentliches Fundament verdienen

Statamic besetzt einen spezifischen und wirklich wertvollen Mittelweg zwischen einer komplett individuellen Lösung und einem eher klassischen CMS. Es baut auf Laravel auf, speichert Inhalte aber standardmäßig als Flat Files, wobei Datenbankunterstützung verfügbar ist, und bringt ein gut gestaltetes Control Panel mit, das Redakteure tatsächlich gerne benutzen. Für Projekte, bei denen die redaktionelle Erfahrung zählt und das Content-Modell zwar bedeutsam, aber nicht wahnsinnig komplex ist, ist es oft die beste Antwort.

Seinen Platz verdient es bei Projekten, in denen das Kundenteam genug technisches Verständnis mitbringt, um eine durchdachte Oberfläche zu schätzen, und das Entwicklungsteam davon profitiert, innerhalb eines ordentlichen MVC-Frameworks zu arbeiten, statt mit dem prozeduralen Erbe von WordPress. Inhalte liegen in versionierbaren Dateien. Deployments sind sauberer. Die Codebasis ist auf eine Weise testbar, wie es WordPress-Projekte selten sind. Das Bauen eigener Fieldtypes, Control-Panel-Ansichten oder Content-Workflows fühlt sich an wie das Schreiben von Laravel-Code – weil es das ist.

Wir haben Statamic für redaktionslastige Sites verwendet, bei denen die Inhalte strukturiert sind, der Kunde über eine gewisse technische Versiertheit verfügt und die langfristige Wartbarkeit eine Rolle spielt. Eines sollte man klar benennen: Statamic Pro erfordert eine Lizenz, was ein realer Posten im Budgetgespräch ist. Es ist ein angemessener Gegenwert für das, was man bekommt, aber es gehört von Anfang an in die Kalkulation.

Für eine bestimmte Klasse von Projekten – jene, die WordPress entwachsen sind, aber keine vollständig maßgeschneiderte Anwendung benötigen – ist Statamic die vollständigste Antwort, die wir gefunden haben. Und der große Vorteil ist, dass sich ein solches Projekt bei Bedarf problemlos hochskalieren lässt, um den vollen Funktionsumfang von Laravel zu nutzen. Bei manchen Projekten mischen wir zum Beispiel Statamic mit einem Nova-Backend: Redaktionelles bleibt im Control Panel von Statamic, während komplexere Daten, die nicht von regulären Redakteuren bearbeitet werden müssen, über Nova abgewickelt werden.

ProcessWire: für entwicklergebaute mehrsprachige Sites

ProcessWire ist das, was herauskommt, wenn ein CMS von jemandem entworfen wird, der maximale Flexibilität wollte und kein Interesse daran hatte, es Nicht-Entwicklern leicht zu machen. Das ist ein Feature, kein Kritikpunkt. Es ist gegenüber Daten vollkommen agnostisch, verlangt aber, dass alle Informationen in Seiten organisiert werden: Seine Web-Struktur ist zugleich seine Datenstruktur.

Das Datenmodell ist jedoch wirklich granular. Felder, Templates und Seitenbäume lassen sich zu nahezu jeder Struktur zusammensetzen, ohne gegen das Framework anzukämpfen. Mehrsprachigkeit ist erstklassig und von Haus aus eingebaut, statt nachträglich aufgesetzt zu werden. Die API ist sauber und konsistent. Und die Codebasis bleibt schlank: Es gibt kein umfangreiches Plugin-Ökosystem, auf das man angewiesen wäre, was bedeutet, dass es auch nichts gibt, das zur Belastung werden könnte.

Wir greifen zu ProcessWire bei Sites, die maßgeschneiderte Funktionen und Datenstrukturen erfordern, bei denen WordPress aber wenig Sinn ergäbe und für die Laravel klar überdimensioniert wäre. Es belohnt präzises Nachdenken über die Content-Struktur und hat keine starke Meinung dazu, wie eine Seite aussehen oder was sie enthalten soll. Das Fehlen von Templates von der Stange ist gerade der Punkt: Man baut genau das, was das Projekt verlangt, und nichts darüber hinaus.

Der Nachteil ist genau das, was es zu einer starken Wahl macht. Es gibt keine große Community fertiger Plugins, auf die man zurückgreifen könnte, und keinen Marktplatz mit Themes, um frühe Entscheidungen zu beschleunigen. Allerdings bietet es eine bequeme Backend-Oberfläche, in der sich ein Redakteur sofort zu Hause fühlt. Es ist das perfekte System, um etwas Maßgeschneidertes zu bauen, ohne sich vollständig auf eine große und komplexe Anwendung wie Laravel einzulassen.

Wie wir tatsächlich entscheiden

Das Entscheidungsraster ist weniger glamourös, als es klingt. Das meiste läuft auf eine Handvoll Fragen hinaus, die früh gestellt werden – idealerweise, bevor jemand eine Meinung zu verteidigen hat.

Wer pflegt diese Inhalte, und wie oft? Nicht-technische Redakteure, die eigenständig arbeiten müssen, sprechen für WordPress oder Statamic. Wer keine Scheu vor einer kleinen Lernkurve hat, kommt auch mit ProcessWire zurecht, besonders wenn mehrsprachige Optionen im Vordergrund stehen müssen.

Wie komplex ist das zugrundeliegende Datenmodell? Standard-Beiträge und -Seiten sprechen für WordPress. Strukturierte, aber nicht-relationale Inhalte sprechen für Statamic oder ProcessWire, während relationale Daten mit relevanter Geschäftslogik für Laravel sprechen.

Ist Mehrsprachigkeit von Tag eins an eine Anforderung? ProcessWire und Statamic handhaben dies natürlicher als WordPress, wo Mehrsprachigkeit historisch eine Plugin-Angelegenheit war und die Ergebnisse stark schwanken.

Wie sieht die langfristige Eigentümerschaft aus? Ein Kunde ohne eigene technische Ressourcen braucht ein System, das ohne ständige Eingriffe würdevoll altert. Das verändert die Rechnung erheblich.

Wie hoch ist das tatsächliche Budget über Entwicklung, Lizenzierung und Wartung hinweg? Diese Zahlen beeinflussen sich auf Weisen, die zu Beginn nicht immer offensichtlich sind. Ein günstigeres CMS, das mehr individuelle Entwicklung erfordert, kann am Ende teurer sein als eine lizenzierte Plattform mit besserem integriertem Tooling.

Keine einzelne Plattform gewinnt jede dieser Fragen. Der Punkt ist, sie alle zu stellen, bevor man sich auf eine Antwort festlegt.

Wendigkeit als Dienstleistung

Es gibt die einfache Variante: Man wählt eine Plattform, wird darin richtig gut, und das ist dann das Angebot. Viele Agenturen machen genau das, und es funktioniert. Der Haken ist, dass jedes Projekt dieselbe Antwort bekommt, bevor die Fragen überhaupt gestellt wurden. Die Empfehlung kommt vor der Diagnose.

Wir sind einen anderen Weg gegangen, und ehrlich gesagt ist er schwieriger. Echte Kompetenz über mehrere Systeme hinweg zu erhalten, erfordert nicht nur Vertrautheit, sondern jene Art von Wissen, die es einem erlaubt zu sagen: „Das wird Ihnen in zwei Jahren Probleme bereiten.“ Das aufzubauen braucht Zeit und verlangt, Aufträge abzulehnen, die nicht passen, statt eine Plattform zu strecken, um sie abzudecken.

Ob das die bessere Wette ist, finden wir noch heraus. Was wir sagen können: Wenn wir ein System empfehlen, dann weil wir damit echte Dinge gebaut, seine Grenzen erfahren und entschieden haben, dass es für eine bestimmte Art von Aufgabe trotzdem das richtige Werkzeug ist. Nicht, weil es das war, was wir zuletzt verwendet haben, oder weil es das ist, dessen Namen der Kunde bereits kennt.

Das ist es, was wir anzubieten versuchen. Ob es das ist, was Sie brauchen, ist eine andere Frage – und es lohnt sich, sie zu stellen, bevor wir loslegen.