Phase 3: Kollaboration als Hauptfokus
Die aktuelle Entwicklungsphase des Gutenberg-Projekts steht unter dem Thema Zusammenarbeit. WordPress 7.0 soll diese Phase abschließen und Echtzeit-Kollaboration in den Core bringen. Mehrere Personen sollen gleichzeitig an einem Dokument arbeiten können, sichtbar für alle Beteiligten in Echtzeit.
Das ist technisch kein einfaches Problem, und die Lösung erfordert erheblichen Entwicklungsaufwand. Die Frage ist nicht, ob das technisch interessant ist. Die Frage ist, ob es das ist, wofür dieser Aufwand hätte verwendet werden sollen.
Für wen ist Echtzeit-Kollaboration in WordPress 7.0 relevant?
Echtzeit-Kollaboration ist ein Feature, das in Tools wie Google Docs oder Notion seinen Platz hat. Redaktionelle Teams, die täglich gemeinsam an Inhalten arbeiten, haben diese Anforderung. Für sie stellt sich aber unmittelbar die nächste Frage: Warum sollten sie für kollaboratives Schreiben WordPress nutzen, wenn spezialisierte Tools diese Aufgabe seit Jahren besser und zuverlässiger erledigen?
Die realistische Zielgruppe für kollaboratives Schreiben direkt im WordPress-Editor ist überschaubar. Für die überwiegende Mehrheit der WordPress-Installationen, ob Unternehmenswebsites, Agenturen oder individuelle Projekte, ist dieses Feature bedeutungslos. Es löst kein Problem, das in der Praxis relevant ist.
Stattdessen sorgt es für Komplexität im Core, erhöht den Wartungsaufwand und bindet Entwicklungsressourcen, die anderswo dringender gebraucht würden.
Was in WordPress 7.0 fehlt
Custom Post Types und Options Pages gehören in den Core
Wer in WordPress strukturierte Inhalte jenseits von Posts und Pages verwalten möchte, braucht Custom Post Types. Wer Theme- oder Plugin-Einstellungen sauber ins Backend integrieren möchte, braucht Options Pages. Beides ist seit über einem Jahrzehnt Standardanforderung für jede professionelle WordPress-Installation.
Zwar ist beides mühselig über Custom Code realisierbar, aber eine intuitive UI um die Nutzung zugänglicher zu machen fehlt im Core.
Stattdessen bedient man sich bei Advanced Custom Fields, Meta Box, Pods oder anderen Drittanbieter-Plugins, um Funktionalität zu implementieren, die zum Grundrepertoire eines ernstzunehmenden CMS gehört. ACF Pro kostet ca. 49 US-Dollar jährlich. Wer ACF nicht kaufen möchte oder kann, greift zur kostenlosen Version mit reduzierten Möglichkeiten oder baut Custom Post Types und Options Pages manuell über register_post_type() und add_options_page() in der functions.php, was für Menschen ohne Programmierkentnisse keine Option ist.
Das ist kein kleines Versäumnis. Es ist eine strukturelle Schwäche des WordPress-Cores, die seit Jahren existiert und bei jeder Roadmap-Diskussion übergangen wird. Ein CMS, das sich selbst als Plattform für Unternehmen positionieren möchte, muss strukturierte Datenverwaltung als First-Party-Feature mitbringen. WordPress tut das nicht.
Rollen- und Rechtemanagement ist nicht für Enterprise-Anwednungen geeignet
Das WordPress-Rollensystem kennt fünf vordefinierte Rollen: Administrator, Redakteur, Autor, Mitarbeiter und Abonnent. Für einfache Blogs reicht das. Für Unternehmenswebsites reicht es nicht.
In der Praxis brauchen Unternehmen differenzierte Zugriffskontrollen: Wer darf welche Custom Post Types sehen? Wer darf Inhalte eines bestimmten Bereichs bearbeiten, aber nicht veröffentlichen? Wer darf Medien hochladen, aber keine Menüs ändern? Wer hat Lesezugriff auf bestimmte Seiten im Backend, aber keine Bearbeitungsrechte?
Diese Anforderungen sind in mittelständischen Unternehmen mit mehreren Redakteur:innen, einem Marketing-Team und einer IT-Abteilung vollkommen normal. WordPress beantwortet sie mit Drittanbieter-Plugins wie Members, User Role Editor oder PublishPress Capabilities. Alle drei haben ihre Daseinsberechtigung, weil der Core die Lücke nicht schließt.
Ein CMS, das für Unternehmen funktionieren soll, braucht granulares Rechtemanagement im Core.
Datenbankstruktur und Performance-Fundament
Die WordPress-Datenbankstruktur hat sich seit Jahren nicht grundlegend verändert. Die wp_postmeta-Tabelle, in der Custom Fields als Key-Value-Paare gespeichert werden, ist für einfache Anwendungsfälle ausreichend. Für komplexe Datenstrukturen mit vielen Custom Fields und großen Datenmengen ist sie ein Performance-Problem.
Wer Custom Post Types mit vielen ACF-Feldern betreibt und komplexe Queries schreibt, stößt an die Grenzen der Meta-Tabellen-Struktur. Die Lösung ist heute individuelles Datenbankdesign außerhalb der WordPress-Standardstruktur, was technisches Know-how erfordert und die Wartbarkeit erschwert.
Dazu kommt ein weiteres Versäumnis: WordPress hat keine native Unterstützung für Object Caching über Redis oder Memcached. Wer auf einer stark frequentierten Website Datenbankabfragen über einen persistenten Object Cache beschleunigen möchte, greift zu Plugins wie Redis Object Cache oder WP Redis. Beide funktionieren, setzen aber eine manuelle Konfiguration der wp-config.php und eine entsprechend konfigurierte Serverumgebung voraus.
Ein CMS mit Unternehmensanspruch würde Redis-Caching als dokumentierten, nativen Bestandteil der Plattform mitbringen, nicht als Plugin-Lösung. WordPress überlässt diese Entscheidung dem Marktplatz, obwohl Object Caching längst kein optionales Extra mehr ist, sondern Grundlage für performante Websites unter Last.
Das eigentliche Muster hinter der Roadmap
Die WordPress-Roadmap ist kein Zufall. Sie ist das Ergebnis einer strategischen Ausrichtung, die in den letzten Jahren immer deutlicher wird: WordPress versucht, mit Plattformen wie Wix, Squarespace und Jimdo zu konkurrieren. Der Fokus liegt auf Features, die Laien ansprechen, auf visuellen Editoren, die ohne technisches Wissen funktionieren, auf Echtzeit-Kollaboration, die im Marketing-Pitch glänzt, auf KI-Integration, die als Innovation verkauft werden kann.
Das ist eine legitime Geschäftsstrategie. Es ist aber keine Strategie, die im Interesse professioneller Webentwickler:innen liegt, die täglich mit WordPress arbeiten.
Wix und Squarespace sind Closed-Source-Plattformen mit festen Strukturen und begrenzten Erweiterungsmöglichkeiten. Sie funktionieren für einfache Websites und Nutzer:innen ohne technischen Hintergrund. Sie sind aber keine Plattformen, auf denen komplexe, skalierbare und langfristig wartbare Projekte entstehen. Wenn WordPress in diese Richtung wandert, verliert es genau das, was es für professionelle Entwickler:innen interessant gemacht hat: die Kombination aus Offenheit, Erweiterbarkeit und einer breiten Entwickler-Community.
Custom Post Types im Core, ein durchdachtes Rechtemanagement und eine skalierbare Datenbankarchitektur: Das sind keine glamourösen Features. Sie erzeugen keine Keynote-Momente auf WordCamps und helfen nicht dabei, Laien zu überzeugen, dass WordPress genauso einfach ist wie Squarespace. Aber sie wären das, was WordPress als ernsthafte Entwicklungsplattform stärken würde, anstatt es in einem Segment zu positionieren, in dem es strukturell im Nachteil ist.
Langfristig wäre meines Erachtens sogar eine klare Trennung sinnvoll. Eine Version oder Distribution von WordPress, die konsequent auf Laien und visuelle Bearbeitung ausgerichtet ist, und eine, die professionelle Entwickler:innen als primäre Zielgruppe ernst nimmt, mit den Core-Features, der Architektur und den Workflows, die komplexe Projekte tatsächlich brauchen. Ob das im Rahmen des bestehenden Projekts realisierbar ist oder eine eigenständige Initiative erfordern würde, ist offen. Aber die aktuelle Mischung, die versucht, beide Zielgruppen gleichzeitig zu bedienen, dient keiner davon wirklich gut.
Was das für den Einsatz in Projekten bedeutet
WordPress 7.0 wird kommen, und die Echtzeit-Kollaboration wird ein Feature sein, über das viele schreiben werden. Für die Mehrzahl der professionellen WordPress-Projekte wird es irrelevant sein.
Wer WordPress heute für ein skalierbares Projekt einsetzt, tut das nicht wegen der Core-Roadmap, sondern trotz ihrer Lücken. Gute WordPress-Architektur bedeutet, die Schwächen des Cores zu kennen, sie mit den richtigen Werkzeugen zu kompensieren und gleichzeitig sicherzustellen, dass das System langfristig wartbar bleibt, auch wenn sich Drittanbieter-Plugins verändern oder einstellen.
Wenn du ein WordPress-Projekt planst und wissen möchtest, wie eine saubere technische Grundlage trotz der beschriebenen Core-Einschränkungen aussieht, kannst du dich gerne bei mir melden.