WordPress 6.9 erst 2026 + Statement von Matt Mullenweg

Dieser Beitrag zeigt dir, wie es mit WordPress weitergeht, warum die Version 6.9 erst 2026 kommt sowie das neueste Statement von Matt Mullenweg zu den aktuellen Geschehnissen und meine eigenen Gefühle dazu.

Was ist passiert ?

Ich werde zunächst einmal die Fakten hier posten. Weil der Beitrag geht ja speziell um die nächste WordPress Major Version 6.9

WordPress 6.9

Nachdem WordPress 6.8 Mitte April 2025 veröffentlicht wurde, wurde bekannt gegeben, dass es die letzte Major Version für das Jahr 2025 sein wird.

Noch im November 2024 wurde der nächste Zyklus bis WordPress 7.0 im Jahr 2025 vorgestellt. Das alles ist jetzt Vergangenheit. Der Entschluss kam – zumindest für uns User – relativ unerwartet.

Ebenso, wenn man nicht so direkt am Laufenden blieb, auch nur sehr versteckt zu finden. Auch auf Google wirklich fast keine Einträge dazu.

Plötzlicher Entwicklungs Stopp

Nach nun Jahren mit drei Major Releases pro Jahr und einem wirklich atemberaubenden Tempo ist nun unerwartet eine längere Pause an Major Releases. Diese Pause wird wahrscheinlich bis 2027 andauern.

Neuer Release Zyklus 2026

👉 Der neue Release Zyklus sieht vor, das die nächste Major Version 6.9 im Jahr 2026 als Einzige ausgespielt wird.

Neuer Release Zyklus für 2027

Eher Ende 2027 wird dann die nächste WordPress Major Version 2027 veröffenlicht werden.

Minor Releases

👉 Die Minor Releases mit Bugfixes und Sicherheits Updates bleiben unverändert bestehen.

Gründe für die Verschiebungen der Release Zyklen

Die Ursachen und Gründe für diese Verschiebungen der Release Zyklen ist umfangreich und komplex.

-Ich möchte hier zunächst einmal das zusammenfassen, was veröffentlicht wurde.

– Danach schreibe ich meine eigene Einschätzung dazu.

-Und dann die Zusammenhänge, wie das auch mit dem Vorfall um wpengine zusammenhängt.

Die offiziellen Gründe für die Verschiebung

Auf make.wordpress.org ist ein ausführlicher Bericht, den ich hier zusammenfassen möchte.

Ca 30 Core Committer, Projekt Leiter und Mitglieder des Core Teams haben sich zusammengesetzt Ende März 2025 und haben den Veröffentlichung Zyklus der WordPress Versionen diskutiert.

Der Grund dafür war, das Unternehmen und Organisationen die Anzahl an Stunden zurückgefahren haben, an denen ihre Mitarbeiter aktiv an der Entwicklung des WordPress Core beteiligt waren.

Unter der Haube ..

Die Ursache dafür dürfte mit dem Eklat zwischen Automattic und wpengine zusammenhängen, der seit Herbst 2024 schwelt.

Nach dem öffentlichen Konflikt zwischen Automattic und WP Engine im Herbst 2024, in dessen Folge WP Engine von WordPress.org ausgeschlossen wurde, kam es zu spürbaren Veränderungen im Engagement vieler Unternehmen. Mehrere große Sponsoren wie Automattic, Newfold Digital (u.a. Yoast, Bluehost) und GoDaddy haben daraufhin die Anzahl der Stunden, die ihre Mitarbeiter*innen für die Mitarbeit am WordPress-Core zur Verfügung stellen, deutlich reduziert. Diese Entwicklung hatte auch Auswirkungen auf die Geschwindigkeit der Weiterentwicklung, was in der Community die Diskussion über eine mögliche Anpassung des Release-Zyklus ausgelöst hat.
Quelle: therespository

und weiter:

„Laut einer offiziellen Einschätzung auf make.wordpress.org, ist die Zahl der offenen Tickets in den letzten sechs Monaten nahezu gleich geblieben – was darauf hindeutet, dass sich in der aktiven Entwicklung nur wenig bewegt hat. Auch neue Funktionen im Gutenberg-Repository gehen stark zurück. Das legt nahe, dass die Beteiligung und Dynamik im Projekt deutlich nachgelassen hat.“
Quelle: make.wordpress.org

Zwischen den Zeilen ..

🤫 Das klingt auf den ersten Blick neutral – aber zwischen den Zeilen lässt sich auch lesen: Die Entwicklung steht still, weil weniger Menschen aktiv mitarbeiten. Ursachen werden nicht direkt genannt – aber der Rückgang von gesponserten Entwicklerstunden dürfte eine Rolle spielen.“

Das ist nun einmal der Zustand. Nun werden Lösungsvorschläge vorgebracht, sowohl positiv als auch negativ:

In der Diskussion wurden folgende Vorteile einer langsameren Release-Frequenz genannt:

– Sie bringt WordPress in Einklang mit dem Veröffentlichungsrhythmus großer Unternehmen wie eBay oder Airbnb.
– Sie könnte als Signal für einen bewussten Neustart und eine stärkere Qualitätsorientierung dienen.
– Sie ermöglicht mehr Konzentration auf sogenannte „kanonische Plugins“ und die Roadmaps einzelner Komponenten, die unabhängig von Hauptversionen weiterentwickelt werden können.
– Ein langsameres Tempo erlaubt bessere Dokumentation und Verbesserungen an der Infrastruktur.
– Größere Releases mit substanziellen Neuerungen statt reiner Bugfix-Versionen werden wahrscheinlicher.
– Der Koordinationsaufwand für Mitwirkende, Systemteams und Release-Leads sinkt.
– Gleichzeitig kann stärker an einer Automatisierung der Release-Prozesse gearbeitet werden, um zukünftige Versionen effizienter und weniger manuell auszuliefern.

Gleichzeitig wurden auch Risiken und Nachteile diskutiert:

– Weniger Releases bedeuten langsamere Feedbackschleifen für neue Funktionen.
– Es kann frustrierend für Mitwirkende sein, wenn ihre Arbeit länger nicht veröffentlicht wird oder weniger sichtbar ist.
– Veränderungen, die in mehreren Schritten eingeführt werden müssten, werden schwerer umzusetzen.
– Änderungen wie die Einführung neuer Coding-Standards können komplizierter werden, wenn sich Release-Branch und Hauptzweig zu stark auseinanderentwickeln.
– Größere Releases könnten bei Nutzern und Site-Betreibern Unsicherheit oder Ängste auslösen.
– Unternehmen, die Beiträge zum Projekt sponsern, könnten den Aufwand schwerer rechtfertigen.
– Eine langsamere Taktung kann als fehlender Fortschritt wahrgenommen werden und dem Projekt Dynamik nehmen.
– Das über Jahre aufgebaute Vertrauen in Auto-Updates darf nicht beschädigt werden – auch bei längeren Entwicklungszyklen.

Kurz zusammengefasst könnte man sagen, das verlängerte Release Zyklen folgende Vor und Nachteile haben :

Die Vorteile wären:

☑️ein bewusster Neustart mit Fokus auf mehr Qualität
☑️verbesserte Dokumentationen
☑️mehr Substanz bei Neuerungen statt nur Bugfix Versionen
☑️Fokus auf kanonische Plugins
☑️ weniger Koordinationsaufwand
☑️mehr Automatisierung

Die Nachteile wären:

⛔ Langsamere Feedback Schleife
⛔ frustrierende für Mitwirkende
⛔ Coding Standards könnten komplizierter werden
⛔ Unsicherheit oder Ängste
⛔ Fehlender Fortschritt

Vorgeschlagene Fokusbereiche

