#080: Wie weit ist Gutenberg in 2026? | m. Birgit Pauli-Haack

Gutenberg, oder das Projekt Gutenberg besser gesagt, wurde von vielen Leuten abgestempelt und dann nie wieder verwendet.

Also das komische Ding, was aus WordPress da entstanden ist.

Aber das ist, finde ich, sehr sehr schade, dass das der Fall ist, weil wenn du dich mal in Gutenberg oder in den Block-Editor reingelesen hast oder eingeübt hast, dann wirst du gemerkt haben, okay, da hat sich mega viel getan seit dem, wo es rausgekommen ist.

Es gibt dann auch viele andere Sachen, wie zum Beispiel den Website-Editor, wo man auch Header-Footer bearbeiten kann und das Ganze, also es hat sich wirklich, wirklich viel getan.

Und in dieser Episode wollen wir die Frage beantworten, ob Gutenberg, sag ich jetzt mal, umgangssprachlich reif genug ist in 2026 und was die Pain-Points sind, woran wird gearbeitet, was die Zukunft von Gutenberg bringt und genau das werden wir uns in dieser Podcast-Episode anschauen.

Herzlich Willkommen bei der 80. Episode der Dominik Liss Show.

Auf diesem Podcast gibt's WordPress und Business Talks.

Das heißt, wenn du WordPress in deinem Business verwendest, dann bist du hier genau richtig.

Weil in jeder Episode entpacken wir die Skills, Storys und Geheimnisse der besten Experten aus der WordPress-Branche und das Ziel des Podcasts ist dir dabei zu helfen, ein besserer Professional in der WordPress-Welt zu werden.

Und heute haben wir einen ganz, ganz besonderen Gast und heute reden wir mit Birgit Pauli-Haack.

Und falls du die Birgit noch nicht kennst, also dann würd's mich ein bisschen wundern, aber wenn du nicht so im Gutenberg-Thema unterwegs bist oder im WordPress-Core-Thema, dann kann es schon sein, dass die Birgit für dich eine neue Person ist.

Aber Birgit ist die Herausgeberin von Gutenberg Times, sie ist Co-Host von Gutenberg Changelog, von dem Podcast, sie ist Core-Kontributerin, Developer Advocate für Automattic und davor hat sie 20 Jahre lang in den USA eine Agentur gegründet, geleitet und ist dann glaube ich schon seit Ewigkeiten in dem WordPress-Ökosystem dabei.

Deswegen freue ich mich sehr, dass wir heute mit Birgit darüber sprechen können, weil Wie gesagt, im Intro habe ich schon erwähnt, worüber wir sprechen werden.

Aber Birgit, herzlich willkommen.

Freut mich sehr, dass du da bist.

Könntest du dich bitte auch gut selbst vorstellen, den Leuten kurz Hallo sagen und dann werden wir gleich ins Thema eintauchen.

Vielen Dank für diese Einleitung und willkommen alle, dass ich hier sein darf und dass du mich eingeladen hast.

Es wird wirklich interessant sein.

Die Gutenberg Times hat angefangen im 2018. Das war auch das Jahr, in dem dann im Dezember der neue Block-Editor in WordPress kam.

Und das ist jetzt, sage und schreibe, fast genau auf das Datum acht Jahre her.

Und da hat sich natürlich sehr viel getan.

Also gerade von deiner Einleitung her.

Für jemand, der den Block-Editor.

.

.

Ich kenne Leute, die können mit dem Block-Editor nichts anfangen, immer noch.

Die vermeiden das, aber es gibt sehr viele Millionen von Leuten, die das sehr viel lieber haben als den anderen.

Diese weiße Box TinyMCE und jetzt mit dem Site-Editor, der jetzt seit gut drei Jahren sich eingearbeitet hat, also an dem gearbeitet wurde, also schon ziemlich gut entwickelt hat.

Aber vielleicht kommen ja auch irgendwie zu konkreteren Fragen und dass wir dann das Ganze so ein bisschen aufdröseln.

Genau, weil so eine ähnliche Podcast-Episode haben wir schon, ich glaube, vor eineinhalb Jahren aufgenommen mit Peter Müller und die kann ich auch nur empfehlen.

Da sind wir mehr darauf eingegangen, wie es eigentlich dazu gekommen ist, was so die Entwicklungsgeschichte von WordPress ist zum Teil und wie dann die Entwicklung von dem Block-Editor und dem Projekt Gutenberg eben zustande gekommen ist und wie sich das entwickelt hat.

Und da haben wir die Frage beantwortet, ist Gutenberg reif genug? In 2024 war das, glaube ich.

Und das würde ich gerne wiederholen, weil dann haben wir einen guten Kontrast zu dem, wie sich das alles entwickelt oder was sich tut und ob dann die Leute sich damit näher beschäftigen sollten schon langsam oder sagen, hey, okay, das ist für meinen Fall auch nicht so wirklich ein Thema und dann lasse ich das lieber und schaue mal, wie sich das in Zukunft entwickeln wird.

Und nebenbei werden wir dann auch ein paar Begriffe aufschlüsseln, weil die werden dann auch quasi ineinander irgendwie vernetzt, verwickelt, verwendet.

Es gibt nämlich den Begriff Gutenberg, es gibt Block-Editor, es gibt Website-Editor, Es gibt Full Site Editing, ist der Begriff noch aktuell oder nicht, und können wir da vielleicht mal so einen Einstieg machen, also allgemein, was ist das Projekt Gutenberg, was bedeuten die einzelnen Wörter und aus was besteht dieses Projekt, weil wenn man so dieses große Vogel, wenn man so dieses Bild von der Vogelperspektive hat, was das Projekt ist, aus was es besteht und was die einzelnen Begriffe sind, dann können wir glaube ich, das Gespräch viel besser weiter voranführen, um dann wirklich in die Feinheiten einzutauchen.

Ja, gerne.

Also Gutenberg ist das Projekt des Block-Editors und der wird eben, und das ist aber der Block-Editor in Entwicklung.

Da gibt es also ein Gutenberg-Plugin und das ist sozusagen die Vorstufe, wo alles entwickelt wird, bevor es dann irgendwann in eine Hauptversion von WordPress mit integriert wird.

Und das war im Endeffekt die Beta-Version, die große Beta-Version von einem Block-Editor, wie er dann irgendwann in der WordPress-Software komplett dann aufgeht.

Das ist ein GitHub-Repo, Und das ist das Plugin.

Und das Plugin wird jeden, alle zwei Wochen kommt eine neue Version raus, wo man, also wenn man das installiert, dann kann man diese neuen Funktionen, die neuen Interfaces eben schon mal ausprobieren und testen und dementsprechend dann auch Feedback liefern zurück an den Issues an Gutenberg oder eben im Slack dann auch mal Fragen stellen und beantworten, zu sagen, okay, habe ich das jetzt richtig verstanden oder ist das ein Bug oder wie auch immer.

Das ist also die Gutenberg-Entwicklung.

Der Gutenberg-Editor, der Name ändert sich sofort, wenn man über den Block-Editor in WordPress redet.

Das ist jetzt im Endeffekt der Block-Editor.

Der Site-Editor ist der Editor und der Block-Editor ist sozusagen der Oberbegriff und dann gibt es den Post-Page-Editor und den Site-Editor und das kommt aus den verschiedenen Phasen von dem Gutenberg-Projekt.

Der Site-Editor, Template-Editor, das ist alles eins.

Und der Post-Editor ist also nur für die Inhalte von Beiträgen.

Der war, das war das erste, war die erste Version von dem Block-Editor.

Und der ist, man will das eben jetzt auch, dass die Editoren alle gleich sind, dann auch zusammenfassen.

Das ist dann eben auch schon passiert.

Das ist im Endeffekt der gleiche Interface, der in einem Post-Editor ist, auch im Site-Editor, nur mit verschiedenen zusätzlichen Funktionen.

Das heißt also, wenn man jetzt von WordPress redet und dem blockbasierten Content-Erstellungsmechanismus, den das Interface anschaut, das ist der Block-Editor.

Full-Site-Editing war lange Zeit, ich glaube für zwei Jahre oder so, der Begriff, der jetzt im Endeffekt nur noch der Site-Editor ist.

Weil das ist das, wo du die Template-Parts ändern kannst, wo du Templates ändern kannst oder erstellen kann man, wo man dann auch Pattern mit einbauen kann in die Templates oder in die Pages.

Das ist also dann, man sieht das ganz gut bei den Pages.

Den kann man ja zweifach, das ist ein bisschen unglücklich, aber da gibt es ja diesen über den normalen Admin kann man die Seiten anwählen zum Editieren oder man kann die über den Seite-Editor machen.

Das ist ein bisschen doppelt gemoppelt, aber das ist glaube ich ganz gut, weil das nämlich die Entwicklung ist, wie der Admin dann irgendwann später mal ausschauen wird, wenn alles umgestellt ist, ja.

Also so grob zusammengefasst, ich werde da jetzt ein paar Begriffe aus dem Gespräch mit Peter von damals weiterverwenden, weil die einfach ziemlich gut passen.

Die Episode werde ich natürlich unten verlinken, aber zusammenfassend kann man sagen, WordPress ist gerade in so einem Blockifizierungsprozess, dass zuerst halt der Editor durch den Block-Editor ersetzt wurde, dann der Widget-Bereich wurde durch Blocks ersetzt, mittlerweile haben wir auch den Site-Editor, der dann auch in die Richtung geht, hey, modernes WordPress und mehr im Projekt Gutenberg ist als jetzt in dem altmodischen WordPress-Layout und im Endeffekt soll ja dann ganz WordPress so diesen, ich sag jetzt mal, den Blockifizierungsstil dann haben, also inklusive Admin-Interface, inklusive alles was du jetzt gerade kennst von WordPress, so wie ich das verstanden habe, also bitte korrigier mich da, da kann man gerne auch in diese vier Phasen von dem Projekt Gutenberg eingehen, was das genau bedeutet, wo sind wir gerade und was ist so das Endziel von dem Projekt Gutenberg? Oder was ist das, was man damit erzählen will? Weil man will ja nicht nur Verwirrung stiften und die Leute zu etwas Neuem überzeugen, was sie vielleicht nicht so mögen, aber das hat ja auch ein größeres Ziel, wieso das überhaupt angefangen wurde.

Ja, das große Ziel ist natürlich sehr viel Kontrolle an den Seitenbesitzer zu geben, was seine Seiten angeht.

Nicht nur wegen der Beiträge, sondern eben auch Template und Theme-Modifikationen.

Auch, dass man den Bereich, wer denn nun jetzt Themen bauen kann, auch weitermacht, weil man kann das über den Site-Editor schon ziemlich weit bringen, dass man eben das von einem Ausgang-Theme dann die Templates erstellt, innerhalb des Site-Editors und die Global-Styles, also die und über die site-spezifischen Design-Elemente halt dann auch über den Site-Editor festmacht, ohne dass man eben jetzt tatsächlich einen Entwickler braucht, um eben Archiv-Seiten zu gestalten und solche Dinge.

