Hallo liebe Netzgemeinde, ich habe ein Problem. Ihr kennt das sicher. Ein Kunde wünscht sich eine Webseite, die er selber pflegen kann, ihr überlegt euch, welches CMS dafür wohl am besten geeignet ist und für welches die meisten Erfahrungswerte in der Firma vorhanden sind.

Am Ende habt ihr dann ungefähr achthundert Seiten mit Contao gebaut und bei der nächsten Projektanfrage ist die Entscheidung quasi sofort klar: Contao. Damit kennen wir uns aus, die Kunden mögen es, man kann alles damit machen. Mhh, aber man könnte ja mal was neues ausprobieren, ne? Ach, die Deadline ist nächste Woche? Okay, Contao.

Weil ich mich natürlich trotzdem weiterbilden will, schaue ich mir noch nebenbei ab und zu ein paar Systeme an. Mit Kirby habe ich schon ein, zwei Seiten gebaut, beides aber ziemlich lang her und vom Umfang weit entfernt von einer großen Seite.

Craft ist ja gerade auch relativ angesagt, da klickte ich mir auch schonmal eine Demo-Instanz und spielte etwas rum.

Drupal gibts schon in Version 8, mehr weiß ich darüber nicht.

Das Problem ist: Ich würde auch gerne mal etwas anderes als Contao einsetzen, weil es wahrlich nicht perfekt ist und ich gerne auch mal einem Freelancer von unserer CMS-Auswahl erzählen würde, ohne Angst haben zu müssen, dass er direkt das Chatfenster schließt. Abgesehen davon kann es ja nur gut sein, auch mal über den Tellerrand zu blicken.

Nur leider ist es nicht möglich ein anderes CMS kennenzulernen, wenn man sich nicht die Zeit nehmen kann, ein großes, komplexes Projekt damit umzusetzen. Sowohl bei Kirby und bei Craft fehlten mir bei den ersten Minuten, die ich damit verbrachte immer diverse Features, die ich von Contao kenne — das ein oder andere hätte ich sicher bei genauerer Recherche gefunden.

Daher nun mein Plan: Ich formuliere hier (bzw in einem Spreadsheet) mal ein paar Real-World-Szenarien, die in Contao abgebildet sind, und die ich mir von einer Alternative auch wünschen würde, und ihr, liebe Blog-Leser, Kirby-Fanatiker, Craft-Experten und Drupal-Könige, helft mir zu beantworten, ob eure Lieblingssysteme diese Szenarien auch abbilden können -- und ob ihr damit gute Erfahrungen gemacht habt.

Kriegen wir das zusammen hin? Das wär doch toll. Immerhin könnt ihr dabei lernen, was ein aktuelles Contao so alles kann! (Ich glaube die meisten kennen nur Version 3.x und hassen es daher)

#1: Genereller Aufbau

Vielleicht kein wirkliches Szenario, aber einfach mal um ein paar Begriffe zu klären. Bei Contao ist das zentrale Element erstmal der Seitenbaum, den man definiert. Hier können Seiten beliebig tief verschachtelt angelegt werden. Die Seiten haben jeweils ein Layout, in dem mehrere Bereiche angelegt werden können (Header, Content, Footer, Seitenleisten, alles was man möchte).

In der Artikelebene kann man den Seiten Artikel zuordnen, die in den Layoutbereichen ausgegeben werden. Artikel können wiederum unendlich viele Content-Elemente haben.

Also: Seite Layout Artikel Content-Element

Artikel hängen also immer fest an der Seite, zu der sie gehören und können nicht geshared werden.

Zusätzlich gibt es noch Module, die direkt in Layoutbereiche gehängt oder als Content-Elemente benutzt werden können, für so Kram wie Navigationen und die Suchfunktion.

(Hier ist die Frage hauptsächlich: Wie ist diese Struktur bei anderen Systemen?)

#2: Mehrsprachigkeit

Will man eine Seite für mehrere Sprachen fit machen, kopiert man einfach den Seitenbaum und übersetzt alle Artikel. Mit einem extra Plugin kann man die Seiten in Sprache A und Sprache B miteinander verknüpfen, sodass man im Frontend über ein Sprachwechsler-Modul auch zwischen “Über uns” und “About us” springen kann.

Ich finde die Lösung mit dem kopierten Seitenbaum mittelmäßig, denn wenn man die Hauptsprache noch nicht ganz fertig gestellt hat, führt das am Ende irgendwie immer dazu, dass man die Sprachversionen da immer manuell synchronisieren muss, sonst fehlt in der anderen Sprache eine neu angelegte Seite.