Im weiteren Verlauf der Diskussion wurde überlegt, worauf sich Mitwirkende im Projekt sinnvoll konzentrieren könnten, falls künftig nur noch ein großes Release pro Jahr erscheint.

Kanonische Plugins

👉 Von offizieller Seite gewartete Plugins, die als Erweiterung des WordPress-Kerns gelten – allerdings außerhalb des Core-Codes. Sind ein Weg, um neue Funktionen bereitzustellen und weiterzuentwickeln, ohne dabei auf größere WordPress Releases angewiesen zu sein :

Preferred Languages, 2FA (Zwei-Faktor-Authentifizierung)
Plugin Suite des Performance Teams

Die Plugin-Suite des Performance-Teams bei WordPress.org ist eine Sammlung von offiziell betreuten Plugins, die sich gezielt mit der Verbesserung der Website-Performance beschäftigen – also mit Dingen wie Ladezeit, Caching, Bildoptimierung oder Datenbankeffizienz.

Ein bekanntes Beispiel daraus ist:

Performance Lab
Dieses Plugin wird vom offiziellen Performance-Team entwickelt und enthält experimentelle Funktionen zur Leistungsverbesserung. Es dient als Testumgebung für neue Features, die später eventuell in den WordPress-Core integriert werden könnten.

Inhalt von Performance Lab (Stand heute, kann sich ändern):

Unterstützung für moderne Bildformate wie WebP
Optimierung von Lazy-Loading
Audit-Funktionen zur Leistungsmessung
Automatische Verbesserung von Konfigurationen

Wie macht man diese Plugins effektiver ?

1. Bessere Möglichkeiten zur Sammlung von Nutzerfeedback:
Derzeit steht als Kennzahl nur die Anzahl aktiver Installationen zur Verfügung – diese sagt aber wenig über den tatsächlichen Nutzen aus.
→ Nutzen User die Funktion überhaupt?
→ Wie genau verwenden sie sie?
→ Finden sie sie hilfreich?

Meist gibt es nur Rückmeldungen, wenn etwas nicht funktioniert. Man war sich einig, dass Telemetrie und andere Wege, aussagekräftige Feedback-Schleifen zu etablieren, geprüft werden sollten.

2. Mehr Sichtbarkeit:
Viele wissen gar nicht, dass es kanonische Plugins gibt oder dass sie offiziell betreut werden.
Daher sollen verschiedene Maßnahmen zur Bekanntmachung dieser Plugins geprüft werden, etwa:

Beiträge im WordPress.org-News-Blog
Erwähnungen in Präsentationen wie „State of the Word“
Nutzung der bislang leeren „Werkzeuge“-Seite im WordPress-Adminbereich

To-do-Liste ( Backlog )

-Das Abarbeiten des Backlogs ( der To do Liste ) von insgesamt etwa 13.000 Tickets auf Trac und im Gutenberg-GitHub-Repository kann unabhängig von größeren Releases erfolgen.

-Die Mehrheit der Fehlerbehebungen kann in kleineren Versionsupdates ausgeliefert werden.

-Die Statuslösung „maybelater“ („vielleicht später“) gibt es aus gutem Grund und sollte öfter verwendet werden.

-Über geschlossene Tickets kann die Diskussion jederzeit fortgesetzt werden.

-Ein großer Backlog ( lange To do Liste ) kann das Ansehen der Projektqualität und Wartbarkeit negativ beeinflussen.

-Alle Zahlen sind isoliert betrachtet nur Zahlen. Sie müssen immer im Zusammenhang mit weiteren Faktoren gesehen werden.

Ausdrücke konkret:

👉 Backlog wird meistens im Projekt- und Softwarekontext benutzt für alle offenen Aufgaben, Bugs, Features etc., die noch bearbeitet werden müssen.

