Worauf ist EmDash eigentlich die Antwort?

Joost weist in seinem Follow-Up-Artikel zu EmDash, in dem er dem WordPress-Projekt eine Liste von Hausaufgaben auf den Weg gibt, auf das alles entscheidende Kernproblem hin, das EmDash gegenüber WordPress attraktiv macht: das strukturierte Speichern von Daten. WordPress hat bewusst auf ein Datenmodell verzichtet, das Struktur und Inhalt auf einmal transportieren kann – und nicht, wie aktuell, das eine aus dem anderen gewissermaßen ableiten muss.

Replace wp_posts and wp_postmeta with proper typed tables per content type, while preserving the existing APIs. This sounds radical, but it’s been done before, in the WordPress ecosystem itself. […] It can be done, and it’s easier at the core level, since core controls the schema. Automattic proved this again with WooCommerce’s migration from its legacy data model to High-Performance Order Storage — a tested, backwards-compatible approach to exactly this kind of schema change. […] Stop serializing blocks to HTML comments in post_content. Store them as JSON instead, or at minimum alongside the HTML. […] Keeping it as JSON means APIs, headless frontends, and AI agents can work with WordPress content natively, without reverse-engineering structure out of markup. […] This is the single biggest unlock for making content machine-readable, and it’s what EmDash does with Portable Text.

Joost de Valk

Absurder wird es, weil der Block-Editor selbst über Strukturinformationen verfügt, sie beim Speichern aber verwirft. Um sie wiederherzustellen, hat WordPress die Funktion ⁠parse_blocks()erschaffen. Sie extrahiert aus dem Mischmasch an Daten Inhalt und Struktur – ein Problem, das man leicht hätte umgehen können, würde das Datenmodell selbst die Struktur speichern. Joost hat vor sieben Jahren bereits ein Ticket zu dem Thema eröffnet, um, wenn schon eine Änderung des Datenmodells nicht drin ist, wenigstens das Ergebnis von parse_blocks() zu cachen und damit die Performance-Kosten des ständigen Neu-Parsens zu senken. Das Ticket ist bis heute offen.

Aber nicht nur Joost. Auch Hendrik Luehrsen sieht hier ein – immer wiederkehrendes – Problem:

WordPress hat die Entscheidung für HTML in post_content nicht beiläufig getroffen, sondern bewusst begründet. […] Sobald Content mehr sein soll als gerenderte Ausgabe, reicht es nicht, Struktur nur implizit in HTML mitzuschleppen. Dann braucht es ein Datenmodell, das Inhalte nicht bloß darstellt, sondern sie auch maschinell lesbar, sortierbar und weiterverarbeitbar macht. […] Gutenberg behandelt [maschinelle Lesbarkeit] bis heute eher als nachträgliches Problem. […] Genau deshalb produziert WordPress rund um Gutenberg immer neue Hilfskonstruktionen, während EmDash CMS dieselbe Frage eine Ebene früher beantwortet. Die entscheidende Architekturfrage lautet heute eben nicht mehr nur, wie Inhalte editiert werden. Sie lautet, in welcher Form ein System Inhalte dauerhaft begreift.

Hendrik Luehrsen

Was Hendrik Luehrsen da schreibt, ist im Grunde keine neue Erkenntnis, sondern eine Beobachtung über die scheinbar aktive Ablehnung des Fortschritts vieler Jahre: Es gibt funktionierenden Code und (in anderen Projekten) bewährte Ansätze, aber es kommt im WordPress-Universum nicht und nicht zur Umsetzung. Das wird ja auch intern kritisiert.

Ein simples Beispiel liefert Brian Coords (Automattic), der in einer Reaktion auf EmDash anmerken muss, dass es bis heute kein User-Interface für Core-Funktionen wie “Custom Post Types” und “Custom Fields” gibt, auch wenn er sein Statement elegant unter Rückbezug auf KI seiner Bedeutungsschwere enthebt.