Andererseits hat dieser Ansatz den Vorteil, dass die beiden Sprachversionen auch gegebenenfalls einen anderen Aufbau haben können, oder Seiten, die in manchen Sprachversionen nicht vorhanden sein sollen.

Bei Bildern und anderen Dateien, die man z.B. zum Download anbietet hat man die auch die Möglichkeit die Meta-Daten in diversen Sprachversionen einzugeben. Für eigene Module kann man die interne Label-Funktion verwenden, die auch mehrere Sprachen unterstützt. Leider gibt es dafür keine Editier-Möglichkeit für den Kunden (außer man baut sie sich selber)

(Frage: Ist Mehrsprachigkeit direkt supported, und wie funktioniert sie? Werden Content-Elemente direkt übersetzt, oder kopiert man wie bei Contao den “Seitenbaum”?)

#3: Einfaches Interface (für den Kunden)

Wenn man dem Kunden vernünftige Accounts anlegt, die nur die paar Funktionen haben, die sie auch brauchen (siehe 6.), ist die Oberfläche tatsächlich ganz benutzbar. Seit Version 4.4. sieht das Backend tatsächlich auch nochmal etwas besser aus. Es ist immer noch weit davon entfernt hübsch oder perfekt zu sein, aber unsere Kunden sind eigentlich relativ zufrieden damit.

(Vielleicht ist das hier zu schwammig formuliert. Frage: Kommen eure Kunden mit dem Interface klar?)

#4: Frontend Editing

Am Besten ist es jedoch, wenn der Kunde das Backend gar nicht sehen muss. Das Rocksolid Frontend Helper-Plugin hängt, für eingeloggte User, an jedes Content-Element einen “Editier mich!”-Button an, der ein kleines Overlay spawnt, wo man die allermeisten Elemente wunderbar und schnell editieren kann. Ich selber nutze das fast nie, weil der Frontend-Helper so viele data-Attribute in den DOM schiebt, dass die Chrome Devtools immer fast abstürzen, aber die Kunden lieben es!

(Frage: Gibt es sowas?)

#5: Eigene Content-Elemente

Contao bringt eine Menge Kram mit. Text, Bilder, Video, sogar Akkordeons und Bildergalerien (einiges deaktiviere ich auch direkt wieder, wie die Akkordeons, damit Contao nicht auf die Idee kommt sein eigenes Gammel-Javascript irgendwo zu injecten).

Manchmal braucht man ja aber doch etwas aufregenderes. Ein lustiges Diagramm, eine Auflistung der Team-Mitglieder mit abstrus komplexem Markup, was auch immer. Natürlich könnte man jetzt ein “HTML”-Content-Element benutzen und den nötigen Code da reinhauen, aber das ist nicht sehr kundenfreundlich.

Glücklicherweise gibt es dafür das Custom Elements-Plugin von Rocksolid. Da reicht es einfach ein Template und einen PHP-Array mit ein paar Konfigurationsoptionen (“Dieses Element hat vorname, nachname, avatar, adresse”) anzulegen und schon kann man das neue Element benutzen, wie ein normales, denn alles fügt sich ganz normal ins Backend ein.

#6: Spezifische Rollen

Oberste Ziel ist ja immer, alles so zu bauen, dass der Kunde nicht aus Versehen irgendwas kaputt machen kann. Dazu ist es natürlich notwendig, dass man die Zugriffsrechte stark einschränken kann. Manchmal soll es auch noch extra Redakteur-Rollen geben, die nur Blogeinträge editieren dürfen, und sonst am besten nichts anfassen.

Das kann Contao alles ziemlich gut. Man kann Benutzern Rechte auf einzelne Seiten, einzelne Module und, wenn man will, sogar einzelne Datenbankspalten geben. Eine Rolle, die nur den Titel der Startseite ändern darf? Kein Problem! Außerdem kann man auch einschränken, wo Dateien abgelegt werden können, usw. Die Admin-Seite um Benutzerrechte zu editieren hat bestimmt tausende Checkboxen!

#7: Eigene Entwicklungen / Dokumentation

Ein Punkt, bei dem ich mir sicher bin, dass andere Systeme überlegen sind. Es gibt zwar einiges an Dokumentation zu Contao, doch das meiste ist für die alte 3.x-Version. Vieles davon geht zwar noch, aber manche Sachen halt nicht mehr, da sich mit der 4.x-Reihe super viel ändert. Aktuell wird da gerade im Grunde das ganze Fundament rausgenommen und gegen ein neues (Symfony) getauscht — möglichst natürlich ohne das Haus einstürzen zu lassen. Für Dokumentation ist da irgendwie keine Zeit.

