WordPress 6.2 – die FSE-Betaphase ist vorbei

WordPress 6.2

Nachdem sich der Release-Termin der neuesten WordPress-Version 6.2 (Dolphy) um einen Tag verzögert hatte, kam sie gestern (29. März), und ich aktualisierte umgehend meine Testumgebungen. Da ich keine Probleme feststellen konnte, ging es weiter mit meinen eigenen Websites. Auch hier – keine Probleme. Bis Mitternacht hatte ich alle von mir betreuten Projekte upgedated. In einer WordPress-Gruppe erfuhr ich allerdings am nächsten Tag, dass vereinzelt Probleme mit manchen Themes aufgetreten waren. – Nicht alle Anbieter testen ihre Komponenten mit Beta- und RC-Versionen um ggf. rechtzeitg Updates parat zu haben.

Tipp: zuerst Plugins und Themes updaten, erst dann das WordPress-Versions-Update machen. So sind etwaige Kompatibilitätsanpassungen bei Plugins und im Theme bereits implementiert.

FSE ist nun voll integriert

Was sofort ins Auge stach: der Website-Editor ist nicht mehr Beta. Die Bearbeitung von Templates und die Navigation zwischen den Elementen ist erwachsen geworden. In einem Projekt mit Twenty Twentythree fand ich nun ein Element mit Seitennummerierung vor. Beim Aufsetzen des Blogs gab es nur „neuer“ und „älter“, diesmal wurde mir beim Bearbeiten des Teilelements mit der Seitennavigation sofort auch ein dritter Block „Seitenzahlen“ angeboten.

Klickt man auf das Plus, um Elemente hinzuzufügen, gibt es nun Blöcke, Patterns und Medien. Dort stehen einem nun zahlreiche kostenfreie Bilder aus dem Metaverse zur Verfügung. Ursprünglich als Hotlinks vorgesehen (externe Medien) werden ausgewählte Bilder nun in die Mediathek geladen und lokal gehostet. Damit steht einem, was das Metaverse zu bieten hat, datenschutzkonform zur Verfügung.

Das Stilbuch

Zwar ist es nicht neu, Stile global festzulegen hat bereits vorher funktioniert. Tatsächlich hat sich die Stilverwaltung nun zu einer der genialsten Entwicklungen gemausert, die FSE mit sich bringt. Stile können hier jeder Zeit global geändert werden.

An den Stileditor kommt man über die Bearbeitung eines Templates heran.

grafik

Der Punkt „Blöcke“ führt zur Liste verfügbarer Blöcke, die an der Stelle umgestyled werden können. Ggf. sogar mit eigenen CSS (für jeden Block).

Das Feature muss in der theme.json freigeschaltet sein.

"styles": {
    "blocks": {
        "core/button": {
            "css": "background: #FF0000"
        }
    }
}

Oder (um nicht jedes Design-Feature einzeln freizuschalten):

{
    "settings": {
        "appearanceTools": true
    }
}

Die vorgenommenen Änderungen können zentral auch für bereits bestehende Blöcke angewendet werden. So könnte ich z.B: alle meine Codeblöcke nachträglich in anderen Farben darstellen, und sie wären in allen Beiträgen identisch neu gefärbt.

In den globalen Stilen sind nun auch Schatten möglich, und es gibt eine Einstellung für Mindesthöhen (sofern nicht bereits appearanceTools: true sind, mit nachfolgendem Snippet in der theme.json).

{
    "settings": {
        dimensions: "minHeight": true
    }
}

Manuell eingefügte Stile (z.B. speziell ausgesuchte Farben für Text oder Hintergrund) bleiben von globalen Anpassungen unberührt. Geändert werden nur Standard-Designs.

Sticky Elements