Man will da also sehr viel mehr Kontrolle zu dem Site-Owner oder zu dem Content-Creator bringen.

Das ist auch etwas, was die Leute, viele Leute auch wollen.

Ja, die wollen nicht wegen jedem, dass sie jetzt den Namen oder das Datum von dem Archiv-Post rausnehmen müssen, einen Developer anrufen, der das dann für den macht das ist eigentlich und der man hat auch viele shortcodes gab es beim bei dem anderen editor von den plugins ja und das ist natürlich auch user spezifisch ein bisschen schwierig zu handeln weil man in dem editor überhaupt nicht sieht wie es eigentlich nachher ausschaut das will man eben auch hat man eben auch jetzt geschafft dass das wenn man jetzt in dem editor drin ist dass man genau sieht wie das dann demnächst ausschaut wenn es veröffentlicht wird.

Und jetzt mit der neuen Template View geht es eben noch besser, weil man es dann im Kontext von der gesamten Seite sehen könnte, wenn man wollte.

Da sind also sehr viele Funktionen jetzt im Editor, die vorher nur für Developer zugänglich waren.

Und das öffnet das Ganze natürlich für sehr viel mehr Leute, weil das eben viel besser ist.

Ja, und das, ja, wolltest du noch was dazu sagen? Ja, ich wollte, dass die vier Stufen von Gutenberg, die vier Phasen, das hat der Matt Mullenweg auch Anfang schon gesagt, in 2018, als es neu kam, dass wir also erstmal den Editor anschauen, der nur für die Beiträge ist, nur für die Posts und Pages und dass der Rest weiter in dem normalen Theme hantiert wird.

Die zweite Phase ist eben dieser Site-Editor, das wurde also 2020 ungefähr eingeleitet mit der Entwicklung von einem Post-Editor und dem Site-Editor.

Das ist immer noch dran.

Aber wir haben eben jetzt schon angefangen mit der dritten Phase.

Das ist die Zusammenarbeit mit mehreren Leuten an einem Post, an einer Seite, dass man eben gleichzeitig, wie eben in Google Docs, in Google Dokumenten zum Beispiel, Kommentare machen kann oder gleichzeitig auch schreiben kann oder die Inhalte verändern kann.

Das ist die dritte Phase und die Phase wird dann Mehrsprachigkeit von WordPress Core sein.

Und dass das so weit hinten ist, das ist für viele, weil sie eben jetzt schon den Bedarf haben für die Mehrsprachigkeit.

Aber wenn man jetzt die erste Phase, zweite Phase und dritte Phase nimmt, das sind sehr viele, das ist alles die Basis, die ja dann hinterher in der Mehrsprachigkeit funktionieren soll.

Also wenn man die Basis noch nicht weiß, wie das funktioniert, tut man sich mit der Mehrsprachigkeit ein bisschen schwerer, das Ganze noch mal zu scalen, im Endeffekt größer zu machen mit eben mal den vielen Sprachen.

So, das ist das Projekt insgesamt.

Wir sind jetzt, das dauert alles immer länger als man denkt, aber wir sind eigentlich schon ziemlich gut und das ist eigentlich glaube ich, dass was im nächsten Jahr kommen wird, ist eben die immer noch Verbesserung vom Site-Editor.

Da sind noch ein paar Sachen dabei, wo ich oder jeder hat immer wieder mal Sachen, die man sagt, ich wünschte das würde funktionieren, aber dass man eben auch die, dass man nicht nur die kommen, also was jetzt in 6.9 kommt, sind die Kommentare, die Blockbasierten Kommentare innerhalb der Editoren.

Das ist eigentlich schon ziemlich weit gereift und im nächsten Jahr, weiß nicht, 7.0 oder 7.1, wird dann auch die gleichzeitig, dass mehrere Leute an den Block, an den Blgpost gleichzeitig arbeiten können.

Und der eine oben, der andere unten oder ja, dass sie sich nicht in die Quere kommen.

Im Moment ist ja immer noch so, nur einer hat eigentlich Zugang zu dem Blogpost.

Ja und da ist finde ich so, dass WordPress sich gefühlt halt irgendein Übel aussuchen muss, weil es ist halt so stark verbreitet auf so vielen Webseiten, auf so vielen Websites ist es im Einsatz, dass wenn man dann zum Beispiel das schnell entwickeln will, dann sorgt man bei vielen Leuten vor Aufregung, weil dann einfach Sachen brechen, Bugs entstehen und so weiter.

Aber wenn man das die langsame Entwicklung angeht, dann sorgt man ebenfalls vor Aufregung bei den Leuten, weil eben so langsam was voreingeht.

Und da gibt's eigentlich keine gute Lösung.

Und ich find's eigentlich super, dass das wie WordPress das macht, auch wenn es jetzt ein bisschen länger dauert.

Aber dafür brechen die Websites nicht zusammen.

Es gibt Backwards-Compatibility da, wo es Sinn macht und da, wo es keinen Sinn macht natürlich nicht, weil ich meine für den MCE braucht man jetzt keine Blöcke irgendwie Backwards-Compatible machen oder was auch immer.

Aber deswegen, ja, deswegen finde ich es auch viel von dieser, ich sage jetzt mal, negativen Aura um das Projekt Gutenberg herum, weil Leute, die da nicht so irgendwie involviert sind oder das große und ganze nicht sehen, die vergleichen das dann natürlich mit, keine Ahnung, anderen Softwarelösungen, wo wirklich schnell was vorangeht, viele neue Tools und so weiter.

Aber alleine dadurch, dass Projekt Gutenberg, das ist so eine immense, ich mag jetzt nicht sagen so Sisyphus-Arbeit oder Herkules-Aufgabe, was, wie man auch immer das benennen will, dass mich es überhaupt wundert, dass das Projekt gestartet ist, weil das ist ja ein Projekt, was über eine Dekade wahrscheinlich laufen wird und es dann jetzt irgendwann fertig sein wird und einfach da das zu starten, das finde ich eine mega große Aufgabe und mega großen Respekt für alle, die da jetzt da seit Anfang an Beteiligten sind, die jetzt da contributen, die da mitentwickeln und so weiter, weil es ist einfach eine enorme Aufgabe und das wollte ich mal so in den Raum stellen, damit man dann nicht immer sagt so, ah Gutenberg, das ist das Ding, was so langsam sich entwickelt oder was ich nicht verstehe oder mich damit nicht beschäftigen will, weil ich brauche Tempo, ich brauche meine Websites, ich muss die schnell entwickeln, ich brauche ein fertiges System und so weiter.

Und da wollte ich das vielleicht noch kurz anhängen, damit man da einfach ein besseres Verständnis dazu hat.

Ich kann dann auch ein bisschen dagegen setzen.

Ich habe also jetzt gerade in München ein Meetup wieder besucht und da waren eben mehrere Designer dabei, die also eine Agentur haben, auch lange Zeit Agenturen schon in der Agentur leben sind sozusagen und immer mit Kunden arbeiten und die sagen, wir haben also jetzt komplett umgestellt auf Block-Themes, weil die erstens schneller sind, werden wir auch schneller zum Erfolg kommen.

Die Kunden mögen es, weil sie eben wirklich Kontrolle haben und ich meine, das Autofahren lernt man ja auch nicht ganz einfach ohne Unterricht.

ich meine, man muss ein bisschen Training brauchen man schon für alle Dinge und die sagen, wir können eigentlich das, was wir nicht mit dem Editor machen können, können wir eben mit theme.

json machen oder wenn es gar nicht anders geht mit CSS.

Da ist die langjährige Erfahrung natürlich da von anderen Webseitensystemen, aber die sind also sehr happy damit, dass sie umgestellt haben, weil sie eben dann einfach wissen, Das wird weiterentwickelt.

Das wird auch weiterentwickelt, dass meine Seiten nicht brechen, oder zumindestens ist das der Anspruch.

Und WordPress wird es immer geben.

Ob das Plugin, das ich jetzt gerade benutze, nach vier Jahren noch weiter gibt, das weiß man nicht.

ich meine, da sind ein paar dabei, wie Elementor oder Beaver Builder, die haben jahrelang, waren die WordPress voraus.

Einfach deswegen mit dem What you see is what you get Editor.

Aber das sind jetzt auch alte Systeme.

Ich meine, die waren 2014, 2015 sind die rausgekommen.

Aber was eben der gute, der Teil davon war, was also bei WordPress nicht ist oder was wir als Developer Advocates eigentlich auch versuchen die Lücke zu füllen, ist, dass da auch zufällig sehr viel mehr Tools da sind, um eben einen Side-Builder zu unterstützen in Workflow.

Und da sind wir eben auch dran.

Da gibt es jetzt zum Beispiel das Create-Block-Theme-Plugin gibt es, wo man eben die Dinge, die im Editor sind und wenn man die Templates im Editor editiert, wird das alles in der Datenbank gespeichert und dann kann man das natürlich ganz schwer umziehen.

Auf eine andere Seite und das Create Block Theme Plugin erfüllt diese Lücke, sagt, okay, wenn Sie jetzt die Templates ändern, das wird alles runter kopiert in die Dateistruktur und dann kann das eben immer wiederverwendet werden.

Und das ist eigentlich in diesem Tooling ist also viel dabei, wo man dann sagt, okay, dann wollen wir eben den Zeitbildern auch helfen, diese Brücke zu schließen.

Da hast du ein wichtiges Thema angesprochen, weil WordPress wurde in der Vergangenheit ja mega oft einfach nur als Fahrgestell verwendet und darauf wurden dann Pagebuilder, Plugins drauf gebaut, wie zum Beispiel eben jetzt Bricks, Elementor, Beaver Builder, früher WPBakery und so weiter, damit wir da jetzt ein paar genannt haben.

Aber den Aha-Moment, den ich für Gutenberg für mich persönlich gehabt habe, der war schon vor vielen, vielen Jahren, wo ich den Benefit von den Blocks gemerkt habe, also da war ich schon sold, okay, passt, das ist die Zukunft, ich bin dabei und das freut mich, dass es sich in die Richtung weiterentwickelt, aber der Aha-Moment, der ist bei vielen Leuten woanders, weil wenn du zum Beispiel nicht programmieren kannst oder keine CSS-Kenntnisse hast, dann kann ich nachvollziehen, wieso die Frustrationen am Anfang entstanden sind, weil Gutenberg und weil Block-Editor und so weiter.

Mittlerweile habe ich mir dann irgendwann, das war glaube ich vor eineinhalb Jahren, die Challenge gemacht, eine Website zu bauen, ohne Page-Builder und ohne zu programmieren, ohne Third-Party-Themes, sondern nur mit dem Block-Editor, mit einem Block-Theme und mit dem Standard-Block-Theme war das, glaube ich, sogar und fertig.

