In einem kürzlich abgeschlossenen Projekt wollte ich für die Bilder in einem Slider-Block das sizes-Attribut nutzen. Da der Slider aber nicht immer in derselben Situation angezeigt wird, also beispielsweise über die volle Breite des Viewports (ein sinnvoller Wert für sizes wäre hier 100vw), sondern auch in normaler Content-Breite oder innerhalb von Spalten-Blöcken, musste der Wert für ein optimales Ergebnis abhängig von der Position des Slider-Blocks sein.
Anchor-Support für dynamische Blöcke
Bei einigen Core-Gutenberg-Blöcken wie etwa der Überschrift können in der Block-Sidebar unter dem Punkt Erweitert nicht nur eigene CSS-Klassen eingefügt werden, sondern auch ein HTML-Anker. Damit wird das id-Attribut des Elements gesetzt, sodass mit einem Sprungmarkenlink darauf verwiesen werden kann.
Alles was dafür getan werden muss, ist bei der Block-Registrierung den folgenden Code anzugeben:
supports: {
anchor: true,
},Einfach, oder? Ja, es sei denn, es handelt sich bei dem Block um einen dynamischen Block, also einen der in der save-Methode null zurückgibt und sich in einer PHP-Funktion um das Rendering kümmert. In dem Fall wird zwar mit dem oben stehenden Schnipsel das Feld erzeugt, wir kommen aber nicht an den eingegebenen Wert dran, da er nicht als Attribut in der PHP-Funktion ankommt.
Ich habe einen nicht so schönen kleinen Umweg gefunden, um es trotzdem umzusetzen.
Anchor-Support für dynamische Blöcke weiterlesenGefiltertes Block-Markup für Nicht-Admin-User durch wp_kses
WordPress lässt standardmäßig nur Administratoren ungefiltert HTML im Editor eingeben und speichern. Bei allen anderen User-Rollen wird weggefiltert, was nicht in einem festgelegten Set von Elementen und Attributen vorhanden ist, etwa svg-Elemente oder das sizes-Attribut für img-Elemente. Das betrifft auch HTML, das von Blöcken und nicht direkt von Usern generiert wird, was zu interessanten Ergebnissen führen kann.
Eigenen Block immer in voller Breite im Editor einfügen
Normalerweise werden Blöcke alle in derselben Standard-Breite in den Gutenberg-Editor eingefügt. Abhängig vom Block und davon, ob das Theme es unterstützt, gibt es noch die Möglichkeit eine weite oder die volle Breite zu aktivieren, damit der Block im Frontend über die normale Inhaltsbreite hinausgeht.
In einem Projekt hatte ich den Fall, dass ein eigener Block immer über die gesamte Breite gehen sollte, ohne Änderungsoption für den User. Im Frontend habe ich einfach entsprechend das Styling angepasst, aber im Backend sind ein paar weitere Anpassungen notwendig, da bei einem Full-Align-Block die Controls zum Umsortieren nicht links neben dem Block dargestellt werden, sondern darüber.
Eigenen Block immer in voller Breite im Editor einfügen weiterlesenBlock-Variationen in Gutenberg erstellen
Mit WordPress 5.4 wird die Block Variations API in WordPress Einzug halten. Damit ist es möglich, Variationen von Blöcken zu erstellen, die dann auch als eigene Einträge im Block-Inserter angezeigt werden. Ein Beispiel aus dem Core sind die Social-Media-Buttons, die alle eine Variante des Social-Link-Blocks sind.
Block-Variationen in Gutenberg erstellen weiterlesenAttribute des Block-Edit-Wrappers verändern
Im Gutenberg-Editor liegen ein paar Wrapper-Elemente um das Markup aus der edit-Funktion. Der äußerste hat die wp-block-Klasse und ein data-block-Attribut, in dem der Name des Blocks mit dem Namespace steht, bei dem Gruppe-Block beispielsweise core/group.
Die Attribute dieses Wrappers lassen sich verändern, so können zum Beispiel Klassennamen eingefügt werden, die etwas über den Wert von Block-Einstellungen aussagen, was für das Styling des Blocks im Backend vorteilhaft oder notwendig sein kann.
Attribute des Block-Edit-Wrappers verändern weiterlesenGutenberg-Eingabefeld wie das für Schlagwörter erstellen
In einem meiner aktuellen Projekte sollte es möglich sein, für Beiträge eines Custom-Post-Types Verknüpfungen zu Beiträgen eines anderen CPTs herzustellen. Ich wusste nicht genau, welche Gutenberg-Komponente dafür am besten geeignet wäre, bin dann aber an dem Feld für die Schlagwörter normaler Beiträge hängen geblieben: bei Nutzereingabe erscheinen passende Schlagwörter und können einer Auswahl hinzugefügt werden.
Mit dem FormTokenField-Feld kann das Verhalten nachgebaut werden, in der verlinkten Readme sind alle Optionen für die Komponente aufgeführt. Damit war die Komponente gefunden, die ich nutzen wollte, statt Schlagwörtern werden CPT-Posts vorgeschlagen.
Veröffentlichen und Aktualisieren in Gutenberg verhindern, bis Bedingung erfüllt ist
In Gutenberg kann der Button zum Veröffentlichen und Aktualisieren deaktiviert werden. So wäre es beispielsweise möglich, vor dem Veröffentlichen eines Custom-Post-Type-Inhalts das Ausfüllen eines Blocks zu erzwingen, mit dem Metadaten für den Inhalt gespeichert werden, die bei der Ausgabe benötigt werden. Hier zeige ich, wie das funktioniert.
Veröffentlichen und Aktualisieren in Gutenberg verhindern, bis Bedingung erfüllt ist weiterlesenUpdates bei Block-Plugins und die oft verzögerte Auswirkung aufs Frontend
Ich bin ein großer Fan von Gutenberg. In den letzten Wochen hatte ich allerdings gleich mehrfach das zweifelhafte Vergnügen, bei dem Seiten nach dem Aktualisieren plötzlich im Frontend zerschossen waren, obwohl nicht groß etwas geändert wurde.
Der Grund: ein Block-Plugin hatte ein Update spendiert bekommen, mit dem das Markup der Blöcke geändert wurde. Dadurch griffen CSS-Änderungen nicht mehr, die ich im Theme gemacht hatte. Gut, das hätte auch mit Markup passieren können, das über Shortcodes generiert wird.
Updates bei Block-Plugins und die oft verzögerte Auswirkung aufs Frontend weiterlesenKorrekte Meta-Werte nach Post-Update im Block-Editor bekommen
Vorwort: Torsten Landsiedel hat das #Projekt26 gestartet, bei dem über ein Jahr alle zwei Wochen ein Blogbeitrag und ein Kommentar zu einem anderen #Projekt26-Artikel geschrieben werden sollen. Ich versuche mich auch daran, um das Blog wieder etwas regelmäßiger mit Beiträgen zu füllen. Hier mein (kurzer) Start-Beitrag.
Manchmal ist es notwendig, nach dem Speichern eines Posts eine bestimmte Aktion mit den aktualisierten Daten durchzuführen. Der Block-Editor macht es einem da insofern schwer, als dass die bisherigen Hooks wie save_post oder post_updated nicht wie erwartet funktionieren: die Metawerte stimmen zu dem Zeitpunkt noch nicht, sondern sind auf dem alten Stand von vor der Aktualisierung.
Abhilfe schafft der rest_after_insert_{$this->post_type}-Action-Hook, der als ersten Parameter das Post-Objekt erhält ({$this->post_type} muss durch den Bezeichner des Post-Types ersetzt werden, also beispielsweise post oder page). Wenn zu diesem Objekt dann via get_post_meta() Daten ermittelt werden, handelt es sich um die neuen Werte.