EmDash includes data modeling capabilities, custom content types and custom fields, directly in its core. Of course, so does WordPress. With only a few lines of PHP, you can register post types and post meta, and WordPress does a great job of handling storage, API endpoints, and routing for you. And because these features have been around so long, AI is already really good at setting it up. It’s PHP, not JSON configs, but I think it’s pretty solid. […] It’s good, but there’s no UI-based management in WordPress, which they’ve included in EmDash (in a UI that will feel very similar to anyone with an ACF license key). […] On the flip side, if you’re skilled enough to Claude Code yourself an Astro site, do you need a UI for it?

Brian Coords

Für diejenigen, die Post Types und Fields nicht ausschließlich per Code registrieren, gilt: Noch immer hängen wir an Drittanbieter-Plugins, die etwas ermöglichen ein User Interface für etwas anbieten, das lange schon zum Kern von WordPress gehört.

Gregory Schoppe hat das 2017, also vor knapp zehn Jahren, kommen sehen und auf das Problem des Gutenberg-Editors hingewiesen, mit dem falschen Datenmodell – oder eigentlich: mit gar keinem – zu arbeiten. Gregory Schoppe gibt ein paar Beispiele (hier massiv gekürzt), die wir nur allzu gut kennen.

Developers are saddled with 15 years of poor decisions with regard to the WordPress editor, and they just keep digging deeper with every iteration. Let’s consider a few:

• shortcodes – these were a hack to allow for inserting dynamic content into static posts. They use a non-standard format that is parsed out of HTML via regular expression
• flat HTML image storage – images are stored in the media library by ID, but stored in the post as HTML tags with src attributes. This means that deleting or updating an image that is used in many posts will not update the images themselves, leading to broken image resources.
• And now we add comment-based post structure – […] the core team has doubled down, and is creating a second structured data standard, based in HTML comments,that is, once again, parsed […] Rolling your own, to try to preserve back compatibility with unstructured posts is a horrible misstep. In a logically developed system, there would be a conversion step, from which point, all posts would be stored in logical, structured data.

These are all issues that are going to continue to hinder core developers again and again.

Gregory Schoppe

Schoppe schrieb das, als Gutenberg noch ein Plugin in der Entwicklung war. WordPress 5.0 mit dem Block-Editor als Standard erschien ein Jahr später, im Dezember 2018. Seitdem sind fast acht Jahre vergangen. Die Liste der Hilfskonstruktionen ist länger geworden, nicht kürzer.

Nun gibt es natürlich Gegenstimmen. Nicht, was die Eleganz und den technischen Fortschritt des Speicherns strukturierter Daten angeht, aber was die Notwendigkeit einer grundlegenden Änderung von WordPress angeht. Miriam Schwab, Head of WordPress at Elementor, meint, EmDash habe zwar architektonische Vorteile, aber für die Menschen, die Websites tatsächlich bauen und betreiben müssen, reiche Architektur allein nicht aus. Ohne Plugin-Ökosystem, ohne Community, ohne Themes, ohne Antworten auf häufige Fragen (in Form von Code-Snippets, Diskussionen, Best-Practices, Tutorials usw.) kann ein Content Management System auf Dauer nicht funktionieren.

If WordPress came along and […] showed us the EmDash experience, we’d be like um, why did you take away ALL THE THINGS? […] You can’t just architect your way into with decades of accumulated community work. […] WordPress has thousands of free themes [and] 60,000 plugins covering every imaginable use case […] When something breaks, there are forums, documentation, tutorials, and developers everywhere who know how to fix it. […] EmDash has none of that yet, and no architecture makes it appear faster. You can’t design your way to community. […] There’s also the infrastructure independence question. WordPress runs on almost anything — a $5/month shared host, a Raspberry Pi, a major cloud provider. […] EmDash’s serverless approach is geared towards Cloudflare’s own infrastructure […] That’s a vendor commitment that most WordPress users have never had to think about.

Miriam Schwab