Und das hat funktioniert.

Und das war für mich dann dieses Gefühl so, hey, das ist ein komplettes natives System, wo man jetzt eine komplette Website bauen kann, also inklusive Header, Footer, Page-Templates und so weiter.

Klar hat das noch die eigenen Tücken und Lücken, wo man dann ein bisschen dann Geduld haben muss und ein bisschen nach Lösungen suchen muss.

Aber alleine, dass das möglich ist, finde ich das schon ziemlich cool.

Und du hast ja dann noch diesen Artikel geschrieben Is it time to dump your pagebuilder? Noch nicht.

Ich habe den Artikel noch nicht veröffentlicht.

Dürfen wir darüber reden oder nicht? Können wir, ja natürlich.

Ich meine, das hatte mehrere.

.

.

Einfach ich bin dann durch die Werbung von den anderen Pagebuildern durchgegangen hat.

Da hat irgendjemand, ich weiß nicht mehr wer, aber im Artikel habe ich es festgehalten, hat einen schönen Überblick über alle Page-Bilder gemacht, ich glaube acht oder so, und hat dann ausgefüllt, welche Tools da da sind.

Und da habe ich dann gemerkt, dass sehr viele Tools tatsächlich schon im Block-Editor drin sind.

Ob das nur die die seitweiten Stilrichtungen sind oder die Variations, wie man so schön sagt, die Style Variations, oder die Templates oder Patterns, solche Dinge sind ja alle schon im Block Editor verfügbar und jetzt auch sehr viel leichter in einem Block-Theme mit einzubauen und dann eben auch automatisch im Interface des Editors dann zu sehen Ja, wie man jetzt sagt, zum Beispiel, ich habe verschiedene Vorlagen, Patterns heißen Vorlagen in Deutsch, für bestimmte Seiten, ja, die man, und da gibt es dann ein Model, wo man die dann aussuchen kann.

Und das ist natürlich unheimlich klasse.

Und da kann jeder Theme-Builder eben, ja, denn diese Pattern dieses Modell auffüllen, also nicht nur die Pattern im Inserter und solche Dinge.

Bin ich eigentlich begeistert davon, dass das jetzt alles möglich ist, weil ich war, wie du, auch Block-based.

Block-basierende Editoren gab es ja, bevor WordPress angefangen hat damit, ja, die gab es ja in Mailchimp, die gab es bei Adobe, die gab es bei Canva, ja, also diese Idee war ja eigentlich schon lange im Web-Development-Bereich, bis dann WordPress das aufgenommen haben.

Und ja, das war auf jeden Fall ein mutiger Zug gewesen, aber natürlich auch ein notwendiger.

Also das Core-Contributors haben lange Zeit überlegt, wie sie denn jetzt ein Editor modernisieren können und ich fand also die Vision, dass das als ein Block basiert, in 2017 war ja WordCamp Europe und da war das erste Mal ein Demo-Video von einem Block-Editor zu sehen und das war eigentlich der Punkt für mich, wo ich gesagt habe, Mensch ja, das wird die Zukunft werden und ich bin also jetzt froh, dass das jetzt soweit ist.

Ich habe dann auch in meiner Agentur, also in 2018 schon angefangen, Webseiten mit dem Block Editor zu bauen.

Man konnte ja dann schon die Farben in den functions.

php, die Farben schon regulieren, dass also nicht die Custom-Farben, sondern nur die Standard-Farben von einem Brand mit reinkommen.

Und das war eigentlich so der Punkt, wo ich gesagt habe, also jetzt kann ich mit anderen Webseiten damit arbeiten, weil die Editoren dann die richtigen Farben benutzen und nicht alles kaputt machen, so ungefähr.

Und die Seiten, also ein Projekt hatte bestimmt 15 Editoren, die Events hatten, die Events-Planer waren, die haben Seiten erstellt, die haben Beiträge geschrieben und die sind mit dem Block-Editor sofort, ohne Training, wirklich unheimlich gut zurechtgekommen und hatten das Gefühl, dass sie endlich mehr wissen.

die haben also nicht dieses jetzt mache ich das und wie schaut es denn aus.

Helen Hussan, die sagt immer safe and pray.

Das sichere ich jetzt und dann schaue ich mal, wie es ausschaut, dass dieser Schritt im Workflow dann einfach wegfällt.

Jetzt bin ich aber ein bisschen außerhalb deiner Fragestellung, glaube ich, gekommen.

Jetzt bin ich mir nicht mehr sicher.

Ja, also quasi, wenn sie jetzt irgendwie überlegt, okay, ich entwickle jetzt viele WordPress-Projekte mit Webseiten, also viele Websites, mit Hilfe von WordPress.

Normalerweise verwende ich da immer einen Page-Builder, weil in einer Agentur standardisierte Prozesse und so weiter einfach entweder teilweise das Überleben definieren einer Agentur oder nicht, ist jetzt die Zeit langsam gekommen, dass man sich Gedanken machen sollte, als Agentur jetzt zu dem Block-Editor, zu dem Website-Editor zu switchen.

Und wenn nicht, was sind dann so diese Fragen, die man sich stellen sollte, um halt das für sich selbst herauszufinden? Kurze Unterbrechung in eigener Sache, weil falls ihr die Podcast-Episode, der du jetzt gerade zuschaust oder zuhörst, gefällt und du keine andere Podcast-Episode mehr verpassen möchtest, weil mit den Algorithmen weiß man ja nie, manchmal spielen die einem ein Video aus und manchmal verschwindet das im Internet-Ether, dann würde ich dich herzlichst zu dem WP-Office Newsletter einladen, weil in dem WP-Office Newsletter bekommst du Recaps aus den letzten Wochen und da gibt's Zusammenfassungen von den letzten Podcast-Episoden, Livestreams, Tutorials und Vlogs und ich verspreche dir eine totale Unregelmäßigkeit, weil ich bin kein Roboter, ich werde maximal eine E-Mail im Monat verschicken, wenn nicht weniger, aber dafür ist es alles schön kompakt in einer E-Mail zusammengefasst und dadurch wirst du natürlich die weiteren mega interessanten Podcast Episoden in den Postfach bekommen und keine weitere Episode verpassen.

Falls du aber nicht so oft von mir hören möchtest, aber mich trotzdem unterstützen möchtest, dann wäre ich dir extrem dankbar, wenn du den Podcast in deiner Podcast-App deiner Wahl bewerten könntest, wenn du mir so ein Review abgeben könntest.

Ich weiß, bei manchen Podcast-Apps ist es ziemlich versteckt, aber das wird mir enorm viel weiterhelfen, um einfach neue Leute zu erreichen.

Und wenn du jetzt zum Beispiel zuschaust auf YouTube und nicht den Podcast hörst, dann hinterlass bitte einen Like, einen Kommentar und das wird mir um Welten weiterhelfen.

Den Link findest du natürlich unten in der Beschreibung.

Vielen Dank dafür und jetzt geht's weiter mit der Podcast-Episode.

Also das Beste ist, was ich für mich festgestellt habe, und ich meine, jeder ist da anders, aber wenn ich einmal anfange, dann komme ich dazu.

Was sind die Aufgaben, die ich machen muss? Kann ich das mit dem Block-Editor machen? Man muss natürlich dann schon ein bisschen einkalkulieren, dass es ein bisschen länger dauert, weil man natürlich das Ganze lernen muss.

man weiß nicht, wo die ganzen Dinge versteckt sind.

Und da muss man sich dann schon ein bisschen an die Hand nehmen und sagen, okay, ich muss jetzt ein vieles verlernen, bevor ich was Neues lernen kann, weil das System irgendwie anders ist.

Wenn ich also mit einem alten System versuche, das Gleiche zu machen, wird wahrscheinlich das ein bisschen frustrierend sein.

Das heißt, ein bisschen mehr studieren, was das theme.

json macht, ja, wie viel man da machen kann.

Man kann dann auch für jede, für viele Sachen gibt es Tutorials, die also auf dem Developer-Blog auf WordPress da sind.

Da hat das Justin Tadler, der ja ein Theme-Guru ist, sozusagen, ja, ganz viele Tutorials geschrieben.

Und die Developer, der Ryan, der Nick und der Juan die haben eben auch mehr Development Sachen mit reingemacht.

Aber das sind so die Dinge, dass man sagt, okay, nicht die eigene Webseite nehmen, weil meine, also wenn ich eine Webseite mache, die meine eigene ist, das ist immer hinten dran.

Ja, mal so ein einfaches Projekt für ein Kundenprojekt und dann mal anfangen.

Das ist, glaube ich, der beste Rat, den man da geben kann, weil nämlich dann alles andere so ein bisschen zusammenkommt, ja.

Ja, und für mich war das so ähnlich wie bei dir, also wo ich dann, ich weiß nicht, ob das 2018 war, ich weiß nicht genau, wann die Block Themes rausgekommen sind, aber seit dem Moment, wo die rausgekommen sind, da habe ich das gleich für ein Projekt verwendet, und das war für mich einfach der Auslöser, eben wie bei dir, dass man jetzt Farben definieren kann, die dann im Editor verfügbar sind, und die Leute können sich keine anderen Farben auswählen, sondern das sind halt die Brand Farben, die vordefiniert sind.

Und das streckt sich dann über den gesamten Blockeditor bei allen Elementen, welche Farmen verfügbar sind und welche nicht.

Und alleine das, finde ich, ist eine super User Experience.

Also in dem Aspekt, wenn Kunden wenig kaputt machen können, dann ist das eine gute User Experience.

Ja, oder wenn man einfach die Entscheidungen wegnehmen kann, weil das eigentlich keine wichtigen Entscheidungen sind, aber ablenken von dem, was die Kunden eigentlich machen wollen an der Seite.

Und man kann die auch sehr viele Dinge ausschalten, wo man dann sagt, okay unsere Kunden brauchen so ein bisschen so ein Geländer, wo sie sich entlang hangeln können, ohne dass sie runterfallen bei der Treppe.

Das kann man eigentlich sehr gut, muss man natürlich in theme.

json machen oder in Code.

Und da hat der Nick Diego die 15 verschiedenene Methoden, wie man das für die verschiedenene Dinge, ob man jetzt, wie man nur den Duotone ausschaltet oder Gradients ausschaltet, ja das muss man ja nicht alles haben, nicht jede Seite braucht das.

Aber viele Designers wollen das eben auch haben.

Das ist irgendwie ganz schwierig zu entscheiden, was kommt rein oder nicht.

Ob das nur die Shadows sind oder die Border Controls.

Das ist alles, kann man alles kontrollieren, wie das beim Kunden ausschaut.

Ja, voll.

Und das ist dann warum ein bisschen aufwändiger, aber das, was mich dann noch zusätzlich überzeugt hat und das motiviert hat, noch ein bisschen mehr Mühe in die Projekte reinzustecken, ist wo ich dann gemerkt habe, okay, wenn du Custom Blöcke machst, dann kann das Backend, das was du schon angesprochen hast, nicht Save & Pray, sondern dann kann das Backend genauso aussehen wie das Frontend.