Dazu kommt auch, dass viele der Plugins für die alte Version sind und manchmal in der neuen nicht funktionieren. Manchmal schon, nachdem man zwei Zeilen anpasst und sie in den richtigen Ordner schiebt. Die Plugins kann man, bis auf wenige Ausnahmen, auch nicht nehmen um etwas zu lernen, da sie entweder alte Sachen benutzen, die vor Deprecation-Warnings nur so strotzen, oder einfach so schrottig entwickelt sind, dass man seinen Rechner am Liebsten sofort verbrennen würde (klassisches PHP-Problem)

Vor allem am Anfang fand ich auch immer ganz schlimm, dass sich jedes Plugin, was man selber schreibt wie ein riesiger Hack anfühlt. Wenn man sich näher damit beschäftigt, sieht man auch dass das alles ein mega Hack ist. In der Zukunft wird das sicher besser, da mit Symfony jetzt ja auch ein besseres System für Plugins/Bundles Einzug hält, aber ich denke es wird noch lange dauern, bis der letzte $GLOBALS[]-Aufruf aus dem Code verschwunden ist.

(Frage: Wie ist der Source / Wie fühlt es sich an Plugins zu schreiben / Gibt es gute Doku / Community?)

#8: Legacy / Ausrichtung

Wie bei #7 schon gesagt gibt es einfach mega viele Sachen, die sich wie 2005 anfühlen und nicht wie ein modernes CMS. Wahrscheinlich gibt es noch Funktionen, die noch aus der TypoLight-Zeit dabei sind und sich kaum verändert haben.

Contao ist halt vor allem auch ein CMS für Leute, die keine Ahnung von sowas haben, sich ein CMS runterladen, für 20€ ein Theme kaufen und eine Webseite haben. Also Leute, die auch lieber zu Squarespace oder Jimdo gehen könnten.

Ich bin auf der Suche nach einem CMS mit dem Fokus auf Entwickler, die für Kunden Seiten bauen. Mit Unterstützung für einen modernen Frontend-Entwicklungsprozess (nein, mein CMS braucht keinen eingebauten Sass-Compiler, ich will auch im Seitenlayout keine Google Fonts angeben können und mitgelieferte Content-Elemente sollten nicht 20 Javascript-Libraries inkludieren) und einem Interface, dass darauf optimiert ist, dass der Kunde am Ende alles gut pflegen kann.

#9: Patternlab

Seitdem mir Martin das gezeigt hat, bin ich ein großer Fan von Patternlabs. Beim letzten großen Projekt habe ich das auch freudestrahlend angefangen und ganz gut gepflegt, aber das große Problem ist natürlich, dass es sehr viel Disziplin erfordert, wenn das Patternlab nicht direkt im CMS integriert ist. Leider ist es das hier nicht. Ich hab zwar mal angefangen, da ein Plugin zu schreiben, aber da schwanke ich die ganze Zeit zwischen “boah, was für ein Hack” und “boah, bringt das wirklich was? Vielleicht wechseln wir ja mal das CMS.”.

#10: Multidomain

In einem Contao kann ich soviele Seitenbäume anlegen wie ich will, die auch zu anderen Domains gehören können. kunde.de, tolle-werbeaktion-landingpage-von-kunde.de, usw. kann also alles in einem System abgefeiert werden.

Jetzt seid ihr dran!!

Falls ihr bis hierhin gelesen habt, schonmal nicht schlecht. Ich hab die Punkte jetzt nochmal in ein Spreadsheet gepackt, in dem jeder wild editieren darf. Mein größter Wunsch (ich hatte letztens erst Geburtstag, das zählt noch!) wäre es nun, wenn sich alle von euch, die genug Erfahrung mit einem CMS haben, das mal angucken könnten und vielleicht zu dem ein oder anderen Punkt etwas beisteuern kann, sodass ich mir ein Bild von der Konkurrenz machen kann, ohne ein großes Projekt mit einem der Systeme umzusetzen! (Ich brauche keine Romane, ein paar Stichpunkte wären teilweise wahrscheinlich ausreichend)

Zum Spreadsheet

Was ihr davon habt? Naja, immerhin mein Wissen über Contao schonmal (Contao 4.x ist gar nicht so schlimm, ihr müsst keine Angst haben!). Vielleicht ist die Tabelle am Ende vielleicht auch für andere hilfreich.

Wenn euch noch ein “Szenario” einfällt, bitte auch gerne hinzufügen.

Danke an alle!