👉 maybelater („vielleicht später“) – ist eine Kennzeichnung in Bug- oder Aufgaben-Tracking-Systemen wie Trac oder GitHub.
👉 Er bedeutet, dass ein bestimmtes Ticket, Problem oder Feature momentan nicht prioritär behandelt wird, aber auch nicht komplett verworfen ist. Man behält es im Auge, um es eventuell später nochmal aufzugreifen.

Verschiedenes

– Um eine breitere Beteiligung an der Testphase zu erreichen, sollen mehr Initiativen wie „Host Tests“ gestartet werden. Auch Entwickler sollen besser darüber informiert werden, warum es sinnvoll ist, regelmäßig Beta-Versionen oder sogenannte Nightly Builds zu testen.

Was sind Host Tests ?

„Host Tests“ im WordPress-Kontext sind automatisierte Tests, die auf verschiedenen Hosting-Umgebungen durchgeführt werden, um sicherzustellen, dass neue WordPress-Versionen stabil und kompatibel mit den gängigen Webhosting-Angeboten laufen.

Sie dienen dazu, Beta-Versionen oder sogenannte Release Candidates (RCs) von WordPress unter realen Bedingungen zu testen – also auf Servern mit unterschiedlichen PHP-Versionen, Datenbankkonfigurationen, Betriebssystemen und Einstellungen, wie sie bei Hosting-Anbietern üblich sind.

– Die technische Struktur der beiden Haupt-Repositories – dem Core-SVN (für WordPress Core) und dem Gutenberg-Repository auf GitHub – soll überdacht werden. Ziel ist es, den Veröffentlichungsprozess effizienter zu gestalten.

Was ist damit gemeint – für Laien erklärt

Veraltete Technik bremst den Prozess

👉 Ein weiteres Thema war die technische Organisation des WordPress-Codes: Der WordPress-Core wird traditionell über ein älteres System namens SVN verwaltet, während der Gutenberg-Editor auf GitHub weiterentwickelt wird – also mit einem moderneren System (Git).

👉 Diese Zweigleisigkeit macht den Veröffentlichungsprozess unnötig kompliziert. Änderungen müssen teilweise manuell zwischen den Systemen übertragen werden, was zeitaufwändig ist und zu Fehlern führen kann.

👉 Es wurde deshalb vorgeschlagen, zu prüfen, wie man diese beiden Systeme besser aufeinander abstimmen oder vielleicht sogar vereinheitlichen könnte. Ziel wäre ein effizienterer Ablauf, der auch neuen Mitwirkenden den Einstieg erleichtert.

– Da aktuell weniger neue Features im Gutenberg-Repository entwickelt werden, könnte es sinnvoll sein, die Veröffentlichungsfrequenz des Plugins auf einmal im Monat zu reduzieren. Der bisherige Rhythmus ist zwar weitgehend automatisiert und handhabbar, aber man will flexibel reagieren, wenn der Umfang kleiner wird.

– Die sogenannten „Release Squads“, also die Teams, die für WordPress-Releases zuständig sind, sollen künftig vor allem koordinieren. Gleichzeitig sollen einzelne Teams wie die Component Maintainer oder die Make WordPress-Teams mehr Verantwortung und Entscheidungsspielraum bekommen.

Was sind Component Mainainer ?

👍👉 In der WordPress-Community gibt es viele freiwillige Helfer, die sich um einzelne Bereiche des Systems kümmern – sogenannte „Component Maintainer“.
Eine Komponente ist zum Beispiel der Editor, die Medienverwaltung oder der Datenschutzbereich.
Die Maintainer prüfen neue Fehlerberichte und Vorschläge, geben Rückmeldung zu Code-Änderungen und helfen dabei, ihre Komponente in den nächsten WordPress-Versionen weiterzuentwickeln. Sie sind also eine Art „Fachverantwortliche“ für bestimmte Teile des WordPress-Kerns – ehrenamtlich, aber mit großem Einfluss.