Vorausgesetzt, das verwendete (Child-)Theme unterstützt es (entweder mit „appearanceTools„: true oder)

    "settings": {
        "position": {
            "sticky": true
     }

können gruppierte Elemente „sticky“ gesetzt werden. Sticky Header sind nun also auch mit FSE umsetzbar. – Theoretisch – die praktische Anwendung muss ich noch testen.

Ebenfalls noch nicht ausprobiert habe ich die Funktion zum Importieren klassischer Widgets in Blöcke…

Struktur und Ordnung

Die Block-„Patterns“ sind neu geordnet und nach Kategorien gelistet, vergleichbar mit der Struktur die man vom Customizer kannte. Beim Bearbeiten lässt einen nun der neue „Ablenkungsfreie Modus“ weiterhin die Dashboard-Navigation und Adminleiste eingeblendet (ist mir wesentlich sympatischer als der Vollbildmodus).

Die Blocknavigation (Editorleiste oben links, Symbol mit drei versetzten horizontalen Linien) wurde erweitert. Sie zeigt weiterhin eine Liste der Blöcke an. In einem zweiten Tab geht es jedoch um Semantik. Dort kann man unter anderem die Anzahl der Zeichen, Wörter und die Lesezeit sehen. Darunter erhält man die Gliederungsansicht (Überschriften – offenbar mit Überprüfung nach Accessibility-Regeln. Wer beispielsweise eine H3 in einem Artikel verwendet, der noch keine H2 hat, wird darauf hingewiesen).

Blockstile kopieren und auf einen anderen Block übertragen geht nun über das jeweilige Blockmenü.

Google Fonts lokal integriert in WordPress Themes

Twenty Twelve bis Twenty Seventeen enthalten die verwendeten Schriften nun im Theme-Ordner, anstatt sie von Google Servern zu laden. Damit wird sichergestellt, dass die Themes den aktuellen Empfehlungen für die Einhaltung des Datenschutzes folgen.

Neue HTML API

Für Entwickler wird speziell der neue HTML Tag Processor interessant sein, über den via PHP Attribute gefunden, hinzugefügt oder entfernt werden können, um Block-Markup einfach und sicher anzupassen. Dies ist die erste Komponente der HTML-Verarbeitungs-API. Weitere Features sollen folgen.

Methoden


$p->get_tag()
$p->set_attribute()
$p->get_attribute()
$p->remove_attribute()
$p->add_class()
$p->remove_class()

Mehr darüber in der Entwickler-Dokumentation.

Block Patterns

Mit der Hilfsfunktion register_block_pattern können Block Patterns hinzugefügt, mit unregister_block_patterns vorhandene entfernt werden.

function my_plugin_register_my_patterns() {
    register_block_pattern( 
        'title'       => __( 'Pattern Name', 'my-plugin' ),
        'description' => _x( 'Pattern Description', 'my-plugin' ),
        'content'     => "<!-- ... -->",
    );
}
add_action( 'init', 'my_plugin_register_my_patterns' );

function my_plugin_unregister_pattern() {
    unregister_block_pattern( 'other-plugin/not-used-pattern' );
}
add_action( 'init', 'my_plugin_unregister_pattern' );

Auch Block-Pattern-Kategorien können über die API verwendet werden, hier ein Link, um das Thema zu vertiefen.

…. noch mehr? – Hier geht’s zum WordPress 6.2 Field Guide

Wer braucht da noch externe PageBuilder?

Der Block-Editor fing als kleines Licht an, und ohne Plugins die zusätzliche Blöcke und Features lieferten, war die Handhabung in den Anfängen eher dürftig. Doch mittlerweile kam ich zunehmend davon ab, Blöcke aus Fremdplugins zu verwenden. – Ich gehe davon aus, dass Flexibilität und Möglichkeiten mit den nächsten WordPress-Versionen weiter wachsen und freue mich bereits auf die praktische Anwendung der neuen Features.

Zugegeben, ich war nie ein Fan von Plugins wie Visual Bakery, Elementor, Divi und anderen PageBuildern. Mit dem Block-Editor und FSE gibt es keinen vernünftigen Grund mehr, auf Fremdplugins zu setzen. – Wer sich bisher nicht an FSE herangwagte: spätestens jetzt ist der Moment, damit anzufangen (oder auf Anbieter zu setzen, die WordPress gut genug kennen, um damit umgehen zu können).

Bitte Kommentarfunktion nicht für Supportanfragen nutzen. Dem kann hier nicht entsprochen werden. Die Angabe einer E-Mail-Adresse und eines Namens ist nicht erforderlich. Einen (Spitz)-Namen zu nennen wäre aber doch nett.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Sowohl angegebener Name als auch E-Mail-Adresse (beides ist optional, dafür werden alle Kommentare vor Veröffentlichung geprüft) werden dauerhaft gespeichert. Du kannst jeder Zeit die Löschung Deiner Daten oder / und Kommentare einfordern, direkt über dieses Formular (wird nicht veröffentlicht, und im Anschluss gelöscht), und ich werde das umgehend erledigen. – Mit hinterlassenen Kommentaren hinterlegte IP-Adressen werden nach zwei Monaten automatisch gelöscht

publicly queryable