Und das habe ich davor nicht wirklich in einem Editor miterlebt, also zum Teil hast du ja diesen Drag & Drop Editor wie Elementor und keine Ahnung, also ich bin da relativ aus dem Page-Builder-Game schon ein bisschen draußen, also Bricks habe ich so ein bisschen angeteasert aber nicht wirklich verwendet und so Sachen, aber dass es halt so nativ in WordPress drinnen ist, wo du nicht einfach diese Post-Editor-Maske hast, wo du auf veröffentlichen klicken kannst und dann auch einen zusätzlichen Button hast, wo du in den Page Builder reinspringst, sondern das alles in einer Oberfläche ist und das alles so ausschaut im Backend wie im Frontend, das ist finde ich schon ziemlich geil.

Und das hat mich dann so zu 100 Prozent dann überzeugt, das war so dieser letzte Kick, den ich gebraucht habe, so okay, da kann man Projekte machen, die wirklich eine geile User Experience haben dann im Endeffekt für die Kunden, die das bekommen.

Einerseits, weil es simpel ist, es sind nicht so viele Optionen, andererseits, weil das genau so ausschaut, wie es ausschauen soll.

Ich kann da natürlich verstehen, der andere Seite, wenn jetzt zum Beispiel ein Webdesigner daherkommt und er will, er oder sie, die wollen die ganzen Optionen haben, dann finde ich kann da so eine, ich mag jetzt nicht sagen Diskrepanz, aber so ein Unterschied da sein in den Funktionen, die man sich erwartet.

Weil wenn man jetzt sich ein komplett ausgetuntes Design-Tool erwartet mit hey, da kann ich alles pixelgenau einstellen oder da kann ich das machen und so weiter.

Es geht, großteils wenn du dich mit theme.

json beschäftigst und dort dann viele Sachen machst, aber der Editor ist ja eigentlich nicht für Designer gedacht, sondern eher dann um den Content zu erstellen, wenn ich das jetzt richtig verstanden habe.

Also man kann da schon Design-Elemente mit einfließen lassen, aber es ist mehr so gedacht für Content-Erstellung und nicht so ein ausgefeiltes Design-Tool, was du jetzt als professioneller Designer verwenden kannst.

Das wäre so mein Eindruck, aber bitte, falls ich da irgendjemandem plötzlich geredet habe, bitte korrigiere mich.

Ja, ich meine, da hast du schon recht.

Pixelgenauigkeit im Web ist sowieso etwas, was man vor 20 Jahren schon eigentlich sagen müsste, da muss ich mich verabschieden, weil die Bildschirme immer größer werden, die Telefone werden immer kleiner und dann wieder größer und dann ist es auch noch am Fernseher.

Also da ist es immer schwierig zu sagen, ich will das genau so das Design haben, wenn ich das ausdrucke, dass es das gleiche ist.

Aber ich kann auch sehen, so die Entwicklung für, wie der Site-Editor entwickelt ist, dass man also, dass man erstmal gesagt hat, was sind diese Site-Wide Stile und Controls, dass man die erst im theme.

json hat, weil es einfacher zu handhaben ist.

Also zum Beispiel Hover für Button und Links, das gibt schon lange in theme.

json.

Das Interface für den Designer, der das im Interface machen will, ist noch nicht da.

Das gleiche war, dass man jetzt im theme.

json mit der 6.9 kann man den Border Radius in Steps machen, also Presets für den Border Radius machen.

Da gibt es noch kein Interface dazu.

Ja, dass man das auch im Interface feststellen kann, wie die Sprünge sind für die Borderadius.

Das war im theme.

json zuerst drin.

Genauso wie diese die Font-Controls, die man jetzt im, also seit ich glaube 6.3 oder 4 im Interface hat, die konnte man ab für seit 20 oder seit 5.9, wo es Blockthemes gab, schon im theme.

json kontrollieren.

Das heißt, theme.

json ist immer so einer der ersten Plätze, wo etwas integriert wird und dann muss man sich überlegen, wie macht man das intuitiv in einem Interface.

Und der letzte Schritt, das ist eigentlich der große Schritt, der dann gemacht werden muss, weil es ja nicht nur für die Theme-Builder da ist, sondern man muss natürlich dann auch überlegen, wenn ich die Funktion jetzt in den Editor nehme, kann ich die auch wieder rausnehmen.

Ja, weil eben Agenturdesigner da sehr stark Wert darauf legen, dass man eben bestimmte Funktionen wieder ausschalten kann.

Also es ist dann immer so eine bestimmte Folge von Abläufen, wie denn etwas implementiert wird, weil man ja dann auch auf diesen bestimmten Stufen dann auch kontrollieren kann, wie funktioniert das.

Und das ist eigentlich der sehr bewusste Entwicklungsflow, den du vorhin angesprochen hast, wo man dann sagt, okay, wir machen das ein bisschen langsamer, aber dafür wissen wir dann, dass das die Situation ist, dass man das auch weiter dann über die nächsten zehn Jahre auch maintainen können.

Ja und das geht dann wiederum auf diesen Aha-Effekt zurück, diesen Aha-Moment.

Also bei jedem ist da woanders.

Also je mehr technische Skills du hast, je mehr technisches Know-how, desto eher kommt der Aha-Moment mit dem Block-Editor.

Und wenn du diese nicht hast, dann musst du eben warten bis halt das User-Interface so weit ist, dass du das halt wirklich ohne CSS, ohne PHP-Kenntnisse alles alles machen kannst.

Ja, ich meine, was ich also gesehen habe, ist bei einigen Plugins, die haben also, also das Block Editor ist ja nicht nur das, was wir sehen und was wir dann auf Seite haben, sondern das ist auch eine Basis für die Plugin Developer, zusätzliche Funktionen reinzubringen.

Und da gibt es also ein ganzes Design-System für den Block Editor selber, wo man eben, wie man den zusätzliche Funktionen in den Sidebar mit rein, in die Sidebar mit rein nehmen kann und die verschiedenen Controls dazu.

Da gibt es also ein komplettes Komponentensystem und das ist ja auch noch entwickelt worden.

Das ist eigentlich die Grundlage für alles, was in dem Block Editor drin ist und das können auch Plugin Developers benutzen, sodass ihre Funktionen, die sie in den Editor tun, genauso ausschauen wie Core, sodass also der Benutzer, der das Plugin installiert, eben nicht neue Interface lernen muss, wie das eben früher in Plugins war, dass man dann immer wieder sagen, wo finde ich was und ja, wenn da neue Design Tools da sind, die finde ich in der Sidebar, ja, wo eben die anderen auch sind.

Und das ist eigentlich, das ist eigentlich der Punkt wo ich gesagt habe, das kann auch den ganzen Ecosystem sehr viel nutzen, dass dieses Component System da ist, weil die Plugin Developers müssen, haben dann ganz viele Entscheidungen, die sie nicht mehr treffen müssen und sie haben einen Partner, der eben Teile von dem Code selber pflegt, der für sie pflegt und das kommt jetzt noch mehr mit diesen ganzen Data Views und Data Forms.

Das ist jetzt technische Term, das ist im Endeffekt wie diese Adminseiten dann aufgebaut werden, was man jetzt in den Pages und in den Theme Template Editor schon sehen kann, wenn man die Listen hat, also die Listen der Seiten, die man hat und wo man dann eben verschiedene, man kann die dann ändern, man kann die in einem Gridview ändern, man kann eine Liste haben, man kann Tabellenform haben und dann kann man eben auf verschiedene Dinge klicken und eben dann editieren oder eben löschen oder irgendwie sonst was machen.

Aber das ist so das Interface, das dann irgendwann mal zu dem zu all dem ganzen Admin kommt.

Und dieses System für die, was dann eben auch Plugin Developers benutzen, ist gerade, wird gerade gebaut und getestet.

Das wird gebaut im Site Editor oder getestet im Site Editor, aber eben auch im Component System.

Und das ist eben die nächste Generation für WordPress ist, wie der Admin dann aussehen will.

Weil der sieht ja eigentlich aus wie wer 15 Jahre alt ist, was er ja auch ist.

Also ich meine, das ist natürlich auch immer eine, der WordPress hat sich oft nicht verändert.

Und auf einmal ist eine Änderung da, aber in der Technologie.

Man hätte eigentlich schon sehr viel mehr Änderungen sehen können, ja.

Aber das stimmt schon.

Ja, aber ich finde es mega interessant, dass du das gerade angesprochen hast, mit den ganzen Komponenten, mit den Libraries und so weiter, weil wo ich zum ersten Mal gesehen habe, wie viele JavaScript-Bibliotheken im Endeffekt gebaut wurden, alleine, also und so schön aufgeteilt.

Du kannst halt das importieren, um halt mit der Datenbank zu kommunizieren, um dir in einem Block halt schön über Javascript halt dann die Daten zu holen und nicht einen eigenen REST-API-Endpoint und einen Ajax-Request bauen und so weiter, damit das halt über die Umwege passiert, sondern gibt es ein fertiges Paket dafür, das man verwenden kann.

Genauso das Gleiche für die Komponenten, dass man das einfach verwenden kann, damit halt die Tabs gleich aussehen, wie WordPress das vorgesehen hat und so weiter.

Und wo ich gesehen habe, wie viel unter der Haube versteckt, zum ersten Mal, dann so, okay, wie viele Tausende von Entwicklerstunden sind da reingeflossen? Weil das ist wie ein komplett neues System, ein komplett neues, ich mag jetzt nicht sagen, also Monster im positiven Sinn, dass halt so viel schon dabei ist und das so viel schon ausgereift ist, man kann das zwar noch nicht so sehen, wie es schon entwickelt wurde unter der Haube.

Aber wenn das alles Step-by-Step sich so voran entwickelt, dann bin ich mega gespannt, wie sich das dann in der Zukunft zeigen wird und welchen Impact das haben wird auf die Art.

Macht mich total, finde das total gut, wie das funktioniert.

Und ich bin auch schon versucht, dass ich wieder anfange zu programmieren.

Also ich bin ja jetzt auch ein bisschen raus.

Ich Ich baue immer so kleine Sachen, wie mein Theme, ich baue mir mein Theme für die Gutenberg Times.

Ich darf das eigentlich gar nicht sagen, aber das ist immer noch ein Klassik-Theme.

Ja, aber es hält mich eben auch zurück, weil ich eben Dinge nicht darstellen kann auf der Seite, wie ich es eigentlich wollte, weil ich weiß, es ist funktionfähig und deswegen habe ich auch viele lokale Seiten, die alle nur mit Block-Themes arbeiten, wo ich eben sehr viel teste.

Und ich habe jetzt auch ein Plugin geschrieben.

Ja, man kann diese Social Icons, da kann man einfach neue Variationen dazu machen.