– Ermutige die Verantwortlichen der Komponenten, aktiver zu sein, indem deren Aufgaben und Erwartungen als freiwillige Maintainer klarer definiert werden.

Was heisst das für Laien:

👉 Die sogenannten „Component Maintainer“ – also die Freiwilligen, die für einzelne Bereiche von WordPress zuständig sind – sollen stärker eingebunden werden. Dafür will man ihre Aufgaben und die Erwartungen an ihre Rolle klarer kommunizieren.

– Für Barrierefreiheit (Accessibility) sollten die Unterschiede zwischen verpflichtender Einhaltung (WCAG) und freiwilligen, nicht verpflichtenden Best Practices klarer gemacht werden.

– Erkunde schnellere Veröffentlichungsmodelle, sobald technische Schwachstellen bei den Werkzeugen behoben sind.

– Verbessere die Einbindung von Mitwirkenden mit nicht-technischen Fähigkeiten (z. B. Design, Testing, Produktmanagement) auf vielfältigere Weise.

Was heisst das alles ? Fazit :

So ich das herauslese, geht der Weg mit den kanonischen Plugins jetzt eine andere Richtung. Nämlich, weg von den vielen Major Versionen in zu einer Auslagerung von Neuerungen in externe kanonische Plugins.

Gleichzeitig will man diese mit Telemtrie testen.

👉 Was ist Telemetrie (englisch: telemetry) bedeutet in diesem Zusammenhang das automatische Sammeln von Daten darüber, wie Nutzer eine Software tatsächlich verwenden.

In WordPress oder bei Plugins heißt das zum Beispiel:

Welche Funktionen eines Plugins werden wie oft benutzt?
Welche Einstellungen nehmen Nutzer vor?
Gibt es Fehlermeldungen bei bestimmten Aktionen?
Welche Systemkonfigurationen (PHP-Version, Servertyp etc.) sind verbreitet?

Warum ist Telemetrie wichtig?

Telemetrie liefert echte Nutzungsdaten, statt nur grobe Zahlen wie „aktive Installationen“. Entwickler können damit besser verstehen:

Was funktioniert gut?
Was wird gar nicht verwendet?
Wo entstehen Fehler oder Probleme?
Welche Features lohnen sich weiterzuentwickeln?

Beispiel in WordPress:

Statt nur zu wissen, dass ein Plugin 100.000 Mal installiert ist, könnten die Entwickler sehen, dass 90 % der Nutzer nur eine einzige Funktion des Plugins verwenden. Oder dass eine bestimmte Einstellung regelmäßig zu Fehlern führt.

Datenschutz?

Weil Telemetrie oft sensible Daten berührt, muss sie transparent, anonymisiert und freiwillig sein – also:

Klare Kommunikation, welche Daten gesammelt werden ?

Nutzer müssen zustimmen (Opt-in)
Keine personenbezogenen Daten

Alles in allem, was ich da herauslese, ist, dass:

-wp engine nur der letzte Tropfen auf den heißen Stein war. Das da ziemlich viel unter der Haube schon war, dass viele gestört hat, ganz unabhängig von diesem Disput.

-dass das nun der Auslöser war, um vieles zu überdenken.
-ein weiterer Auslöser war natürlich, dass viele Unternehmen die Zahl der gesponserten Entwickler reduziert hat, und dass anscheinend wenig Interesse von Seiten der Anwender war, weil wenig bis gar keine neuen Tickets eingereicht wurden.

Meine persönliche Sicht auf WordPress

WordPress und die letzten 7 Jahre ..

Ich kann das nur aus meiner Sicht sagen. Seit 7 Jahren ist WordPress für Entwickler ein sich bewegendes Ziel. Es gibt viel weniger Plugin Entwickler, viele konnten ganz einfach früher ein neues Plugin erstellen, aber jetzt mit React und das alles ist das nicht mehr so einfach.

