 Moin, Moin. In meinem Talk jetzt geht es um Gutenberg. Dieser Talk richtet sich eher an Entwickler, also einen Plugin-Entwickler und Seam-Entwickler, um zu zeigen, was es jetzt für Schnittstellen gibt und wie man den Editor und die Funktionen erweitern kann. Das richtet sich jetzt weniger an Endanwender, sondern ist ein bisschen Code zu sehen, ein bisschen Konzepte erklärt, was es möglich und wie kann man das alles umsetzen. Code zu mir, ich bin so im Brede, ich arbeite als Web-Entwickler in Hamburg. Beschäftige mich schon seit knapp zwölf Jahren und mit WordPress lernen immer noch dazu. Und habe jetzt so im letzten Jahr mich ein bisschen mehr mit Gutenberg beschäftigt, ein bisschen daran mitentwickelt und React gelernt und paar Sachen ausprobiert. Warum dieser Vortrag? Im Editor gibt es viele neue Konzepte, also es ist jetzt in Javascript geschrieben und deswegen ist es jetzt ein bisschen anders, wie man den erweitert, als es vorher war. Es gibt jetzt auch viele neue Möglichkeiten und die will ich jetzt einmal kurz vorstellen. Es wird aktiv noch entwickelt, also manche Sachen ändern sich noch oder sind noch nicht ganz fertig. Aber die Grundkonzepte, die stehen soweit und werden sich jetzt auch nicht grundlegend ändern. Genau, kurz zum Inhalt habe ich in verschiedene Bereiche gegliedert, also der Gutenberg-Editor baut ja auf verschiedenen Blöcken auf. Da zeige ich einmal kurz, wie man eigene Blöcke erstellt, wie man bestehende Blöcke anpassen kann und was dafür Möglichkeiten gibt. Dann zeige ich, welche Möglichkeiten es für Seams gibt, wie Seams Funktionen freischalten können und wie man Templates definieren kann. Dann zeige ich noch, wie man die UI erweitern kann, also wie man noch verschiedene Elemente hinzufügen kann, die Funktion noch erweitern kann durch eigene Plugins. Dann stelle ich noch den Datastore vor, was das ist, wie die Daten verwaltet werden im Hintergrund und dann noch den Pasa, was das ist und wie man den erweitern bzw. ersetzen kann. Das Ganze ist noch Work in Progress, also es ändert sich noch viel. Was ich jetzt zeige, ist so der Stand, wie er gerade ist, das Gutenberg 4.0 an der Version wird gerade entwickelt und genau gestern wurde die Version 3.9 veröffentlicht und jetzt wird einer Version 4.0 gearbeitet und das ist so jetzt der aktuelle Stand. Um eigene Blöcke zu erstellen, gibt es eine API, also eine Schnittstelle für Programmierer, da ist die wichtigste Funktion eigentlich die Register-Block-Type Funktion, als nicht kann man das sehen auf der rechten Seite so ein bisschen, also das Licht einmal vielleicht ausmachen. Genau, jetzt geht es wieder. Genau, da will ich jetzt nicht weiter darauf eingehen, da gibt es eine sehr gute Dokumentation zu, wie man eigene Blöcke erstellt. Gibt es auch auf WordPress TV viele Videos, wo man sehen kann, wie macht man das. Hier habe ich jetzt auch in den Slides ein paar Links drin, einmal im Handbuch, es gibt ein Handbuch, das speziell sich um Gutenberg dreht. Da gibt es auch ein Tutorial, wo Schritt für Schritt erklärt wird, wie man jetzt seinen eigenen Blog entwickelt und man kann sich auch die ganzen bestehenden Blöcke in GitHub anschauen, wie diese ganzen Core-Blöcke wie zum Beispiel Bild, Absatz, Überschrift, Galerie und so, da kann man im Code auch nachgucken, wie die das umgesetzt haben und kann sich daran orientieren. Es gibt auf YouTube auch Videotutorials, wo man sich das angucken kann und eine Boilerplate habe ich hier verlinkt. Ich kann mal grob durchgehen, wie das funktioniert. Also man ruft diese Javascript-Funktion auf und übergibt dann verschiedene Werte. Also erstmal gibt man dem Blog einen Namen, unter dem er in intern abgespeichert wird und dann kann man dem Blog Eigenschaften geben. Man kann Titel geben, man kann Eiken geben und dann eine Beschreibung, die dann auf der rechten Seite angezeigt wird. Eine Kategorie, wo der zu finden ist im Menü, wenn man den einfügen will. Man kann Keywords noch definieren, wenn man nach dem Blog sucht, dass man noch nach anderen Begriffen suchen kann und der Blog trotzdem auftaucht und über das Support-Array kann man noch Eigenschaften definieren. Also gibt es noch mehr, als hier aufgeführt sind. Wie gesagt, das soll jetzt nur ein Überblick werden, was es alles für Möglichkeiten gibt. Wenn man sich da weiter reinarbeiten möchte, dann gibt es sehr gute Dokumentationen. Die Slides gehen nicht. Genau, also kann ich jetzt mal weiter erzählen, ohne Slides. Also die Schnittstelle für die Blöcke ist in Javascript. Es ist sowohl möglich, mit der älteren Syntax in ES5 zu schreiben, oder in der neueren Schreibweise ES6, da hat man in Javascript noch ein bisschen mehr Feature. Die neue Schreibweise funktioniert allerdings nicht in älteren Browsern, also muss man das wieder ins ältere Format kompilieren. Neben der offiziellen Schnittstelle werden jetzt noch weitere Möglichkeiten entwickelt, Blöcke zu erstellen, die es vereinfachen sollen. Zum Beispiel verschiedene Plugins sind jetzt gerade dabei, eine Blog-API zu entwickeln, zum Beispiel Advanced Custom Fields. Das kennen vielleicht viele, nutzen viele. Genau, die haben jetzt im Blog-Post veröffentlicht, die mit gutem Berg arbeiten wollen und arbeiten jetzt gerade an einer PAP-Schnittstelle, die die Felder in die Blöcke einfügt. Und genau, das wird dann irgendwann in den nächsten Monaten kommen, dass man dann einfach über PAP und die Funktionen, die man jetzt eigentlich aus den Teams und Plugins schon kennt, dass man die da verwenden kann. Dann gibt es noch weitere Plugins, die dann auch das Gleiche machen, dass man das halt in PAP alles definieren kann und nicht in Javascript das entwickelt. Ich würde aber schon empfehlen, das in Javascript zu entwickeln, weil da hat man schon mehr Möglichkeiten und es wird immer mehr in WordPress auch Richtung Javascript gehen. Also es macht schon Sinn, sich mit Javascript mehr zu befassen und die offizielle Schnittstelle zu nutzen und sich nicht auf irgendein Drittanbieter-Plugin zu verlassen. Genau, jetzt ganz neu ist auch, dass einige Entwickler versuchen, gutem Berg für Drupal lauffähig zu machen, sodass es möglich ist, dass man einen Blog entwickelt und den in verschiedenen CMS nutzen kann. Also das ist jetzt gerade erst angefangen worden, das erste Versuche und erste Ideen, wie man das machen kann, wird halt jetzt diskutiert. Und ja, da wird sich in den nächsten Jahren dann halt auch noch sehr viel tun, dass man nicht für jedes einzelne CMS entwickeln muss, sondern das Ganze sehr unabhängig vom CMS wird. Genauso wie in PAP gibt es jetzt auch in Javascript Hux. Das orientiert sich sehr an der Schreibweise, wie es in PAP verwendet wird, also mit Actions und Filter. Hat man dann die Möglichkeiten zum Beispiel bei einem Blog, kann man zum Beispiel sagen, ich möchte jetzt den Titel von dem Blog ändern oder ich möchte jetzt noch eine bestimmte Einstellung zum Blog hinzufügen. Das wird alles, wie man es bereits aus PAP kennt, über die Hux geregelt. Genau, also da ein paar Filter und Hux sind schon drin, aber da wird auch gerade dran gearbeitet, dass man noch mehr Möglichkeiten hat. Das wird, genau. Statt dieser Hux gibt es auch einige Funktionen. Die Möglichkeiten bieten den Editor zu erweitern, also diese Funktionen bauen intern auf die Hux auf, aber haben eine leichtere Aufbau, bei der man besser verstehen kann, um das Ganze zu optimieren, damit man nicht alles wieder von neu schreiben muss, wenn man die gleiche Funktionen immer wieder verwendet. Hier habe ich jetzt ein Beispiel, wenn man zum Beispiel, also Blocks können verschiedene Styles haben, also zum Beispiel hier habe ich den Button-Block, da kann man sagen, ich habe jetzt vier verschiedene Button-Typen, und mit der Funktion Regista-Block Style kann man neuen Style hinzufügen. Hier sagt man jetzt, man möchte den Button erweitern, gibt dann noch einen Namen, das ist dann später die CSS-Klasse, und noch ein Label, der dann angezeigt wird im Editor, und so fügt man dann neue Styles hinzu. Und dann muss man im CSS nur noch sagen, was bei dieser CSS-Klasse dann passieren soll. Und im Editor kriegt man dann auch schon sofort eine Vorschau, wie dieser Style dann aussieht, was der dann an dem Button ändert. Die Frage war, ob man auf dem gleichen Weg auch ein Style wegnehmen kann. Über Hooks geht das aktuell, da gibt es aber glaube ich noch keine Funktionen für, aber das ist auf jeden Fall möglich, Style zu entfernen. Genau, das war jetzt grob erstmal zu Blocks, also da gibt es viele Möglichkeiten. Ja, das Wichtigste ist halt eigene Blöcke zu erstellen. Da habe ich sehr viele Beispiele verlinkt, könnt ihr euch mal anschauen. Genau, jetzt zu Seams. Seams haben auch viele Möglichkeiten, Gutenberg zu erweitern, sie können Styles überschreiben, können einige Funktionen aktivieren, können Blöcke auch noch anpassen, welche Optionen die haben und können auch die Styles vom Seam im Editor anzeigen. Genau, zum Beispiel können sie die Funktion hinzufügen, dass man Bilder hinzufügen kann, die breiter als der Inhalt sind. Das macht man über die Funktion Seamsupport, das ist eine PHP Funktion, die gibt es jetzt auch schon für viele HTML5-Formulare und so. Es sollte vielen Seam-Entwickler bekannt sein. Über diese Möglichkeit gibt es jetzt auch weitere Funktionen, die man hinzufügen kann. Also wenn man diese Funktion sozusagen im Editor freischaltet, dann wird dem Bild quasi eine bestimmte CSS-Klasse hinzugefügt, für die man dann Styles im Seam hinterlegen kann. Das wurde gemacht, damit alte Seams immer noch kompatibel bleiben, weil die jetzigen bestehenden Seams, die haben ja keine CSS-Anweisungen für das Bild, kann breiter als der Content sein. Oder für manche Seams macht es auch keinen Sinn. Deswegen ist dieses ein Opt-in-Feature. Und der Seam-Autor kann entscheiden, so will ich diese Funktion im Editor unterstützen oder macht diese Funktion für meinen Seam eigentlich gar keinen Sinn. Dann gibt es noch die Möglichkeit, Farben zu ändern von Blöcken. Zum Beispiel beim Button kann ich sagen, ich möchte jetzt hier einen blauen Button mit einem weißen Text haben. Da haben Seam-Autor dann auch die Möglichkeit, eigene Farben zu definieren. Genau, das wird auch über PAP gemacht, über Add Seam Support. Und da übergibt man dann ein Array mit den ganzen Farben. Der Button kriegt dann eine CSS-Klasse und für diese CSS-Klasse kann man dann, also für diese Klasse kann man dann wieder CSS Anweisungen schreiben. Man kann auch, also es gibt verschiedene Farben, die schon vordefiniert sind, diese kann man überschreiben, sodass nur die Farben aus dem Seam auswählbar sind. Man kann die Farben ganz deaktivieren. Oder man kann sagen, dass nur der Farbwähler deaktiviert wird. Das wird alles über Add Seam Support geregelt. Es gibt auch die Möglichkeit, verschiedene Schriftgrößen zu wählen. Auch diese kann man dann als Seam-Autor definieren, welche Schriftgrößen werden von meinem Seam unterstützt. Und dafür kann man dann halt auch CSS-Klassen anlegen. Oder diese Funktionen dann halt ganz deaktivieren. Also das macht man, indem man einfach ein leeres Array übergibt. Und dann ist das Ganze deaktiviert. Es gibt jetzt auch die Möglichkeit, die Styles vom Seam gleich auch schon im Editor anzuzeigen, wenn man zum Beispiel eine bestimmte Schriftart hat oder bestimmte Schriftgrößen, dass man im Editor dann auch schon diese Schriftart zur Verfügung hat. Das wird einfach so gemacht. Es wird das Style Sheet vom Seam genommen. Da wird dann Prefix vorgesetzt, sodass sich auch nur der Inhalt vom Editor ändert und nicht die anderen Elemente irgendwie überschrieben werden. Das macht man auch mit der Funktion Add Seam Support Editor Styles. Und dann gibt es noch zwei weitere Funktionen. Zum Beispiel, wenn man im Seam jetzt einen schwarzen Hintergrund hat, gibt es die Möglichkeit auch die UI ein bisschen anzupassen, dass man im Editor dann auch einen schwarzen, einen dunklen Hintergrund, also den Hintergrund vom Seam hat und die Elemente immer noch gut zu erkennen sind. Oder man kann auch aktivieren, dass die Blöcke ihre eigenen Styles ausliefern, also dass sie schon vordefiniert sind, also schon eigene CSS Styles haben. Dann gibt es die Möglichkeit, Block Templates zu erstellen. So, das sind dann schon vordefinierte Blöcke, die man hat zum Beispiel, wenn man jetzt ein Post Type hat und sagt, in diesem Post Type habe ich eigentlich immer ein Bild, eine Überschrift, dann eine Liste und am Ende ein Button. Dann kann man in diesem Template definieren. Für diesen Post Type füge diese Blöcke standardmäßig schon ein. Also wenn man dann einen neuen Post erstellt, sind diese Blöcke schon vordefiniert. Genau, das kann man entweder über einen Hook machen oder man übergibt dieses Template gleich schon in der Funktion, in der man den Post Type registriert. Da war eine Frage. Die Frage ist, wie man das beschränken kann, ob die Blöcke definiert sind und der User kann keine weiteren hinzufügen. Das ist die Funktion, die man hier unten sieht, Template Lock. Da kann man übergeben All, also wenn man All übergibt, sind alle gelockt. Der Benutzer kann keine löschen, keine neuen hinzufügen. Man kann den Wert Insert übergeben. Dann kann der Benutzer keine entfernen, aber neue hinzufügen. Standardmäßig ist es, wenn man da keinen Wert übergibt, dann ist es, dass der Benutzer die auch löschen kann und eigene hinzufügen. Man übergibt einfach ein Array und in diesem Array sagt man, ich möchte jetzt den Block Bild haben und das Bild soll schon nach links ausgerichtet sein. Da kann man z.B. auch die ganzen Attribute, die der Block hat, kann man da auch schon festlegen oder Platzhalter Texte definieren mit Anweisung. Das geht einerseits über PAP, wenn man das in der Funktion, in der man den Post Type registriert macht oder man kann das auch über Javascript machen. Das ist jetzt schon länger drin, aber es gibt auch noch viele weitere Ideen, wie man das noch erweitern kann. Es sind noch viele weitere Funktionen für diese Block-Templates geplant, die dann irgendwann in den nächsten Monaten umgesetzt werden oder dann in 5.2, in 5.3. Da wird das dann noch viel mehr möglich ist. Dann gibt es auch die Möglichkeit, die UI zu erweitern, also, dass man mit seinem Plugin eigene Buttons hinzufügt, eigene Sidebars hinzufügt oder bestimmte Elemente an bestimmten Stellen hinzufügt. Dabei wird auf die Slot-Film-Methode gesetzt. Also, im Editor sind bestimmte Stellen markiert, an denen Inhalte eingefügt werden können. Hier auf der Folie habe ich z.B. unter der Status-Bar ist sozusagen ein Slot. Und ich kann mich jetzt z.B. in diesem Slot, kann ich sagen, ich möchte diese Komponente in diesem Slot rendern. Genau, das ist rechts der Beispiel-Code. Ganz unten sage ich dann Register-Plugin. Also, das ist dann ein Editor-Plugin sozusagen. Dem gebe ich einfach einen Namen und sage, welche Komponente gerendert werden soll. Und diese Komponente ist dann oben definiert. Die heißt jetzt My Plugin Post Status Info und in dieser Komponente habe ich dann den Slot. Also, der Slot heißt Plugin Post Status Info. Und durch diese Komponente weiß der Editor, an welche Stelle das gerendert werden soll. Und wenn die Funktion ausgeführt wird, wird dann unten an der Stelle unten links da, wo man den Pfeil sieht, dann die eigene Komponente gerendert. Also, wenn man da irgendwelche Checkboxen haben will, wenn man irgendwelche Buttons haben will, wenn man Hinweistexte da anzeigen lassen will, dann kann man das über diese Methode machen. Genau, da gibt es an verschiedenen Stellen. Man kann zum Beispiel auch eine eigene Sidebar definieren, dass das Plugin eine eigene Sidebar ist. Zum Beispiel Yoast macht das. Die haben dann nicht mehr unten die Metabox, sondern haben dann eine eigene Sidebar, wo man dann Feedback kriegt. Wo ist mein Text jetzt optimiert für Suchmaschinen? Oder wo dran kann ich noch arbeiten? Das wird dann, die registrieren sich eine eigene Sidebar. Und genau, das Plugin, das hier ist, heißt Drop It. Mit dem kann man von verschiedenen Fotodiensten wie Ansplash zum Beispiel dann Bilder suchen und direkt in den Content einfügen. Und um Sonne, das funktioniert halt auch mit diesem Slot Fill, Mechanismus und um eine eigene Sidebar zu registrieren, braucht man halt auch nur fünf, sechs Zeilen. Und dann kann man einfach seine Komponenten da Rändern, APIs abfragen oder sonstige Funktionen in diese Sidebars packen. Neben den Sidebars gibt es auch noch die Möglichkeit, Popovers anzuzeigen, also Model Windows. Da kann man dann auch noch Einstellungen, dann hat man noch mehr Platz. Das setzt sich dann je nachdem, wie viel Inhalt man hat, über den Editor, so dass man noch mehr Platz hat. Also die Sidebars ja in der Breite beschränkt, aber wenn man irgendwie größere Sachen haben möchte, dann kann man das auch über ein Model Window machen. Genau. Dann gibt es noch den Datastore. Einige werden vielleicht sowas wie den Datastore kennen, die man schon mit Frameworks wie Vue.js oder React schon mal gearbeitet haben. Da gibt es dann sowas wie Redux oder Vuex. Das heißt, die Daten werden zentral abgespeichert, also zwischengehalten, und der Editor rendert nur diese Daten. Also die Daten sind nicht in den Komponenten, sondern es gibt eine Datenbank quasi Key Value Store, wo man die aktuellen Daten aufrufen kann. Dafür gibt es auch Browser Plugins, die dann den Datastore anzeigen. Hier habe ich auch nochmal Blockartikel verlinkt, in denen das ganz gut erklärt wird. Das zweite hier ist noch ein Vortrag von David. Das hat auch so ein Beispiel Plugin und ein Video, wo er zeigt, wie man seinen eigenen Store registrieren kann, wie man dann mit Slot Fill das macht. Also da hat man dann ein Beispiel-Code und er erklärt das auch in einem Blog-Post und hat ein GitHub Repository. Da kann man sich das mal anschauen und kriegt einen ganz guten Eindruck. Diese Datastores, also es gibt verschiedene Datastores, die Gutenberg schon breit hält. Das ist einmal CoreData, CoreNUX, also das sind die Tipps, die angezeigt werden. Viewport, da steht dann drin, wie breit das Fenster ist, ob man jetzt Mobile verwendet oder was man für ein Browser hat, ob die Sidebar gerade eingeblendet ist und alle möglichen Daten, kann man da abfragen. Dann gibt es ein Store zum Editor, das sind alle Einstellungen, ob man jetzt im Vollbild-Modus ist oder nicht. Man hat dann Editor Post, da stehen dann alle Daten drin. Die im Editor gerade eingegeben werden, wie zum Beispiel der Titel oder die Anzahl der Blöcke und diese ganzen Daten kann man mit seinen Plugins abfragen. Man kann mit Rigidster Store, kann man einen eigenen Store definieren, dass man einen eigenen Bereich hat, zum Beispiel Yoast hat auch einen Store drin und da stehen halt alle Werte, die dann später in der Sidebar gerendert werden, sind dann dazwischen gespeichert. Man kann also mit der Funktion Select aus allen Stores die Daten abfragen. Mit Subscribe kann man sich dazu sagen, dass man benachrichtigt wird, man kann die abonnieren. Das heißt zum Beispiel, man kann sagen, benachrichtige mich immer, wenn ein neuer Block hinzugefügt wird, dann wird die Funktion ausgeführt oder benachrichtige mich, wenn der Titel geändert wird oder wenn eine Kategorie ausgewählt wird. Und dann gibt es noch die Funktion Dispatch, mit der kann man dann Daten in den Store schreiben. Über den Store kann man dann auch Daten von der RestAPI abfragen. Da gibt es dann eine einfache Schnittstelle und die wird dann dazwischen gespeichert. Genau, da gibt es dann sehr viele Möglichkeiten, wie man dann mit Plugins auf bestimmte Interaktionen oder bestimmte Werte eingehen kann. Genau, und mit diesen Browser Plugins, die es gibt, kann man sich dann halt alle aktuellen Werte auch schon mal angucken. Da kann man dann eine Übersicht sehen. Und im Handbuch sind auch alle Werte aufgelistet. Da sind viele hundert Sachen, die da abgespeichert wird. Da steht dann auch jeder Block, der zur Verfügung steht, welche Attribute die Blöcke haben. Das kann man da alles nachsehen. Und man kann im Browser Plugin dann auch anzeigen, welche Daten werden überschrieben, welche Aktionen werden da gerade ausgeführt. Genau, da ist noch eine Frage. Redux. Die Frage war, welches Browser Plugin das ist, mit dem man dem Datastore angucken kann. Das ist das Redux Plugin. Es gibt es für Firefox und Chrome. Genau. Was wollte ich gerade noch? Dann gibt es noch den Pasa. Der Pasa ist die Komponente. Die ganzen Daten werden ja in HTML gespeichert in Kommentaren und Elementen. Und der Pasa wandelt dieses HTML wieder zurück in strukturierte Daten, die der Editor dann auch lesen kann. Das gibt es einmal fürs Backend und einmal fürs Frontend. Den kann man jetzt auch erweitern oder austauschen. Wir sind dabei nicht so viele Fälle eingefallen, wofür das jetzt wichtig wäre. Es gibt jetzt andere Implementierungen zum Beispiel. Einer hat das in einer Programmiersprache Rust einmal geschrieben. Und hat dann viel schnelleren Pasa. Der ist dann 100-1000 Mal, je nachdem, wie lang der Post ist, länger. So kann man das halt noch optimieren, wenn man für bestimmte Sachen was machen. Also mir ist da jetzt nichts eingefallen, um jeden Fall die Möglichkeiten auch den Pasa zu erweitern. Genau. Vieles ist nur ein bisschen dokumentiert oder noch gar nicht dokumentiert. Deswegen ist es halt wichtig, wenn ihr jetzt irgendwie sagt, ich möchte gerne mal einen Plug-in entwickeln, suche Dokumentation und finde da irgendwie nichts. Entweder kann man auf GitHub einfach ein Ticket eröffnen und sagt, hier fehlt noch die Dokumentation oder man öffnet ein Pull Request, man dokumentiert das kurz, guckt sich das im Code an und meldet das. Oder wenn man zum Beispiel ein Plug-in selber entwickelt, so dass man Blockpost veröffentlicht, so dass alle von diesen neuen Funktionen erfahren und irgendwie auch lernen und das weiter verbreitet wird. Das ist halt wichtig und dass man den Entwicklern Feedback gibt. Also wenn man sagen, ich möchte das und das Plug-in umsetzen, aber mir fehlen hier noch die Schnittstellen, also die Fitor, die und die Funktionen noch einbauen, damit ich dieses Plug-in umsetzen kann. Das ist halt wichtig, dass man da jetzt Feedback gibt. Die sind halt auch immer offen für neue Vorschläge, für Verbesserungsideen und so. Die kann man einfach in GitHub ein Ticket öffnen und erhält dann Feedback und oft wird dann auch am nächsten Tag einfach die Dokumentation erweitert oder man erhält noch mal ein Beispiel oder ein Link, wo das dann besser dokumentiert ist. Genau, das war einmal der Überblick, was es alles gibt, was es für Möglichkeiten gibt, wo man es nachlesen kann. Ja, gibt es noch Fragen? Ja, die Frage war, wie das gespeichert wird. Du meinst, wie ein Block abgespeichert wird oder die ganze Post einfach abgespeichert wird? Genau, die Frage ist, wie das in die Datenbank gespeichert wird, wenn man auf Speichern klickt. Also es gibt ja diesen Datastore, dieser Datastore, die ich am Ende gezeigt habe, die sind erstmal alle Daten drin, wie der Beitrag heißt, wie der Outdoor heißt, welche Kategorie ausgewählt sind. Diese Werte werden dann an die REST-API geschickt und die erstellt dann einen neuen Post. Und jeder Block wird mit einem HTML-Kommentar ausgezeichnet. Das kann ich kurz mal raussuchen, ob ich das auf die Schnelle finde. Aber das kannst du auch, wenn du den ID-Tour einmal öffnest, habe ich jetzt hier einen, es gibt diesen Demo-Beitrag. Da gibt es auch die Möglichkeit, sich den Quellcode anzeigen zu lassen. Genau hier haben wir ein Beispiel, Beitrag mit Textüberschrift, Bildern, Galerien, Listen. Also vielen verschiedenen Blocken. Wenn man hier aufs E klickt, sieht man, es sind 36 verschiedene Blöcke. Das wird alles, wie bisher in die Tabelle Post, also in das Feld Post-Content gespeichert. Also ein ganzer Beitrag wird als Post-Content gespeichert. Also nicht jeder Block wird einzeln abgespeichert, sondern der ganze Beitrag wird abgespeichert. Und diese Blöcke werden in bestimmtes Format, wenn man hier auf Code-ID-Tour geht, sieht man dann das Format. Das wird immer mit HTML-Kommentar gekennzeichnet, einen öffnen und einen schließenen. Und in diesem HTML-Kommentar kann man dann verschiedene Attribute speichern. Bei diesem Cover-Image-Block ist es zum Beispiel dann die URL des Bildes und wie breit das Bild, also was für ein Style dieses Bild hat. Und im Kommentar wird dann HTML gespeichert. Und der Pasa, also wenn man dann den Post wieder editieren will, dieser Pasa wandelt halt diese Attribute und den HTML-Content wieder in JSON-Data, in Datastore. Da holt sich dieses Markup und wandelt das wieder so in den Datastore um. Genau. Da oben noch eine Frage. Die Frage war, wenn man jetzt die Suche benutzt, weil die Suche ist eine Volltext-Suche, findet die, wenn man jetzt nach Cover-Image oder Paragraph sucht, findet die die auch diesen HTML-Kommentar. Nein, macht sie nicht. Ich bin mir nicht hundertprozentig sicher, aber ich glaube, es wird die gerenderte Version durchsucht. Also es gibt ja einmal als Raw und einmal als Rendert der Content. Und genau, also im Frontend sind ja diese HTML-Kommentare auch nicht vorhanden. Also wenn ich mir diesen Post im Frontend angucke, sieht man nur was zwischen diesen Kommentaren sind. Die werden sozusagen rausgefiltert, die Kommentare. Und so wird das... Doch, also... Ganz am Anfang. Also wenn ich jetzt auch veröffentliche Klick veröffentlichen und mir den Post im Frontend angucke und hier auf den Quelltext gehe, wenn ich hier nach... Das war ja die Frage Graph, Paragraph. Dann findet er den Post. Ja, okay, da gibt es wahrscheinlich ein Ticket für. Also ja, die Suche liest die Kommentare noch mit. Ja, wird wahrscheinlich auch noch so funktionieren. Genau, aber das wäre was. Gibt es wahrscheinlich ein Ticket und muss noch gefixt werden. Also es gibt ein Ticket dazu, war die Anmerkung und gibt noch keine Lösung. Offizielle Aussage. Okay, ich kenne die Ticket nicht, aber ja, gibt ein Ticket dazu. Die Frage ist, wie das mit den Spalten funktioniert. Wie es abgespeichert wird, wenn man Spalten... Genau, das sind dann einfach verschachtelte Kommentare. Also es wird einmal um den Spalten-Block öffnen, dann schließe ich einen Kommentar. Und im Spalten-Block sind dann auch einzelne Blocke. Das kann ich kurz mal erstellen und dann schauen wir uns das einmal an. Genau, ich füge jetzt ein Spalten-Block hinzu. Sag, hier ist jetzt zum Beispiel ein Bild und rechts ist... Was nehmen wir? Eine Liste. Die ist natürlich jetzt nicht rechts. Genau. Also wenn ich jetzt wieder auf den Code-Editor sehe, sieht man hier, es gibt Callums öffnen, schließen. Da drin ist dann Callum, also Einzahl. Und hier Callum, genau. Die Frage war, warum man das in der Datenbank nicht als JSON abspeichert, sondern das in diesem HTML-Format speichert und immer wieder pausen muss. Die Antwort ist, damit man abwärts kompatibel bleibt. Also damit alter Content weiterhin funktioniert. Also man hätte jetzt auch sagen können, wir speichern das jetzt im JSON-Format ab, was mehr Sinn macht. Aber man hat sich dafür entschieden, dass halt die ganzen alten Inhalte weiterhin funktionieren. Dieser Editor bietet aber die Möglichkeit, man könnte dann einfach sagen, speicher den Inhalt nicht nur in Post-Content, sondern speicher mir den Inhalt auch als JSON in diese Datenbank ab. Also es kann sein, dass es irgendwann die Möglichkeit gibt, dass man das einfach als JSON weiß. Es liegt ja im Editor sozusagen in diesem Format vor und man kann das auch so abspeichern. Genau, also es hat dann bestimmte Vorteile. Dann wird, die Frage war, was passiert, wenn ich jetzt hier irgendein Block ändere und den es gar nicht gibt, dann wird dann vieler angezeigt, bei dem einzelnen Block. Dann wird, genau, alles andere funktioniert, nur für diesen Block. Er zeigt hier den Classic Block an, weil er den Block nicht kennt. Dann wird nicht zum Beispiel ein Attribut irgendwie komisch ändern, mit dem er nichts anfangen kann. Dann wird dieser Block, steht dann eine Fehlermeldung und sagt, hier dieser Block kann nicht gepasst werden und das ist der Inhalt. Und dann kann man gucken, wo das Problem liegt. Hier oben noch eine Frage. Die Frage war, wenn man Blocks ineinander verschachtelt und man dann auch definieren kann, dass ein bestimmter Block nur in einem bestimmten Parent Block verwendet werden kann. Wenn man eine Block Registriert, dann gibt es auf jeden Fall die Möglichkeit anzugeben, dass man den Parent Block auf jeden Fall definiert und sagt, dieser kann nur innerhalb von dem Block verwendet werden. Die Möglichkeit gibt. Die Frage war, ob es auch andersrum geht, dass man im Parent Block definiert, welche da drin sein können. Weiß ich es doch nicht, müsste ich nachgucken. Andersrum geht es auf jeden Fall, ob das so rum auch zu definieren, kann ich jetzt nicht sagen. Aber falls du die Funktionen haben willst und es nicht gibt, einfach einen Ticket eröffnen und dann Funktionen vorschlagen und dann wird drüber diskutiert, ob es eingebaut wird oder wie es möglich ist oder ob es die Möglichkeit schon gibt. Die Frage war, wenn man Poster definiert und irgendwie dann das Template, in welchem Format man das angibt, das kann man einfach über PAP ein Array übergeben. Genau, also kann man einfach in PAP bleiben. Es gibt auch, das Team Support war das gar nicht, das waren Block Templates. Es gibt die Möglichkeit, das in PAP zu registrieren oder in Javascript, aber weil man den Post Type sowieso definiert, so wenn man das an der Stelle machen kann, macht das Sinn, das da in PAP zu machen. Also genau. Hat irgendwer schon ein bisschen mit Gutenberg weiterentwickelt, dass er seinen Plug-in dafür angepasst hat oder irgendwelche, die Hux mal genutzt hat oder irgendwas, was ich von den Funktionen vorgestellt habe. Noch keine Erfahrung. Ja, ich glaube, jetzt sind wir auch von der Zeit her durch. Danke fürs Zuhören.