Und weil da muss man nicht auf Core warten als Developer, aber man kann das dann seinen Kunden zur Verfügung stellen.

Ja, und das ist eigentlich schon eine Erweiterung für eine Agentur, die also ganz schnell so ein paar Icons zusammenschustern kann, um die dann mit in die Webseite zu tun, obwohl das eben nicht in Core ist.

Aber genau solche Dinge sind halt, oder auch Blockstyles, da habe ich mal einen kompletten Artikel darüber geschrieben, in verschiedenen Arten, wie man eben Blockstyles implementieren kann, die eben nicht in Core sind, sondern sagt, ich will das meinen Kunden zur Verfügung stellen und wie die dann eben auch, das kann man wollen oder nicht, eben im Editor, im Stylebook dann auch editierbar sind.

Im Stilbuch heißt das dann, glaube ich, auf Deutsch.

Das ist also, der Stilbuch ist eigentlich das Geheimnis für Sitebuilder, die No-Code arbeiten.

Wie kann ich meine Sitewide-Blocks im Endeffekt kontrollieren, dass das in dem Stilbuch drin ist.

Das begeistert mich total, dass ich so viel Kontrolle habe und das überall dann auch sehen kann.

Wenn ich jetzt den Code schreibe, sehe ich sofort, wo das drin ist.

Und das war auch früher nicht der Fall, wo man erst lange warten musste, bis das dann drin ist.

Ich habe aber da noch ein paar Problemchen mit dem Block-Editor und welche Entscheidungen da getroffen wurden.

Also abgesehen davon, dass die Benennung der einzelnen Sachen teilweise verwirrend ist, teilweise später geändert wird und so weiter, das lassen wir mal vorne weg.

Ich glaube, wer sich näher damit beschäftigt hat, der weiß, dass zum Beispiel, hey, Full-Site-Editing ist jetzt nicht mehr Full-Site-Editing oder sowas.

Also da gibt es viele Sachen, wo man halt.

.

.

Wir gehen uns nicht mehr raus aus der Community.

Und das ist auch.

.

.

Ja, aber du hast natürlich recht, was viele Leute, die einfach nur mal so drüberfliegen über den Block-Editor finden, ist natürlich, dass die direkten Responsive-Styles nicht da sind.

Man ist da den Weg gegangen, dass man sagt, okay, es gibt eine zusätzliche oder eine modernere Version von nicht die Mobile Controls, aber von, weil wie groß ist der Viewport? Es gibt glaube ich 365 verschiedene Viewports für die Größe des Screens.

Und wie will man dann mit den Responsive Controls arbeiten? das hat man eben noch nicht so ganz raus weil man gut man kann natürlich drei sagen man kann einmal sagen und der telefon, tablet und der desktop das sind drei aber es gibt dann auch schon plugins da gibt es dann sechs verschiedene viewports und wenn du dann sechs mal verschiedene die Blöcke anders darstellst, ja, wie kann man da je wissen, wo was geändert ist, so dass man wieder was rückgängig machen kann und so.

Und das war eigentlich dann schon total verbirgt, ja.

Sorry, dass ich da kurz reingrätsche, aber das ist sogar bei drei Viewports mega umständlich teilweise, weil wie stehst du diese Optionen optisch dar? Also das habe ich zum Beispiel oft bei Elementor, da kann man dann die drei Viewports auswählen, die drei Gerätypen, aber dann ist das teilweise so versteckt und das ist nicht klar von Anfang an, wie das dann vererbt wird, die Option und so weiter, dass du teilweise gar nicht mal siehst, dass irgendwas eingestellt ist, aber mobil gibt's eine Fehldarstellung, aber das bekommst du gar nicht mit, weil irgendwer damals was eingestellt hat, das weißt du nicht mehr, du weißt nicht mehr, wo die Option ist und du kontrollierst das zum Beispiel nicht responsive und dann hast du halt ein Problem und dann suchst du in den ganzen Einstellungen, in den ganzen Tabs, in den Sub-Einstellungen, ist nichts eingestellt, aber du musst dann noch den Viewport ändern und dann siehst du erst die Einstellung, die eingestellt wurde.

Und das ist halt teilweise mega mühsam, dann diese Fehler zu finden, wenn man da von Anfang an nicht sauber arbeitet damit.

Und das ist, dann verstehe ich auch, wieso dann zum Beispiel dann diese responsive controls noch nicht drinnen sind, weil man sich dem Thema langsam annähern muss, wenn ich das jetzt mal so beschreiben kann? Wenn man jetzt eine Webseite macht und die ist ja eigentlich schon responsive.

Also mit einem einer von diesen default themes, die sind eigentlich fast generell responsive.

Dann gibt es auch bei den Media und Text oder bei den Columns gibt es eben diese Möglichkeit, dass man die Stacked in Mobile, ja man kann sie nicht kontrollieren, wie das, dass man jetzt eine wegnimmt oder so, aber das kommt wahrscheinlich ganz, ganz bald.

Aber was man eben versucht hat, war diese nächste, das nächste Modell für Responsiveness war ja Intrinsic oder ist Intrinsic Design.

Das heißt, der Container, in dem man jetzt Inhalte hat, der passt sich an, an den Bildschirmgröße, ob das nur der kleine oder der große ist, und der Font passt sich an, die Breite passt sich an, die Größe des Fonts passt sich an.

Und da hat man eben sehr viel übernommen von den CSS-Entwicklungen, dass man eben über Fluid redet, dass man sagt, okay, in theme.

json kann ich Fluid einstellen, dass verschiedene Fontgrößen eben im Fluid-System dann zusammen kleiner werden oder größer werden, je nach Größe.

Das ist das eine.

Und dann eben bei den Containern, beim Group-Block, dass der automatisch dann auch dementsprechend kleiner wird, größer wird.

Ob man nun den Reihenblock hat oder einen Stack-Block, das kann man alles dementsprechend kontrollieren und dann hat man eben versucht auf diese weise mal problemlösungen zu finden für bestimmte probleme nicht so global das ganze zu lösen ich kann aber sehen dass so auf der nächsten stufe 6.9 kommt ja mit dem hide mit dem block verstecken oder oder zeigen da hat man ja eine grundlage gebildet damit man eben da weiter darauf aufbauen kann und glaube Ich glaube, eine von diesen konditionalen Funktionen wird dann wohl responsive sein.

Also man sagt, okay, man kann einen Block verstecken, wenn es mobile ist, was ja zum Beispiel bei einer Spalten-Layout schon mal ganz wichtig ist.

Oder dass man sagt, okay, ich mache das woanders hin.

Also da bin ich halt so, ich habe an meinen Seiten eigentlich keine Probleme gehabt, das ordentlich auf mobile darzustellen.

Das einzige, was wirklich problematisch ist, ist die Navigation.

Ja, da gibt es zwar den mobilen Overlay, aber da kann man nicht sagen, wie viel dann, der nimmt einfach das, was am Desktop ist und tut's es in eine Sidebar oder in eine Seiten-Hamburger-Menü.

Aber man kann nicht sagen, ich will nur drei oder vier Items da drin haben, da ist die ganze Navigation drin und das sprengt natürlich immer einen Mobile, also es sei ist eine kleine Seite, die Anzeige auf dem Handy.

Da wird man aber drauf arbeiten, da sind die auch dran.

Das sind so Quality of Life Dinge, die so nacheinander auch durchkommen.

Man hat sich auch überlegt bei dem Navigationsblock, wie kann man das ein bisschen besser machen, wenn sich der Link zu dem zu der page kann das dynamisch gemacht werden und das das ist jetzt in 6.9 eigentlich ganz gut drin aber das braucht immer noch ein bisschen arbeit wie das ganze dann funktionieren soll ja ganz kurz und das was ich vergessen habe zu erwähnen weil wir nehmen die episode natürlich vorher auf die kommt dann später erst raus weißt du waren 6.9 da rauskommen soll 2. Dezember ist das Release-Datum.

Das ist auch zusammen das erste Mal überhaupt, dass die State of the Word Keynote von Matt Mullenweg am gleichen Tag ist und die wollen dann auch dort zeigen, was in der neuen Version drin ist und das gleichzeitig machen.

Bin mal gespannt, ob das funktioniert.

Ja, also deswegen, weil das etwas Zeitversetztes ist, deswegen ist 6.9 schon rausgekommen, wo die Podcast Episode veröffentlicht wird, damit dann die Zuhörer und Zuhörerinnen nicht verwirrt sind.

Genau, wollte ich mal kurz den Raum klären.

Aber etwas, womit ich dann immer Probleme habe, ich weiß nicht, ob ich das einfach nicht verstehe oder mich damit noch nicht wirklich gut genug beschäftigt habe, aber das was ich mega mag ist zum Beispiel bei den Schriftgrößen, REM und diese ganzen relativen Größen mag ich, verwende ich und das finde ich auch viel sinnvoller als einfach Pixel einzustellen.

Das sollte glaube ich jetzt schon mittlerweile jeder schon so im Kopf kategorisiert haben.

Aber womit ich dann immer kämpfe sind dann diese neuen Sachen, wie zum Beispiel was ich auch zum Fluidendesign dazuzähle sind so Clamp und all diese, ich sag jetzt mal, neuen Sachen, wo wenn du da drauf schaust, so okay, was bedeutet das eigentlich? Da ist von selbst definiert, da gibt es mehrere Clamp-Werte, da gibt es irgendwelche neuen Einheiten und so weiter.

Und ich hab da mich damit auch herumgespielt und da gibt es auch so Generatoren, wo man sich das generieren lassen kann online und so weiter, den genauen Wert und das Ganze.

Aber ich hab da nicht die Werte rausbekommen, die ich gerne hätte, dass die so visuell dargestellt sind.

Also das hat dann nicht harmoniert mit den anderen Textelementen.

Dann war zum Beispiel die Überschrift zu groß oder der Text zu klein, obwohl das ungefähr richtig eingestellt war, laut den Angaben vom Fluiden Design, aber wie gesagt, vielleicht verstehe ich das einfach falsch, aber ich bin das sehr pingelig, was dann die Proportionen von Text zueinander angeht und das Ganze.

Und da konnte ich das nicht so genau einstellen, wie ich es gerne hätte.

Und das ist das Problem, was ich habe mit dem fluiden Design jetzt in Bezug auf Font-Sizes, auf die Schriftgrößen, ist das einfach so by Design, dass man das nicht so genau einstellen kann oder mache ich einfach irgendwas falsch.

Hast du das probiert über theme.

json oder Interface? theme.

json, ich glaube theme.

json, also einfach nur so im CSS auch, also da habe ich auch nichts irgendwie sinnvolles da produzieren können.

Ich glaube am Anfang theme.

json war das und im Block Editor oder im Site Editor, besser gesagt, habe ich das glaube ich noch nicht versucht.