Viele kommen überhaupt nur mit Mühe mit dem Entwicklungs Tempo mit. Auch auf der anderen Seite sieht man, das an 13.000 offenen Tickets, dass auch die Core Leute mit dem aufarbeiten der Bugs gar nicht mitgekommen sind.

Gutenberg und das Full Site Editing hat sich von Anfang an nur schleppend entwickelt, bzw. wurde schlecht bis gar nicht von der breiten Community aufgenommen. Ich selber war bei den Early Adoptern dabei, ich habe das von Anfang an mit verfolgt.

Nicht einmal die Hard Core WordPresser aus der alten Gilde konnten sich begeistern. Da ich gewusst habe, wie es ausgehen wird, dachte ich mir, es ist besser gleich von Anfang an, dabei zu sein, wird leichter und genauso war es dann auch.

Und genauso ist es gekommen, viele da draußen, die einfach nur eine Website haben, sind immer noch beim Classic Editor. Die alten WordPresser haben sich dann natürlich umstimmen lassen und sind jetzt auch begeistert.

Das war so einmal der Grund Tenor der letzen Jahre in WordPress, noch ganz ohne wpengine.
Ich kann mich noch erinnern wie arg das war, wenn man geglaubt hat, man kennt sich endlich aus, und kurz darauf wurde alles wieder geändert.

Wie soll man unter solchen Umständen ein Block Theme an Kunden bringen ? Es war jahrelang einfach unmöglich. Viele Free Lancer die gute Entwickler waren, sind wieder zurück in ein Angestellten Verhältnis ? WARUM ?

Auch vor WordPress 6.8, der letzten und einzigen Major Version 2025 gab es im Website Editor so viele Neuerungen und Änderungen, dass einem Schwarz wurde. Wie soll man das an Kunden weitergeben ?

Und wie ich dass dann gelesen habe, dass es keine weiteren Major Versionen mehr gibt, war das zunächst ein Schock. Weil es irgendwie sich wie ein Loch angefühlt hat. Man war praktisch in einem Dauer Stress Zustand und dann plötzlich aus.

Und deswegen schreibe ich auch diesen Beitrag und ich habe ziemlich viel gelesen und recherchiert und auch die Meinungen der User gelesen. Es kommt heraus, dass sicherlich der Eklat mit wpengine eine große Rolle gespielt hat, weil Matt Mullenweg viele Leute abgezogen hat, und gesagt hat, wenn wpengine nix tut, dann ich auch nicht.

Das war dann so eine Reaktion, wo dann eben andere dasselbe gemacht haben. Mit dem Erfolg, dass es jetzt viel weniger gute Entwickler gibt, die da gesponsert werden an der Mitarbeit.

Und der zweite Punkt war, anscheind sind sehr sehr viel Interessierte auch echt müde geworden. Wozu soll man noch ein Ticket einreichen, wenn in einer Woche schon wieder das nächste Neue kommt. Es war wie auf der Jagd.

👉 Jo, und wpengine war nur mehr der letzte Auslöser, dass mal alles kracht.

So, der Gedankenstrich ist jetzt die stille leere Pause. 😂😂😂

Und jetzt ?

Es geht einfach weiter..

Ich habe das alls gebraucht, dieses Nachdenken und Recherchieren, dass ich aus dem Loch herauskomme und irgendwie für mich selber eine neue Motivation finde.

Und tatsächlich, wenn man den Bericht auf wordpress.org liest, den ich hier zusammengefasst und übersetzt habe, dann ist das alles so klein geschrieben, man denkt sich zuerst, was das ist alles ?

Und wenn man es dann genauer ansieht, steht da nämlich sehr sehr viel und sehr gute Sachen. Ich glaube jeder würde damit übereinstimmen und nur nicken dazu und sagen. – jo, genau so.

Ich möchte noch zum Abschluss das neueste Video von Matt Mullenweg hinzufügen. er sagt da etwas gutes wegen wpengine.

