Nicht zuletzt durch das WP Drama angeregt habe ich mal wieder Lust bekommen mir anzusehen was die anderen CMS System so treiben.
Meine Zugang war dabei primär welche Pain Points ich persönlich in WP sehe und was es da für interessante andere Ansätze bei anderen CMS gibt.
Wie der Name sagt sind CMS dafür da Content zu verwalten. Also fangen wir mal da an.
Für viele Leute ist das Killerfeature von WP in der Block-Ära dass man beim bearbeiten sieht wie die Webseite im Frontend aussehen wird. Also dass man Layout und Inhalte gleichzeitig sieht und bearbeitet. Für mich ist das oft gleichzeitig die größte Achillesferse von WP.
Wo genau habe ich ein Problem damit? Stellen wir uns folgenden Inhaltstyp vor und wie man den in WP umsetzen könnte:
Man sieht schon, dieser gar nicht so komische Inhaltstyp lässt sich in WP recht schlecht abbilden.
Für ein passendes Editing-UI braucht man Custom-Development oder zumindest Plugins wie ACF.
Manches wie Mehrsprachigkeit ist in WP quasi gar nicht oder nur sehr mühsam sauber lösbar.
Insgesamt kommt WP bzw. zumindest WP Core bei allem was strukturell kein klassischer Blogpost oder eine generische Seite ist oft an seine Grenzen.
Aber nochmal kurz: Warum wollen wir einen Inhaltstyp in dieser Form überhaupt?
Brechen wir das in 3 Schritte auf:
Hier also ein paar Ansätze aus anderen CMS. Sehr high level, nicht wie das komplett geht, sondern was netter funktioniert als in WP:
Inhalte in YAML Dateien einfach definierbar
Als Textdateien dann auch leicht versionier- und mergebar.
UI um eigene Content Typen und Felder zu definieren
Einstellungen leicht importieren/exportieren -> Versionierung, Migration (Ähnlich ACF Export/Import/Sync nur für alles)
Blöcke ähnlich WP, nicht ganz so flexibel, dafür einfacher zu bedienen.
Die Kombination aus Feldern und Blöcken ermöglicht strenge Vorgaben oder mehr Flexibilität je nachdem.
Außerdem deutlich leichter erweiterbar ohne Build Chain
Was ich bisher nicht erwähnt habe ist dass Mehrsprachigkeit sowohl bei Kirby als auch Drupal und Neos ein Kernfeature ist.
Neos geht dabei mit dem Konzept von "Dimensions" sogar noch einen Schritt weiter.
Ohne hier jetzt ins Detail zu gehen: Inhalte in andere Sprachen zu übersetzen bedeutet andere Varianten desselben Inhalts zu haben.
Aber Sprachen sind nicht die einzige Situation wo man so einen Bezug brauchen kann.
Man kann auch die Situation haben dass ein Inhalt z.B. obwohl immer Deutsch für Deutschland und die Schweiz anders sein muss.
Z.B. wegen der Währung oder weil je nach Land andere Produkt-Features verfügbar sind.
Neos ermöglicht z.B. Sprache und Markt als zwei verschiedene "Dimensions" anzulegen. Dann kann man Inhalte für spezifische Kombinationen definieren aber auch Fallback-Regeln wenn etwas überall gleich ist.
Das ist gleich auch ein wunderbares Beispiel dafür wie Neos immer wenn es Bedarf an einem Feature wie Mehrsprachigkeit gibt nicht nur das Feature implementiert sondern gleich eine generische Lösung die auch alle potenziellen Extremfälle mit abbildet implementiert.
Backend Layout in gewissem Rahmen auch in YAML definierbar
Etwas das man doch auch immer wieder braucht ist größere Änderungen an verschiedenen Inhalten vorzubereiten.
Z.B. um bei einem Produktlaunch die Produktseite, den zugehörigen Supportbereich und eine Newsmeldung gleichzeitig zu veröffentlichen.
Und vor der Veröffentlichung mit anderen gemeinsam an diesem Set an Änderungen zu arbeiten.
Hier bietet Neos Workspaces die ähnlich wie Git Branches funktionieren.
Die Templates sind sehr nahe an dem was man von WP gewohnt ist.
Aber es gibt eine saubere, einheitliche API die man auch leicht selbst erweitern kann.
Was ich daran schön finde ist dass man das HTML individuell kontrollieren kann anstatt auf fremdbestimmtes CMS-Markup angewiesen zu sein.
Sehr mächtige Tools um komplexe Datenabfragen und Transformationen zu machen.
Aber steile Lernkurve für etwas das nur in Neos existiert und für viele einfach Use Cases die Sache eher verkompliziert.
Deswegen gehe ich darauf jetzt gar nicht weiter ein.
Daten in WP aus lokaler Umgebung oder Backup zu exportieren und importieren ist eher mühsam.
Einserseits weil die finalen URLs für z.B. Bilder im Post Content etc. immer mit drinnen stecken und man daher immer in der Datenbank herumfummeln muss.
Andererseits weil Posts oder Media keine eindeutigen IDs haben wodurch bei Export und Import z.B. ID-basierte Referenzen leicht kaputt gehen.
Genauso mühsam ist es Einstellungen z.B. zwischen lokaler Entwicklung, Staging und Live Server zu bewegen. Tlw. oder komplett.
Das können andere CMS tlw. deutlich besser:
Nach all diesen technischen Dingen und Features jetzt abschließend noch zu etwas ganz anderem.
Nachdem einer der Gründe warum ich mir überhaupt andere CMS angesehen habe das WP Drama der letzten Monate war hat mich auch interessiert wie die Ökosysteme sowie Macht- und Organisationsstrukturen rund um andere CMS funktionieren.
WordPress Core ist ja Open Source und wird durch Freiwillige, wenn auch oft als gesponsorte Fulltime-Entwickler entwickelt.
So auch viele Plugins.
Gerade größere Plugins, tlw. auch für sehr essenzielle Dinge wie z.B. Custom Post Types oder Formulare sind aber kommerzielle Produkte.
Das bedeutet einerseits stabilere Entwicklung dank tragfähiger Finanzierungsmodelle, andererseits aber auch Fragmentierung und mangelndes Interesse an Kooperation und Standardisierung. Manchmal leider sogar weniger Interesse an Usability oder Sicherheit als an mehr Profit.
Wie sieht das also anderswo aus?