Ja im Site Editor gibt es eigentlich den Zugang zu Clamp nicht, da gibt es nur die verschiedenen Größeneinheiten, aber in theme.

json gibt es Fluid als ein Parameter mit True und dann eben die Maximum und Minimum festlegen und dann geht das Fluid.

Wenn das nicht richtig funktioniert, ist das ein sogenannter Bug und das wäre ganz gut, wenn du den reproduzierbar dann auch mitteilen könntest auf dem GitHub-Repo, damit das gefixt wird.

weil das ist natürlich, sowas ist alles im Test und für viele Leute funktioniert es und dann irgendwo sind dann Edge Cases, die dann im Endeffekt auch funktionieren sollten, aber es war halt nicht drauf gekommen beim Testen.

Und deswegen wäre eben das ganz gut, wenn du die Zeit nimmst, weil das dauert, bis man das Ganze dann so in einem Bug-Report hat, dass das jeder versteht.

Das ist schon klar.

Aber du kannst mir das auch gerne schicken und mir dann versuchen, mir klar zu machen und dann versuche ich das den anderen auch klar zu machen.

Oder ich nehme dann noch ein paar Leute dazu.

Du kannst auch in dem, also jetzt auch für die Leute, die zuhören, im WordPress Slack gibt es einen sogenannten Outreach-Channel, wo eben viele Theme-Developers drin sind, aber auch Developer, die eben dann auch Fragen beantworten können, wenn es eben um neue Funktionen geht oder um Funktionen, wie geht das eigentlich? Das habe ich jetzt probiert.

Hier habe ich ein Beispiel oder GitHub Gist oder so.

Ich glaube nicht, dass das richtig funktioniert.

stimmt das und wie würde das richtig funktionieren.

Und dann kann man auch mal sagen, hier Ella oder Fabian oder wie kannst du da mal nachgucken, vielleicht hast du da sogar eine Lösung.

Da haben wir so viele schon eine Hilfe bekommen.

Das ist nicht so sehr das Support Forum für was Bestimmtes, aber einfach wenn man mal versucht hat gerade bei den neuen Funktionen was auszuprobieren oder zu testen und dann nicht genau weiß, mache ich das jetzt falsch oder weiß ich da zu wenig, genau wie du es gesagt hast oder ist das tatsächlich ein Bug und dann kann man das feststellen.

Also ich würde es eher in die Kategorie reinhauen, ich habe das noch nicht so ganz genau durchblickt und ich verstehe das noch nicht so gut und ich mag die REM Einheit so sehr, dass ich dann da schon sehr fixiert bin, so hey, wieso funktioniert das jetzt anders, als dass ich das gewohnt bin quasi, aber deswegen würde ich eher in die Richtung tendieren, dass ich teilweise das nicht zu 100% noch durchblickt habe, weil das Gefühl, das wiederholt sich manchmal, wenn ich zum Beispiel irgendwie, keine Ahnung, irgendein Problem bei der Website habe und ich bin zu 100% davon überzeugt, dass es halt ein Problem beim Hosting-Anbieter ist, dann schreibe ich dem Hosting-Anbieter, der sagt, na, da schaut, das ist doch nicht ein Problem beim Hosting-Anbieter, natürlich politisch korrekt alles, und da ist so ein ein ähnliches Gefühl, wo ich halt das noch nicht so 100% verstehe.

Ich glaube, dass das irgendwie nicht so funktioniert, wie ich das bei mir im Kopf habe, aber das wird wahrscheinlich an dem liegen, was ich im Kopf habe oder was noch nicht so gut strukturiert drinnen ist.

Und das ist auch ganz normal, ja.

Aber das sollte dich nicht zurückhalten, entweder ein Issue zu teilen, ja, weil die Leute, die das lesen, die sagen dann schon, ja, schau das kannst du auch so machen, aber dann kriegst du Hilfe.

Und ich meine, nicht jeder will irgendwie sagen, okay, ja, das ist jetzt mein Fehler, das ist klar, aber das ist einfach eine Hürde, wie du lernst, wie ganz schnell du lernst.

Und das eigentlich, je eher du um Hilfe rufst, desto schneller kriegst du das Ding.

Und was es auch bringt, ist, dass die Contributors dann auch merken, ah, das ist jetzt ein Intuitionsproblem oder da haben wir das Interface nicht richtig oder ja, das kommt ja durch solche Fragen, dass man dann merkt, halt da müssen wir vielleicht am Interface was ändern, ja.

Und da musst du nicht, ja, ich meine, kann man sich schon vorstellen, dass man da so ein bisschen die Hemmschwelle hat, aber versuch die zu überbrücken und dann geht man da schneller dran.

Und dann hilfst du auch anderen Leuten, weil du wirst nicht der Einzige sein, der da hat.

Also bei Millionen und Millionen von WordPress-Usern und Theme-Developern ist jede Frage glaube ich hundertfach kopiert.

Und ich glaube, weil wir halt das durchgehende Thema haben oder die Frage beantworten wollen, ist Gutenberg reif genug in 2026. Dadurch, dass ich da noch zwei Themen habe, die ich gerne mit dir besprechen wollen würde, fasse ich das mal kurz zusammen, dass, ja, probier's einfach mal aus und dann wirst du sehen, ob das für dich reif genug ist oder nicht.

So, das ist halt der Clou aus der ganzen Podcast-Episode, weil jeder hat andere Skills, die man im Vorhinein schon mitbringt und so weiter und das wird einfach dieser Aha-Moment, ist für jeden woanders.

Deswegen, ob's reif genug ist oder nicht, für mich auf jeden Fall, ich glaub für dich genauso, aber für eine andere Person kann sein, da brauche ich noch mehr Optionen oder mehr Möglichkeiten.

Und da die zwei Themen, die ich mit dir dann noch gerne durchgehen wollen würde, ist einerseits der Lifecycle der, ich sag jetzt mal grob, Pagebuilder, da werfe ich mal Projekt Gutenberg auch mal in die Kategorie, weil es ein Presentation Layer ist für WordPress, den man dann einfach bearbeiten kann im Backend.

Und das andere Thema ist, was erwartet uns in der Zukunft mit AI, neuem Admin-Interface, was wir schon ein bisschen angeschnitten haben und so weiter, aber davor lifecycle der Page-Builder, weil wir haben das schon ein paar Mal erlebt in der WordPress-Community.

Es gibt zum Beispiel einen Page-Builder, der bringt eine gewisse Revolution mit sich, also wie zum Beispiel der WP Bakery Page-Builder, da konnte man zum ersten Mal visuelles Layout im Backend erstellen mit Drag & Drop, hat natürlich mit dem Save & Pray Prinzip ziemlich gut zusammengepasst, weil du halt keinen visuellen Preview hast, sondern nur halt diese Boxen halt im Backend.

Das hat viele Jahre gut funktioniert, wurde sehr stark entgegengenommen und sehr positiv entgegengenommen von vielen Leuten, sehr viele Themes haben es verwendet, danach wurde es größer, populärer.

Ich glaube, das wurde eigentlich nicht so buggy mit der Zeit, weil es funktioniert heutzutage noch immer ziemlich stabil, aber bei z.

B.

Elementor, das war dann der nächste cool Kid on the Block, sind auf die Art, danach wurde das populär, mehr Feature Requests, es wurde buggy, zu viele Sachen wurden in einer kurzen Zeit implementiert und danach kam z.

B.

Bricks, hey, wir lösen weitere Probleme, die Elementor nicht gelöst hat, weil Elementor z.

B.

das visuelle Bearbeiten der Website gelöst, aber die haben nicht diese Prozesse für Designer drinnen gehabt, wie mit dem Klassenmanager oder da konntest du nicht so gut nach Prozessen arbeiten, wie zum Beispiel mit Bricks.

Jetzt ist Bricks der neue Cool Kid on the Block und das passiert halt so alle paar Jahre und ich weiß noch nicht, wie sich Bricks zum Beispiel entwickeln wird, weil das noch relativ jung ist, sag ich jetzt mal, im WordPress Ökosystem.

Aber dann gibt es jetzt das Projekt Gutenberg und gilt dann dieser Page Builder Lifecycle dann auch für den Block-Editor, dass wir sagen, okay, das wird ein paar Jahre gut gehen und später wird das dann wieder durch ein anderes Tool abgelöst oder würdest du sagen das sind komplett zwei verschiedene Paar Schuhe, zwei verschiedene Kategorien, wo wir uns darüber halt überhaupt keine Sorgen machen müssen beim Block-Editor? Der Block-Editor ist in Core und der wird weiterentwickelt und solange es WordPress gibt, wird es da, nachdem das ja schon so eine Mammutarbeit ist ja so ein richtiges Herkules-Aufgabe ist, den Block-Editor jetzt zu ändern.

Was man eben in der Vision hatte, war, dass man den weiterentwickeln kann, dass er eben modular ist und was auch immer dann oben drauf ist, hat eine solide Basis in JavaScript.

Und das ist halt der Weg, den WordPress jetzt gegangen ist und der wird auch weiterbleiben, weil die Backwards Compatibility Versprechen, das ist ja da.

Und man weiß jetzt nicht, was die nächste Revolution beim Web-Building ist, aber dass der Admin neu ist, das bringt auch modernes Programmieren mit sich, wobei ich modern sage, das wird weiter PHP sein, das wird weiter JavaScript sein, das sind ja alles solide Tools und Programmiersprachen für den Erfolg und es wird halt standardisiert und ich glaube, dass die Standardisierung ist eigentlich das, was wirklich sehr ansprechend ist, weil wenn man jetzt von Page-Builder zu Page-Builder zu Page-Builder wechselt, dann hat man immer wieder einen neuen Workflow, man hat neue Standards, man muss migrieren von einem Page-Builder zum anderen.

Das kostet unheimlich viel Zeit und ich glaube nicht, dass viele Kunden diese Zeit, die ein Developer dann aufbringen wird, auch bezahlen wird auf die lange Sicht.

Das heißt eine solide Basis und wenn das Versprechen, dass das jetzt alles auch erweiterbar wird für Plugin-Developers, für Theme-Developers, für Agencies, dann ist eigentlich die das schon richtig klar, dass das der Weg der Zukunft ist.

Ich meine, Enterprise-Agencies haben fast alle schon umgestellt auf Blockthemes, die haben also ihren eigenen Workflow angepasst.

Dann hat zum Beispiel WebDevStudios, ist eine Agency, die sehr viel mit Enterprise-Seiten arbeitet.

Die haben also ganz viel auf ihren Webseiten darüber berichtet, wie ihr neues Blocktheme ausschaut, warum sie gewechselt haben und wie sie da eben ihren Workflow haben.

Da habe ich auch mal einen Podcast mit der J.

C.