WordPress wird nur besser und stärker werden, in einem Jahr redet niemand mehr darüber und fragt vielleicht nur – was war das noch, wie hieß das gleich wp engine aaaaasshhhsooo..

Und was sollen wir einfachen .. Leute , Entwickler undso machen ?

😅Das eine Jahr genießen, alles wiederholen, neu machen, aufarbeiten, ein eigenes Block Theme entwicklen und so halt…

Es geht ja weiter ! Es ist nur etwas versteckt.

Wir waren verwöhnt, weil auf make.wordpress.org immer so schön Zusammenfassungen von den Gutenberg Neuerungen waren. Und dann 10 – 12 Gutenberg Versionen kam eine neue Major Version. Und man hatte 10 Gutenberg Versionen Zeit das alles sich anzusehen und nach zu lernen. Wenn dann die neue Major Version herauskam, hat man eh schon alles getestet und gewusst.

Und dann kam noch die tolle Zusammenfassung über die neue Major Version und jetzt ?

Jetzt gibt es daweil keine Ann McCarthy mehr die uns wie in der Schule aufschreibt, was wir testen sollen und die uns dann sagt, was wir weiter machen sollen. Das fehlt sehr sehr. Liebe Ann McCarthy du hast das so toll gemacht ! Danke !
👉 Using Create Block Theme Plugin

Neue Gutenberg Versionen ..

Wer aber weiter am Ball bleiben möchte, die Gutenberg Versionen gehen normal weiter, nur findet man sie nur mehr auf github. Und ! Leider muss man sich da jetzt selber durchquälen, – ja es gibt chatgpt, das wird uns schon helfen – aber es ist schon mühsam, das alles zu lesen, oder so.

Aber ich würde es empfehlen, weil sonst glaubt man tatsächlich eis ist nix mehr los.

In diesem Sinne, ist das jetzt ziemlich lang geworden, aber das habe ich selber gebraucht. Mir geht es jetzt besser. Und ich sage nur wie die Koreaner in den kdramsas – ok, Serien Junkie, aber ich lern auch Koreanisch ☝️ –

Fighting 😜😆😘

Hier noch der linkedin post dazu von Lenny Rachitsky

Textauszüge aus dem Podcast auf searchenginjournal.

Sehr berührendes Video zu den aktuellen Vorfällen rund um WordPress und seine Stellungname dazu wie es sich anfühlt “ the villain of the internet „ zu sein 😅

In einem Kommentar schreibt Mary Hubbard :

Great to see Matt speak to what many inside WordPress already know;
we stand for open source
we commit to it
and WordPress will continue to thrive

Irgendwie ist es beruhigend, das alles zu hören. Nach den Neuerungen, das nur mehr eine Major WordPress Version pro Jahr veröffentlicht wird, war es gut zu hören.

das alles weitergeht
das Matt Mullenweg wordpress.org niemals aufgeben wird
das WordPress “ healthy “ ist , auch nach allem Wirbel

Matt Mullenweg fasst kurz zusammen, was es mit dem Wirbel um WordPress und WP Engine auf sich hat, was deswegen schon wichtig ist, weil er sagt, das 80 % auf falschen Meldungen und Unwahrheiten beruhen und die 20 % im Internet, welche das richtig stellen gar nicht mehr die Reichweite bekommen. 😅😂

Quellen:

wpengine against matt mullenweg the repository

core commiters struggle..
Core committers warn of burnout and stalled progress on the Block Editor as Automattic slashes its contribution hours once again.

core commiters check in ..
Hier wird erklärt, warum es nur mehr eine WordPress Major Version pro Jahr gibt, und welche Änderungen Pros und Cons vorgeschlagen wurden. Siehe meinen Beitrag auf deutsch.

automattic scales back wordpress contributions ..

restructuring announcement -automattic.com

gutenbergtimes: gutenberg 20.9 und alle news zu WordPress

heise.de – nur ein WordPress Version 2025