Aber Schwab widerlegt das Datenmodell-Problem nirgendwo inhaltlich. Sie sagt nur: die meisten Nutzer merken es nicht. Das mag stimmen, ist aber eine andere Aussage. Und es ist genau die Haltung, die Gregory Schoppe 2017 beschrieben hat: lieber weiter flicken, als die Sache grundsätzlich anfassen. Das wäre aber auch riskant für das Produkt, das Miriam Schwab gewissermaßen vertritt: Elementor läuft auf rund einem Fünftel aller WordPress-Sites und das Geschäftsmodell des Page Builder-Ungetüms baut auf dem, was WordPress gegenwärtig ist, auf.

Aber was ist mit den Userinnen und Usern, die laut Joost ja Websites wollen, und keine CMS? Miriam Schwab dreht diesen Satz um und macht daraus ein Argument für WordPress: Endnutzer wollen einfach ihre Website bedienen, und dafür ist WordPress gut. Das stimmt zwar, umschifft die Frage, die ein System wie EmDash aber aufwirft, zur Gänze. Nur die allerwenigsten, die WordPress rein redaktionell nutzen, würden sich jemals fragen, ob sie lieber HTML-Kommentare oder JSON in der WordPress-Datenbank hätten. Ich vermute, die meisten würden beim Lesen dieses Satzes verunsichert fragen, was HTML sei, wieso man darin kommentieren könnte, was dieses JSON und seit wann WordPress eine Datenbank sei. Endnutzern ist das Speicherformat egal, solange alles funktioniert und stabil läuft.

Aber wenn es nicht mehr funktioniert, wenn Inhalte nicht mehr portierbar sind, wenn KI-Agenten die Struktur nicht lesen können, wenn jede neue Anforderung neue programmatische Hilfskonstruktionen erzwingt, dann zahlen diese Nutzerinnen und Nutzer am Ende die Rechnung. Nur merken sie es nicht sofort, und niemand erklärt es ihnen. Solange die Kosten “im Rahmen” sind, ist ja alles gut.

Ich habe nun über das Datenmodell und EmDash, Nutzerinnen und die Trägheit bzw. Affinität zu Hilfskonstruktionen bei WordPress gesprochen. Ist also EmDash der “spiritual successor to WordPress,” wie es im Cloudflare-Artikel charakterisiert wird? Meh, ich weiß nicht. Diese Beschreibung würde ich wenn überhaupt, dann eher bei Statamic oder anderen Content Management Systemen sehen, die aktiv mit der Intention an den Start gegangen sind, WordPress und sein dahinterliegendes Ökosystem zu erneuern; nicht bei einem System, das ein Best-Practice-Modell in Reinform vorzeigt.

Was man EmDash aber lassen muss: Es zeigt, wie ein CMS unter der Haube aussehen könnte, das von Anfang an richtig gedacht wurde. EmDash macht sichtbar, was WordPress seit fast zehn Jahren nicht tut, obwohl es könnte. WooCommerce hat bewiesen, dass eine grundlegende Datenmigration rückwärtskompatibel möglich ist ohne alles über Bord zu werfen. Das Argument, es gehe nicht (aus welchen Gründen auch immer), zieht nicht mehr und verliert an Glaubwürdigkeit.

Was bleibt, ist die Frage, warum es trotzdem nicht passiert; ob das Trägheit ist, technische Feigheit oder kalkuliertes Interesse eines Ökosystems, das bei einer echten Strukturreform zu viel zu verlieren hätte. Wir werden das von außen nur erraten, aber nicht abschließend beantworten können. Immerhin gehen viele der WordPress Core-Entwickler und Persönlichkeiten im WordPress-Ökosystem auf die Kritikpunkte ein, mit denen der EmDash-Artikel bei Cloudflare nicht spart. Brian Coords geht sie sogar systematisch durch und schließt jeden Abschnitt mit einem “Takeaway for WordPress”.

Geht man nun aber zwei Schritte zurück und wechselt in eine Makroebene, so ändert sich die Rolle von EmDash in der ganzen Sache plötzlich. Ist es nur ein CMS oder ist es eine Herausforderung an überkommene architektonische Glaubenssätze? Wer hier oder im WordPress-Space ein wenig mitgelesen hat, fragt sich nicht mehr nur, warum bei WordPress nichts passiert, sondern worauf EmDash eigentlich die Antwort ist. Und diese Frage wird von Tag zu Tag lauter.