Palms, der Engineering Manager, und es gibt auch jetzt ganz einige kleinere Organisationen, Organisationen, Agenturen, die den Weg gemacht haben, die gesagt haben, da war auch letztes Jahr im WordCamp Niederlande, das ja jetzt auch letztes Wochenende ist, hat auch jemand einen Vortrag gehalten über, wie ihre Agentur von fünf Leuten eben umgeschwenkt hat von Elementor auf den Blockthemes und wie gut das eigentlich funktioniert hat, vor allem auch für die Kunden und für die Performance von den Webseiten und auch sehr viel einfacher geworden ist, schneller zu Webseiten zu kommen.

Also gerade weil das eben in Core ist, ist ja schon mal eine Qualitätsversprechen im Endeffekt, ja, und dass das eben auch weitergeführt wird.

Da sind halt 800 Developers dran.

Ich glaube 6.9 hatte, glaube ich, 780 Contributors dran.

Und das vergleichen wir mal mit einer Agentur, oder mit einem Page-Builder, die vielleicht 20 oder 40 haben.

Ich meine, Elementor hat, glaube ich, 100 oder so, Aber trotzdem, ja, das ist halt dann nochmal ein Schritt mehr, der, ja, die man wegnehmen kann.

Und das finde ich eigentlich auch mega cool, wie du das zusammengefasst hast, dass es halt standardisiert wird.

Weil wenn du aus der Softwareentwicklung kommst, gibt es ja halt diese N-Tier-Architektur und da hast du halt diese verschiedenen Teilbereiche aufgeteilt bei einer Applikation.

Du hast zum Beispiel den Data-Layer mit der Datenbank, du hast den Business-Layer, wo die Business-Logik drinnen ist, wo alle Funktionen da sind und du hast den Presentation-Layer, wie das dann auf dem Screen präsentiert wird.

Also diese drei Etappen hast du und ich finde WordPress hat viele Jahre die ersten zwei Layer wirklich super abgebildet, also den Data-Layer und den Business-Layer, weil du hast alles dabei gehabt, was du halt brauchst, aber du hast diesen Presentation-Layer halt noch nicht gehabt.

Und das haben dann die Third-Party-Anbieter oder die Page-Builder dann ziemlich gut abgedeckt in den letzten Jahren oder auch die Theme-Hersteller davor, wo die Page-Builder noch nicht so populär waren.

Und jetzt deckt dann WordPress langsam schon diesen Presentation-Layer ab und das finde ich so super spannend.

Also wenn du das so aus der Vogelperspektive siehst, dann entwickelt sich WordPress erst zu einem vollständigen System und das existiert schon so viele Jahre, aber wenn du das von der Perspektive siehst, dann merkst du, hey, okay, das wird erstmal, der dritte Layer wird jetzt schon gebaut oder ist schon ein Großteil da und das finde ich auch so mega spannend, wie sich das auswirken wird und dann habe ich aber nur ein Bedenken, dass es jetzt viele Abhängigkeiten gibt von Page-Buildern, von Third-Party-Themes und so weiter und später kann ich mir gut vorstellen, dass es diese Abhängigkeiten nicht mehr geben wird, aber es wird Abhängigkeiten geben von Third-Party-Block-Libraries zum Beispiel, wo man nicht gleich zum Beispiel das System verlassen kann und irgendwo anders switchen kann, obwohl es schon diesen Standard gibt.

Siehst du dieses Bedenken auch, dass wir in der Hinsicht jetzt nur dieses Problem für den End-User woanders hin verlagern, obwohl es dann diesen Standard gibt, oder siehst du das anders? Im Endeffekt hast du recht, dass die Plugin-Ecosystem war eigentlich immer schon die Abhängigkeit von, wo die, ja, die Site-Owners waren immer abhängig von ihren Plugins, ja, dass das nicht unbedingt, aber was jetzt passiert ist, dass zum Beispiel Plugins nicht mehr Inhalte produzieren oder Themes nicht mehr Plugins haben oder Funktionen haben, die auch Inhalte produzieren, wo dann die Inhalte weggehen.

Also im Moment ist also mit diesem Block-Theme-Ecosystem ist also so, die Inhalte sind alle in der Datenbank immer im gleichen Bereich und wenn einer das lesen will, dann kann er das über ein Plugin machen oder über Theme oder über die REST-API auch für Headless, wenn das angestrebt wird.

Also das ist eigentlich einfach mal standardisiert.

Die Blockbuilders, das hängt natürlich davon ab, wie die Plugins das gemacht haben.

ich meine, das war auch der Grund, glaube ich, dass es so viele verschiedene Plugins gibt mit vielen Blocks, die eigentlich immer wieder das Gleiche machen, dass man gesagt hat, Okay, sollen wir davon welche in Core anbieten, wie zum Beispiel den Akkordeonblock, wie zum Beispiel den Tabsblock, der nächstes Mal dabei ist, den Breadcrumbsblock oder sowas.

dass das eben auch in Core ist, sodass die Theme-Developers damit rechnen können, dass das tatsächlich, wenn einer den benutzt, dass die den dann auch stylen können und dass der in diese Global Styles eben mit dabei ist und dass man eben möglicherweise dann den einen oder anderen Block von den Plugins eigentlich nicht mehr braucht.

Ich meine, die sind ja dahergekommen, dass Core eigentlich nur 20 Blöcke hatte und der Rest und keine davon wirklich besonders attraktiv für größere Seiten waren und eben auch nicht diese Designfunktionen haben, wie zum Beispiel Radius und Padding und Dimensions und sowas alles.

Das ist ja nach wie vor jetzt einfach so nach und nach in den Block-Editor gekommen und man als Site-Owner muss man sich dann schon überlegen, soll ich denn jetzt, muss ich denn, kann ich denn, ja, soll ich denn nicht auf den Core-Block übergehen oder ich bleibe halt, das Plugin bleibt halt da.

Ich hatte lange Zeit ein Plugin für den Table of Content und das eigentlich erst vor zwei Versionen hat das nicht mehr funktioniert und der Developer hat das aus dem Repository rausgenommen und das habe ich eigentlich nur noch auf meiner Seite gehabt, aber jetzt muss ich halt mit dem anderen Table of Content zurechtkommen.

Ich meine, das ist immer die Gefahr mit dem Plugin, wenn man sich darauf stürzt, dass man sagt, okay, ich brauche alles, ich brauche die 70 neuen Blocks, die jetzt mit dem neuen Plugin kommen.

Ja, das ist halt eine Entscheidung, wie viel Freiheit man braucht und was man eben als Möglichkeiten hat.

Das ist eigentlich das Schöne an WordPress, dass das alles möglich ist.

Wenn also jemand ein super tolles Plugin hat, weil das am besten zu seinem Theme passt und das wird eben open source verwendbar gemacht und möglicherweise auf zehn Seiten existiert in der Kombination.

Aber dann kann man das eben von der Repository herunterladen.

Ja, das ist ja auch gut.

Oder eben 100 Seiten oder 200 Seiten.

Ja, je nachdem.

Oder Millionen Seiten.

Je nachdem, wie gut das halt ist, ja.

ich meine, ich nehme so was wie das Ollie-Theme, das basiert auf dem Block-Theme.

Paradigm sozusagen.

Und alles, was dazukommt, da weiß man vom Mike McAlistar oder was auch Great macht, dass wenn Core aufholt, dass sie dann ihre eigene Version rausnehmen und dann sozusagen migrieren.

Das ist natürlich ein wirklich guter Ansatz, das ist auch der ethische Ansatz, aber das ist natürlich nicht überall gegeben.

Also zusammengefasst, es wird noch immer Abhängigkeiten geben, aber zumindest sind das dann standardisierte Abhängigkeiten.

Zum Abschluss noch, weil da nehmen wir schon eine ganze Weile auf, würde ich noch ein bisschen dich befragen wollen, was die Zukunft bringen wird, weil es wartet auf uns ja noch eine Phase 4, wir sind jetzt in Phase 3 vom Projekt Gutenberg und das ist glaube ich mega gut, wenn man das im Kopf hat, okay, das Projekt Guttenberg ist noch nicht fertig, das wird erst fertig, was kommt da auf uns zu, was ist in Bezug zum Beispiel, was vielen Developern glaube ich wichtig ist, ist auch dynamische Daten, kann man das den Kunden dann zur Verfügung stellen, sind das dann die Postmeta Sachen oder ist das dann was anderes, was ist dann AI, also die AI-Welle ist ja dann jetzt dabei.

Da gibt es ja auch so ein Tool wie Telex, MCPs sind ja auch in allen Münde und so weiter.

Es gibt ein eigenes AI-Team innerhalb von WordPress.

Also da habe ich jetzt viele Themen angegriffen, sage ich jetzt mal.

Aber kannst du gerne aussuchen, in welche Richtung du das gerne lenken würdest, um ein bisschen so einen Ausblick zu geben, was uns da erwartet in der Zukunft? Ja, also das Contributor-Team ist für 26 auf jeden Fall auch, arbeiten ja an der Gleichzeitigkeit von der Zusammenarbeit an dem Post, also diese Collaborative-Editing-Geschichte.

Da wird sicher auch noch eine zweite Bugfixes und Erweiterung von diesen Notizen geben, die ja dann im Block sind.

Das wird eine Erweiterung vom Grid-Layout möglicherweise geben.

Da ist ja vieles im Experiment.

Also wenn man unter Gutenberg Plugin installiert hat und dann unter Experimente geht, da sieht man ja eigentlich schon, was möglicherweise kommen kann.

Und da sind eben diese, das sind auch die neuen Blocks drin, die jetzt in der Mache sind.

Also der Tabs-Block, der Icons-Block, Breadcrumbs-Block.

Der Dialog-Block, der ist, das ist eigentlich ein ganz interessanter, weil du dann eben mit einem Button-Klick dann ein Fenster aufmachen kannst, wo dann irgendwas drin ist.

Ja, das finde ich auch ganz toll.

Das ist so der Block-Editor, dann die Komponenten für die Admin, das wird weiterentwickelt.

Da ist jetzt auch ein Design-System für die Farben, dass man eben, dass das durchgängig ist, wenn man also jetzt bestimmte Fonts und bestimmte Farben benutzt.

Das kann man alles schon im Storybook auf dem Repository dann sehen, auf dem GitHub Repository.

Da sind die Sachen alle drin für die Entwickler, um die nächste Schritt für den Admin zu sehen.

Da gibt es auch ganz viele Tutorials kommen jetzt raus für die Data Views und Data Forms.

Da gibt es auch Dev Nodes für 6.9 und da gibt es auch, was auch gut ist für den Developer, ist dieser neue Block Processor, der hilft den Developern, dass man mit dem Parsing von den Blöcken in den Inhalten, dass man da eben sehr viel besser manipulieren kann und sehr viel sicherer die ansteuern kann, ob man da jetzt nur Inhalte hinzufügen will oder dynamische Inhalte machen will.

Block Bindings ist für die dynamischen Inhalte jetzt da.

Alles, was im Post Meta ist, kann jetzt auch in dem Block dargestellt werden im Block Editor.

Das ist also richtig cool, da hat der Ryan Welcher jetzt die Tage eine gute Demo gemacht, wie das funktioniert.

Das wird auch in den Developer Hours mit angesprochen, weil 6.9 da auch das Ganze so ein bisschen aufmacht.

Das müssen also nicht mehr die Blöcke sein, die jetzt nur die 4 Blöcke, wo Block Bindings in 6.8 drin war.

Und AI, ja, die Abilities API, das sind halt die, was WordPress kann, sodass eine LLM da hinkommen kann und sagen, okay, das kann ich jetzt da machen mit einem Agenten.

Die AI-Geschichte ist ein bisschen noch verwirrend, weil MCP ist ja eigentlich nur ein Format aber die Abilities und da brauchst du aber den MCP Adapter.

Das wird alles in Core im AI Team schon bearbeitet.

Der Adapter übersetzt dann die Abilities für einen MCP Server, so dass die LLMs oder Agenten die da kommen also die Tools das dann bearbeiten können.

Da wird auch die Command Palette ist jetzt für ganzen Admin verfügbar mit 6.9 und das wird dann auch das Interface für irgendwelche KI Systeme sein, die dann auf die Abilities API zugreifen.

Und die Abilities-API, da wollte man den Standard jetzt schon mit in Core mit reinbringen, weil dann eben Plugins auch ihre Funktionen und Funktionalität auch dementsprechend vorbereiten können.

damit die dann, wenn der MCP-Adapter da ist, dass das dann alles zusammenspielt.

Aber es ist auf jeden Fall ein Bereich, wo man ein bisschen genauer hinhören muss und genauer gucken muss und dann auch mal ausprobieren.

Vieles wird ja erst klar, wenn man eben versucht irgendetwas mal auszuprobieren und zu sehen, wie funktioniert denn das jetzt? Kann ich jetzt meinen Chat-GPT dahin bringen, dass er mir einen Post macht oder irgend so was? Und das ist eigentlich das Spannende im Moment mit dieser ganzen KI-Geschichte, dass WordPress fast schon bereit ist, dass sie diese Dinge alle umsetzen kann.

Und da gibt es ja auch schon ganz viele Plugins im WordPress-Bereich, im KI-Bereich, aber nicht standardisiert und deswegen gibt es das Core-AI-Team, die dann darauf auf die Standards gehen.

Da bin ich schon mega gespannt, wie sich das alles weiterentwickeln wird, weil wenn du dann zum Beispiel über einen Agenten halt deine WordPress-Website bearbeiten kannst, inklusive Einträge in der Datenbank und so weiter, das wird dann schon mega cool sein.

Und lustigerweise, ich weiß nicht, ob ich dir das erzählt habe oder nicht, aber die nächste Episode, die ich aufnehmen werde, die ist dann mit Alex Kirk und da werden wir viel über AI und die ganzen Neuigkeiten reden.

Also das hat sich eigentlich gut ergeben, dass wenn da jetzt gerade wer zuhört und das Thema einen interessiert, wenn die Episode noch nicht draußen ist, dann kommt die zwei Wochen nach dieser Episode raus und da kann man gleich das Thema fortsetzen, wenn man sich dann mehr in die, ich sage jetzt mal die Zukunft von WordPress, irgendwie mehr darüber informieren möchte und was jetzt schon alles möglich ist und wohin die AI-Reise führen wird.

Und von den ganzen Neuerungen, von denen du erzählt hast, auf was freust du dich am meisten? Kann aber auch komplett was anderes sein, was du jetzt nicht erwähnt hast.

Ja, also ich finde, ich freue mich natürlich schon auf die neuen Admin.

Auf jeden Fall, dass das Ganze ein bisschen moderner ausschaut und dass da auch nicht mehr diese Verwirrung ist, bin ich jetzt im Admin oder bin ich im Site-Editor, dass das alles mal eine eine gute Soße ist und eben ganz modern ausschaut und dass man eben dann, ja, ich freue mich jetzt auf diese, die Journey, dass ich da jetzt ein Block-Theme mache und eben auch sehr viel tiefer auch in diese Problematik mit Fonts und so weiter reingehe, ja, was ist eine Verhältnismäßigkeit von Fonts, das habe ich mir schon lange nicht mehr überlegt, ja.

Da freue ich mich drauf.

Ich freue mich.

Ich bin auch froh, dass diese neuen Blocks kommen.

Akkordeonblock ist natürlich wunderbar, dass der jetzt im Core ist.

Es gibt ein ganz kleines, ganz kleine Funktion, die ich unheimlich toll finde, ist, dass man jetzt bei dem Video, wenn man ein Video auf die Webseite tut, kann man eben mehrsprachige Tracks für Untertitel verwalten, die man dann hochladen kann.

Dann kann das eben koreanisch sein und italienisch und deutsch und französisch.

Und man kann das auch machen für Videos, die keine Voice-Over haben.

Dass man einfach dann verschiedene Sprachen eben erklärt, was passiert in dem Video.

Und das finde ich also richtig cool.

Ja, ich habe das in der Source of Truth mal mit reingenommen, weil es eben so versteckt war und weil es auch sehr früh im Release-Cycle war, dass sie nicht wieder darüber geredet haben.

Aber das finde ich unheimlich cool.

Was noch? Ja, das war's.

Ah ja, die Social Icons, dass man Custom Social Icons machen kann, habe ich für meinen Podcast, weil ich ja in verschiedenen Podcast-Verzeichnissen drin bin.

Und ich wollte eben die Reihe der Icons für diese verschiedenen Podcast-Verzeichnisse herstellen.

Und das ist mir gelungen.

Das war eigentlich relativ einfach.

Meine KI hat dann auch geholfen.

Gut, dann werden wir uns schon langsam dem Ende der Podcast-Episode nähern.

Da haben wir schon ein bisschen überzogen von der Zeit her, aber da machen wir schnell den Abschluss.

Am Ende stelle ich dann auch immer so drei ganz kurze Bullet-Fragen, also das erste, was dir in den Kopf schießt.

Das kannst du gerne, gerne sagen.

Davor würde ich dir gerne den Spotlight geben, falls du irgendwas promoten möchtest, bewerben möchtest, dann wäre jetzt der perfekte Zeitpunkt dafür.

Ja, also wenn du die gutenbergtimes.

com noch nicht kennst, da gibt es einen Subscribe-Button.

Dann gibt es einmal in der Woche so ein Rund durch die ganzen Ecosystem, was gibt es Neues, was Leute machen, ob das nur Plugin ist oder ob das Themes ist oder ob das Tutorials sind oder eben was Core-Themes Richtung Block-Editor machen.

Ich, hin und wieder ist dann auch Playground mit dabei als Topic oder als Thema oder eben auch KI, wenn die Core-Teams da irgendwie was ganz Tolles eben rausbringen oder eben Tutorials vom DeveloperBlock gutenbergtimes.

com und da gibt es also gleich auf der ersten Seite das Subscribe-Button oder im Podcast GutenbergChangeLog, alle zwei Wochen mit dem Gutenberg-Release, aber wir reden auch über andere Sachen, die jetzt gerade in WordPress interessant sind.

Ja, wird auf jeden Fall alles unten verlinkt sein, deswegen klicke einfach drauf und dann wirst du gleich zu den ganzen Seiten, Podcasts und alles was du so machst gleich weitergeleitet werden.

Danke! Okay, die Bullet-Fragen.

Das erste was dir in den Kopf schießt kannst du gerne sagen.

Was ist das nervigste WordPress-Feature? Das nervigste WordPress-Feature ist, dass es eine Uncategorized Category gibt.

Das stimmt, ja, die man nicht löschen kann Und was ist dein Lieblings-WordPress-Feature? Mein Lieblings-WordPress-Feature ist tatsächlich der Block-Editor, dass ich alles sehe, was ich mache und dann kann ich das gleich publischen, ohne dass ich da immer wieder hin und her schalten muss.

Und wenn es jetzt WordPress, Automatic und Gutenberg Times und den Gutenberg Changelog Podcast nicht gäbe, was wäre dein Alternativberuf? Ja, da bin ich durch mehrere Phasen durchgegangen.

Architekt wäre noch ein Beruf gewesen, den ich mir sehr gut vorstellen hätte können.

Künstler im Sinne von Malerei ist auch noch was, was ich gerne machen würde, aber ich weiß nicht, ob ich das je im professionellen Bereich zustande bringen würde, dass ich da so davon leben könnte, einfach weil mir der Prozess so viel Spaß macht.

Ich hatte ja früher mal eine Karriere in der Gastronomie, aber da bin ich ja dann auch weg.

Aber so Buchhaltung kann ich auch machen.

Aber was ich machen würde, das wäre eigentlich dann so Architektur oder so Ja, also im gestalterischen weiterhin.

Perfekt.

Gibt es noch irgendeine finale Message, die du an die Zuschauer, Zuschauerinnen, Zuhörerinnen und Zuhörer weitergeben wollen würdest? Ja, probiert es aus und sagt mir, warum es nicht funktioniert.

Man kann mir immer eine E-Mail schreiben, das wird also auch, ob das du die Gutenberg Times oder über ein Changelog oder oder eben pingen im WordPress Slack, da kann man mich auch anpingen, auch in Deutsch, kein Problem, auch wenn der ganze Slack in, ich bin auch im deutschen Slack mit drin, also wenn irgendwas Fragen gibt oder so, ja, nicht scheu sein und ja, just frag mich und ich finde die Antwort, wenn ich sie selber nicht weiß, aber ich will das anbieten, dass das jeder machen kann, ich hab da, das habt ihr schon lange gemacht, die letzten 15 Jahre, dass wir immer wieder meine E-Mail-Adresse gegeben haben.

Es sind immer ganz gute Unterhaltungen, die man hat.

Sehr cool.

Dann vielen, vielen, vielen Dank, Birgit, für deine Zeit.

Hat mich sehr gefreut, dass wir das gequatscht haben.

Wie gesagt, das wird alles unten verlinkt sein, alles, was wir erwähnt haben, alle anderen Videos, Podcast-Episoden, Block-Beiträge und so weiter.

Das heißt, da kannst du dich gerne als Zuhörer oder Zuhörerin da reinlesen in die Nochmal vielen, vielen Dank für deine Zeit.

Hat mir mega viel Spaß gemacht.

Bin schon sehr gespannt aufs Feedback.

Und ja, dass wir uns dann irgendwann in real life dann wieder sehen werden.

Ja, vielen, vielen Dank, dass du so viel Zeit verwendet hast und dass du mir alles, mir die Zeit gegeben hast auf deinem Podcast.

Und viel Glück für die nächsten, weiß nicht, 80 Episoden oder so.

Danke.

Jetzt erstmal das Ziel bei 100 zu landen und dann wird die Entscheidung getroffen, wie es weitergeht.

Alles klar, vielen Dank.

Passt, danke, tschüss.

.