Was ist neu in WordPress 5.8 (vollständige Seiten-Bearbeitung, WebP-Bilder, globale Stile und Einstellungen und vieles mehr)

WordPress 5.8 „Tatum“ ist da und es ist ein bedeutendes Release. Abgesehen von der unglaublichen Anzahl an Funktionen, Verbesserungen und Fehlerkorrekturen führt WP 5.8 eine neue Art der Erstellung von Webseiten ein, indem es die ersten Funktionen bringt, die unter das breitere Projekt fallen, das als Full Site Editing bekannt ist.

Abgesehen vom Full Site Editing bringt WordPress 5.8 eine Vielzahl von Änderungen und Verbesserungen in verschiedenen Bereichen des CMS.

WordPress-Nutzer, die das Gutenberg-Plugin nicht verwenden, finden Funktionen und Verbesserungen aus insgesamt neun Gutenberg-Releases (für einen tiefen Einblick in die einzelnen Releases siehe Gutenberg 9.9, 10.0, 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, 10.7).

Eine wichtige neue Funktion für Anwender, die es mit der Performance ihrer Seiten ernst meinen, ist die Unterstützung des WebP-Formats.

Entwickler werden sicherlich die Entfernung des IE11 von der Liste der unterstützten Browser, den neuen Mechanismus für die Blockkonfiguration und das Styling auf Basis von theme.json, das verbesserte Blockregistrierungssystem auf Basis von block.json und die vielen API-Verbesserungen, die mit der zweiten WordPress-Version 2021 kommen, lieben.

Bleib also ruhig sitzen, denn es wird eine ausführliche Zusammenstellung von Funktionen und Verbesserungen geben, die den Weg für neue leistungsstarke Tools für die Webseiten-Erstellung ebnen, die in den kommenden Monaten veröffentlicht werden.

Vollständige Webseiten-Bearbeitungsfunktionen in WordPress 5.8

Die Vision hinter Full Site Editing ist es, eine Sammlung von Werkzeugen und Funktionen bereitzustellen, die es WordPress-Benutzern ermöglichen, eine ganze Webseite mit Blöcken zu erstellen. Mit Full Site Editing stehen viele Blöcke zur Verfügung, um jedes Element auf der Seite zu erstellen, von Navigationsmenüs bis hin zu Seiten-Branding, Seitenleisten-Widgets, Vorlagen und vieles mehr.

Auch wenn WordPress 5.8 einige Features einführt, die in den Bereich des Full Site Editing (FSE) fallen, solltest du nicht erwarten, eine vollwertige visuelle Umgebung für die Erstellung von Seiten zu sehen. FSE befindet sich noch in der Entwicklung, und die Veröffentlichung von WordPress 5.8 eröffnet eine Art öffentliche Betaphase. Laut Josepha Haden Chomphosy:

Die vollständige Webseiten-Bearbeitung ist eine Sammlung von Projekten und zusammen stellen sie eine große Veränderung dar, wohl zu viel für eine einzelne Version. Der wichtigste Zusammenhang ist, dass es nicht als vollständige, standardmäßige Erfahrung für Benutzer ausgeliefert wird. Eines der deutlichsten Feedbacks aus dem Phase-One-Merge-Prozess war, dass es für unsere Extender (Agenturen, Theme-Autoren, Plugin-Entwickler, Site-Builder usw.) nicht genug Zeit gab, um sich auf die kommenden Änderungen vorzubereiten.

In diesem Sinne wird dieser Merge-Prozess kein Ein/Aus-Schalter sein. Der Fokus liegt jetzt nicht auf einer vollständigen und nuancierten Benutzererfahrung, sondern eher auf einer offenen öffentlichen Beta innerhalb von WordPress 5.8.

WordPress 5.8 führt also noch keine perfekte und vollständige FSE-Erfahrung ein. Stattdessen werden wir sehen, wie neue Funktionen im Laufe der Zeit hinzugefügt und verbessert werden, beginnend direkt mit Version 5.8. Aus dem gleichen Grund können wir davon ausgehen, dass WordPress 5.8 keine dramatischen Auswirkungen auf die Art und Weise haben wird, wie wir gewohnt sind, Webseiten zu erstellen.

Zum Zeitpunkt der Erstellung dieses Artikels müssen sich Seitenbetreiber und Admins noch bewusst für FSE entscheiden, indem sie ein Block-Theme wie Twenty-Twenty One Blocks (die blockbasierte Version von Twenty-Twenty One) installieren und das Gutenberg-Plugin aktivieren.

Die vollständige Seiten-Bearbeitung umfasst eine Reihe von separaten Unterprojekten, darunter den Seiten-Editor, die globalen Stile, den Abfrageblock, den Navigationsblock, Vorlagen, Blockthemen und vieles mehr.  Aber das, was dem Site Editing in WordPress 5.8 am nächsten kommt, ist der Template Editing Mode und die entsprechenden Theme-Blöcke, die in diesem Modus verwendet werden können, wie wir später in diesem Artikel sehen werden.

Als nächstes wollen wir uns einige FSE-Funktionen ansehen, die mit WordPress 5.8 in Core integriert wurden.

Templatebearbeitungsmodus

Der Templatebearbeitungsmodus bietet eine Möglichkeit, Post-/Seitenvorlagen mit Blöcken zu erstellen. Es ist eine großartige Möglichkeit, die Komplexität der Seiten-Erstellung zu reduzieren, indem Benutzer die Vorteile verschiedener Seiten-Bearbeitungsfunktionen von außerhalb der Seiten-Editor-Oberfläche nutzen können, während sie sich an die Arbeit mit Blöcken gewöhnen. Dies ist auch ideal für Benutzer, die keine blockbasierten Themes verwenden, aber dennoch eine einfache Möglichkeit suchen, Templates über die Benutzeroberfläche des Blockeditors zu erstellen und zu bearbeiten.

Das Anpassen von Themes war in WordPress noch nie so einfach wie jetzt. Jetzt musst du nicht mehr ein Child-Theme erstellen, um deine benutzerdefinierten Vorlagen zu erstellen. Die gute Nachricht ist, dass mit WordPress 5.8 die Template-Bearbeitung nicht auf Block-Themes beschränkt ist, sondern dir auch für klassische Themes zur Verfügung steht.

Um eine neue Vorlage zu erstellen, musst du nur den Templatebearbeitungsmodus in der Seitenleiste „Einstellungen“ aktivieren. Ein neues Templatebedienfeld ist jetzt für Benutzer verfügbar, um den Bearbeitungsmodus zu wechseln (siehe Gutenberg 10.5 Release Note).

Im Templatebedienfeld kannst du eine neue Vorlage erstellen oder eine vorhandene Vorlage bearbeiten.

Um eine neue Vorlage zu erstellen, klicke auf Neu. Gib dann im Modal einen Templatenamen ein und klicke auf Erstellen, und schon kannst du loslegen.

Im Templatebearbeitungsmodus kannst du deine Vorlagen mit allen verfügbaren Blöcken erstellen, einschließlich FSE-Blöcken wie Seiten Title, Seiten Tagline, Login/out und vielen anderen.

Wenn du mit deinen Bearbeitungen zufrieden bist, kannst du zurück in den Post-Editing-Modus wechseln und die Vorlage getrennt vom Inhalt des Beitrags/der Seite speichern, wie im Bild unten gezeigt:

Vorlagen werden in deiner WordPress-Datenbank als benutzerdefinierte Beitragstypen mit dem Namen wp_template gespeichert. Dadurch kannst du eine Vorlage nicht nur über die Editor-Oberfläche bearbeiten, sondern sie auch ganz einfach nach Belieben importieren oder exportieren. Du kannst eine Vorlage auch über verschiedene Webseiten hinweg verwenden (zum Zeitpunkt der Erstellung dieses Artikels ist diese Funktion nur verfügbar, wenn du das Gutenberg-Plugin aktivierst).

Der Templatebearbeitungsmodus ist zum Zeitpunkt dieses Schreibens noch ein wenig fehlerhaft, wie in diesem Aufruf zum Testen und diesem Experiment von Justin Tadlock berichtet wird.

Aber alles, was es braucht, ist ein wenig Geduld und das Warten auf die Behebung der wichtigsten Probleme, um zu verstehen, wie der Vorlagenbearbeitungsmodus die Art und Weise, wie du das Aussehen deiner Webseiten anpassen, verändern wird.

Die Benutzer benötigen keine Entwickler-Kenntnisse mehr, um die vollständige Kontrolle über das Layout und das Gesamtbild der Webseite zu erhalten.

Der Template Editing Mode war zunächst sowohl für Block Themes als auch für klassische Themes verfügbar. Nach einer ausführlichen Diskussion im 5.8 Leads Channel wurde beschlossen, den Template Editor für klassische Themes opt-in und für Block Themes opt-out zu machen (siehe auch Pull #32858).

Laut Carolina Nymark:

Ursprünglich war die Template-Bearbeitung für alle Themes aktiviert. Theme-Entwickler äußerten Bedenken, dass sie nicht alle ihre bestehenden klassischen Themes aktualisieren könnten, um diese neue Funktion zu unterstützen. In einer späten Änderung haben sich das Release Squad und das Editor Team dazu entschieden, die Template-Bearbeitung als Opt-In für klassische Themes zu aktivieren.

Um das Opt-in für klassische Themes zu ermöglichen, sollten die Entwickler nun den Theme-Support hinzufügen:

add_theme_support( 'block-templates' );

remove_theme_support(  'block-templates' );

Einen genaueren Überblick über die Funktionsweise des Template Editing Mode in WordPress 5.8 und einige nützliche Anwendungsbeispiele findest du in diesem Video von Anne McCarty:

Theme Blöcke

Wie bereits erwähnt, handelt es sich bei FSE nicht um ein einzelnes Feature, sondern um ein komplettes Set von Seiten-Building-Funktionen, die sich nicht nur auf den Seiten-Editor beziehen. Der Template-Editing-Modus ist nur ein Beispiel dafür. Aber zusammen mit der Template-Bearbeitung bringt WordPress 5.8 auch viele Theme-Blöcke, die dynamisch aus der Datenbank abgerufene Informationen anzeigen können. Einige dieser Blöcke können auch in Nicht-FSE-Kontexten verwendet werden (siehe Ausgabe #28744).

Theme-Blöcke bringen Template-Tag-Funktionalitäten in klassische Themes, und du kannst sie auf die gleiche Weise wie reguläre Blöcke verwenden. So kannst du z. B. Post-Tags oder das Featured Image des Posts an beliebiger Stelle im Post-Inhalt oder in der Vorlage einfügen. Um eine Vorstellung von der Anzahl der Theme-Blöcke zu bekommen, die mit WordPress 5.8 zum Kern hinzugefügt wurden, gib einfach /post in den Block-Platzhalter ein:

Ein hilfreicher Theme-Block, der mit WordPress 5.8 verfügbar ist, ist der Login/out-Block, der Login- und Logout-Links bereitstellt. Er kann optional das Anmeldeformular anstelle eines Links anzeigen. Seiten-Administratoren können auch das Umleitungsziel anpassen (siehe PR #29766).

Eine genauere Betrachtung der FSE-Blöcke findest du in der Ausgabe „Enabling Full Site Editor blocks in classic themes“ auf Github.

Der Abfrage-Schleifenblock

Wie oft hast du dich schon in einer Situation befunden, in der du eine benutzerdefinierte Liste von Blogbeiträgen oder benutzerdefinierten Beitragstypen anzeigen musst? Denke an Produkte, Veranstaltungen, Immobilien… Natürlich hast du dafür tonnenweise Plugins zur Auswahl, aber die Möglichkeit, stark angepasste Abfragen zu erstellen, erfordert oft Entwicklerfähigkeiten, um sich mit der WordPress-Schleife auseinanderzusetzen.

Mit der Einführung des Query-Loop-Blocks in WordPress Core können Webseiten-Besitzer und Admins Listen von Beiträgen und CPTs erstellen, ohne komplexen Code schreiben oder einen Entwickler einstellen zu müssen, zumindest in den häufigsten Anwendungsfällen.

Was macht also der Query Loop Block?

Kurz gesagt, es macht die gleiche Arbeit wie die WordPress-Schleife, aber im visuellen Kontext des Blockeditors.

Der Block „Query Loop“ führt eine Abfrage basierend auf den Einstellungen des Benutzers über die WordPress-Datenbank aus, durchläuft jeden abgerufenen Beitrag in einer Schleife und zeigt die Daten auf der Seite an.

Nach intensiver Entwicklung hat dieser Block seine heutige Struktur erreicht und besteht nun aus zwei verschachtelten Blöcken: den Blöcken Query und Post Template.

Da es sich um eine erweiterte Funktion handelt, erfordert der Query Loop-Block einige Konfigurationen.

Zunächst kannst du zwischen verschiedenen Blockmustern wählen, die in der Karussell- und Rasteransicht aufgelistet sind. Sobald du dein Muster ausgewählt hast, klicke einfach auf Auswählen, und der Query Loop-Block generiert deine benutzerdefinierte Liste von Beiträgen.

Wenn du auf Start blank klickst, siehst du eine Liste mit vier Kernblockvarianten: Titel & Datum; Titel & Auszug; Titel, Datum & Auszug; und Bild, Datum & Titel ( siehe Angebotsmuster bei Blockaufbau).

Wenn du den Abfrage-Schleifenblock ausgewählt hast, wird die Seitenleiste mit den Blockeinstellungen angezeigt, in der du deine Abfrage erstellen kannst. Du kannst die Abfrage entweder von der URL übernehmen oder die Abfrageargumente anpassen: die Art der Beiträge, die in die Liste aufgenommen werden sollen, die Anzeigereihenfolge und ob es Sticky Posts geben soll oder nicht.

Du kannst auch mehrere Filter setzen und aus Kategorien, Autoren und Stichwörtern wählen.

Zusätzlich bietet eine Schaltfläche Anzeigeeinstellungen in der Symbolleiste des Blocks weitere Einstellungen zur Steuerung der Anzahl der Elemente pro Seite, des Versatzes und der maximalen Anzahl der anzuzeigenden Seiten.

Ja, der Query-Loop-Block ist ein mächtiges Werkzeug, mit dem Webseiten-Betreiber hochgradig angepasste Listen von Beiträgen und benutzerdefinierten Beitragstypen erstellen können.

Aber wenn du die Parameter der Klasse WP_Query durchgehst, ist es klar, dass der Grad der Anpassung, der mit dem Code möglich ist, viel granularer ist als das, was mit dem Query Loop-Block möglich ist.

Nichtsdestotrotz ist es ein wertvolles und flexibles Werkzeug, das sich für viele Anwendungsfälle eignet, und wir werden höchstwahrscheinlich in Zukunft weitere Verbesserungen sehen.

Persistente Listenansicht im Post-Editor

Eine weitere FSE-Funktion, die auf den Post-Editor erweitert wurde, ist die persistente Listenansicht. Vor WordPress 5.8 (und Gutenberg 10.7) wurde die Listenansicht in einem Popover angezeigt. Wenn man den Fokus außerhalb des Popovers bewegte, verschwand die Liste.

Umgekehrt zeigte der Seiten-Editor die Listenansicht in einer Seitenleiste an, die den gesamten Blockbaum enthielt.

Mit WordPress 5.8 wird die Listenansicht nun in einer Seitenleiste im Beitragseditor angezeigt, so dass der Benutzer schneller und präziser im Blockbaum navigieren kann.

Wenn du auf ein Element in der Listenansicht klickst, wird das Listenelement hervorgehoben und der Fokus auf den entsprechenden Block im Post-Editor-Canvas verschoben. Wenn du außerdem den Mauszeiger über die Elemente in der Listenansicht bewegst, werden sowohl das Element als auch der entsprechende Block im Post-Editor hervorgehoben.

Last, adding an anchor to a block will also appear next to the corresponding item in the list view.

Mit all diesen Erweiterungen der Listenansicht sollte die Navigation in komplexen Dokumenten wesentlich einfacher sein.

Blockbasierter Widgets-Editor und Block-Widgets im Customizer

Der blockbasierte Widgets-Editor ist ein umfangreiches Projekt, das darauf abzielt, die Oberfläche des Block-Editors auf Widgets des klassischen Themes zu übertragen.

Der neue Widgets-Editor bietet viele Vorteile für die große Mehrheit, die noch klassische Themes verwendet. Gleichzeitig erlaubt er ihnen, sich mit der Block-Schnittstelle vertraut zu machen, bevor sie zum Standard für alle WordPress-Nutzer wird.

Wie Anne McCarty hervorhebt, bieten blockbasierte Widgets mehrere Vorteile, darunter die folgenden:

• Du kannst jetzt Layouts in Seitenleisten, Kopf- und Fußzeilen mithilfe von Spalten, Trennlinien, Abstandshaltern und anderen Designblöcken erstellen.
• Widgets unterstützen jetzt standardmäßig Rich-Text-Bearbeitung, ohne dass der Benutzer eigenen Code hinzufügen oder einen HTML-Editor eines Drittanbieters mit einem Plugin einbetten muss.
• Viele Shortcode-basierte Widgets sind jetzt als Blöcke verfügbar, wodurch die Bearbeitung vereinfacht wird.

Andrei Draganescu hebt auch die Vorteile hervor, die sich aus der Möglichkeit ergeben, Widgets über eine blockbasierte Oberfläche zu bearbeiten:

Der Hauptvorteil des Upgrades der Widgets-Funktionalität auf Blöcke liegt in der Möglichkeit, Widgets direkt mit der vertrauten Block-Interaktion zu bearbeiten, die du beim Bearbeiten einer Seite oder eines Beitrags auf deiner Seite verwendest. Die Möglichkeit, Blöcke zu verwenden, eröffnet tonnenweise neue kreative Möglichkeiten, von No-Code-Mini-Layouts bis hin zum Anzapfen der riesigen Bibliothek von Core- und Drittanbieter-Blöcken zur Erstellung von Inhalten.

Du musst dir keine Sorgen machen, dass deine Widgets mit WordPress 5.8 nicht mehr funktionieren, denn die Community hat hart daran gearbeitet, Abwärtskompatibilität zu gewährleisten, so dass „bestehende Widgets und Widgets von Drittanbietern weiterhin funktionieren und neben Blöcken verwendet werden können“ (siehe Block-basierter Widgets-Editor in WordPress 5.8).

Aber auch hier gilt: Um Kompatibilitätsprobleme mit deiner bestehenden WordPress-Installation zu vermeiden, vergiss nicht, die neue Version in einer Staging-Umgebung zu testen, bevor du deine Live-Seite aktualisierst.

Für diejenigen unter euch, die den blockbasierten Widgets-Editor im Moment nicht verwenden möchten, ist es immer noch möglich, den klassischen Widgets-Bildschirm auf drei verschiedene Arten wiederherzustellen:

1. Du kannst das offizielle Classic Widgets-Plugin installieren, das die vorherige Oberfläche des Widgets-Bildschirms wiederherstellt. Das Plugin „wird bis mindestens 2022 unterstützt und gewartet, oder so lange wie nötig“.
2. Theme-Entwickler können den blockbasierten Widgets-Editor deaktivieren, indem sie wie gewohnt die Theme-Unterstützung entfernen: remove_theme_support( 'widgets-block-editor' );
3. Ein neuer Filter use_widgets_block_editor kann ebenfalls verwendet werden:

   add_filter( 'use_widgets_block_editor', '__return_false' );

Siehe auch Wiederherstellung des klassischen Widgets-Editors in Widgetblock-Editor Übersicht.

Widgets für den Customizer blockieren

Als Teil desselben Projekts bringt WordPress 5.8 auch Block-Widgets in den Customizer.

Das Hinzufügen eines blockbasierten Widgets im Customizer ist ziemlich einfach. Du kannst den Widgets-Inserter zum Anpassen starten, indem du auf das Plus-Symbol in der oberen rechten Ecke des Widgets-Bedienfelds klickst.

Du kannst den Quick-Inserter auch vom unteren Rand des Widgets-Bedienfelds aus starten, wie in der folgenden Abbildung gezeigt.

Zum Zeitpunkt der Erstellung dieses Artikels erfordert die neue Widget-Bearbeitungsoberfläche noch Verbesserungen und Fehlerbehebungen, aber die Möglichkeiten zur Anpassung sind praktisch unbegrenzt.

Grundsätzlich hast du ab WordPress 5.8 die Möglichkeit, den Block-Editor im Customizer zu nutzen, und du kannst problemlos hochgradig angepasste Sidebars erstellen.

Die Dev-Note zum blockbasierten Widgets-Editor bietet einen tieferen Überblick über den blockbasierten Widgets-Editor, mit Beispielen und Ressourcen für Entwickler.

Funktionen und Verbesserungen des Blockeditors

Neben der ersten FSE-Implementierung bringt WordPress 5.8 auch neue Funktionen und Verbesserungen an mehreren Elementen des Block-Editors, die das gesamte Bearbeitungserlebnis deutlich verbessern.

Diese Änderungen umfassen:

Erweiterungen für Medien- und Textblöcke

Das Umwandeln eines Blocks in einen Spaltenblock ist schon seit einiger Zeit möglich. Allerdings werden alle Blöcke, die in Spaltenblöcke umgewandelt werden, mit einer einzelnen Spalte dargestellt. Dies könnte zu suboptimalen Ergebnissen für den Medien- & Textblock führen, für den eine einzelne Spalte meist nicht geeignet ist.

Ab WordPress 5.8 (und Gutenberg 10.2) fügt die Umwandlung des Medien- & Textblocks in einen Spaltenblock automatisch zwei Spalten hinzu: eine für das Bild und eine für den Text.

Wiederverwendbare Blöcke Verbesserungen

Wiederverwendbare Blöcke ermöglichen es dem Benutzer, einen Block oder eine Gruppe von Blöcken zu speichern, um sie später in einem beliebigen Beitrag oder einer Seite einer Webseite wiederzuverwenden. Dies ist vor allem für Benutzer nützlich, die wiederholt denselben Block oder dieselbe Gruppe von Blöcken in verschiedene Beiträge/Seiten einfügen.

Mit WordPress 5.8 sind wiederverwendbare Blöcke optisch übersichtlicher und damit für WordPress-Anwender leichter zu verwalten.

Hier ist eine kurze Liste von wiederverwendbaren Block-Verbesserungen, die Benutzer nach dem Update ihrer Webseiten auf WordPress 5.8 finden werden:

• Beim Erstellen eines wiederverwendbaren Blocks kann der Benutzer nun in einem Modal einen Namen für den Block vergeben.
• Der Name des wiederverwendbaren Blocks wird jetzt in der Blocksymbolleiste, der Navigationsliste und den Breadcrumbs angezeigt.
• Wenn ein untergeordneter Block ausgewählt ist, werden wiederverwendbare Blöcke jetzt umrandet. Dies stellt eine erhebliche Verbesserung der Benutzerfreundlichkeit dar, da du den übergeordneten Block und dessen Inhalt leicht identifizieren kannst.
• Es ist jetzt möglich, den Blocknamen im Inspektor der Seitenleiste zu ändern.

Symbolleiste für normalisierte Bildblöcke

Mehrere Block-Symbolleisten wurden neu angeordnet, um eine einheitliche Benutzeroberfläche für alle Blöcke zu schaffen und die Benutzerfreundlichkeit zu verbessern. Die Steuerelemente der Symbolleiste sind jetzt in der semantischen Reihenfolge „Meta, Blockebene, Inline“ gruppiert.

Seit Gutenberg 10.1 und Gutenberg 10.3 ist eine ganze Reihe von Blocksymbolleisten normalisiert worden. Dazu gehören ein Bild, eine Schaltfläche, Schaltflächen, eine Liste, eine Überschrift, ein Absatz, ein Zitat, Audio, eine Datei, Medien & Text, ein Video und mehr.

Laut Matias Ventura:

Die semantischen Gruppierungen, die wir in der Symbolleiste haben – Meta, Blockebene, Inline – sollten auch eine visuelle Darstellung mit den Rändern haben. Im Moment haben separate Steuerelemente auf Blockebene unterschiedliche Darstellungen, einschließlich Fällen wie Navigation, wo jedes einzelne einen Rahmen hat.

So gruppiert die Block-Symbolleiste seit WordPress 5.8 Steuerelemente in Segmenten, die von Rahmen umgeben sind. Darüber hinaus:

• Das Meta-Segment enthält blockartige Steuerelemente, wie z. B. den Blockumschalter, den Ziehgriff und das Verschiebe-Steuerelement.
• Das Segment der Blockebene enthält spezifische Blockwerkzeuge, die den gesamten Inhalt betreffen, z. B. die Ausrichtung in einem Absatzblock oder die Verlinkung in einem Bildblock.
• Das Segment Inline-Ebene/Sonstiges enthält Inline-Transformationswerkzeuge, wie z. B. die Inline-Formatierung in einem Textblock.
• Das Menü „Mehr“ enthält zusätzliche Werkzeuge.

Das Bild unten vergleicht die Symbolleiste des Bildblocks in WordPress 5.7 und 5.8:

Verbesserungen der oberen Symbolleiste

Wenn der Modus für die obere Symbolleiste in früheren WordPress-Versionen aktiviert war, wurden die obere Symbolleiste und die Block-Symbolleiste nebeneinander angezeigt, wie in der folgenden Abbildung dargestellt:

Mit WordPress 5.8 wird durch das Aktivieren der oberen Symbolleisten-Ansicht die Block-Symbolleiste am oberen Rand des Editors fixiert, direkt unterhalb der oberen Symbolleiste. Dies geschieht unabhängig von der Browserbreite und sollte das Benutzererlebnis deutlich verbessern.

Diese Erweiterung bringt auch Änderungen für Entwickler, da sie Toolbar-APIs unter der <BlockTools />-Komponente vereinheitlicht (siehe PR #31134).

Eingebettete PDFs

Wenn eine PDF-Datei über den Dateiblock in das Dokument eingefügt wird, ermöglicht ein neuer Toggle in der Seitenleiste die Aktivierung/Deaktivierung einer eingebetteten PDF-Version (siehe PR #30857).

Du kannst die Datei entweder direkt auf die Arbeitsfläche des Editors ziehen oder sie einfach aus der Bibliothek auswählen. Es ist auch möglich, die Höhe des PDF-Viewers manuell oder über die Seitenleistensteuerung anzupassen.

Alle wichtigen Webbrowser unterstützen den PDF-Viewer, mit Ausnahme von mobilen Browsern.

Duotone Block Support

Eine der interessantesten Funktionen, die mit WordPress 5.8 in Core integriert wurde, ist der Duotone-Filter, der erstmals mit Gutenberg 10.6 eingeführt wurde.

Der Duotone-Filter ist als „Blockunterstützungsfunktion“ verfügbar und ist standardmäßig in Corebild– und Cover-Blöcken aktiviert. Im Cover-Block funktioniert er jedoch nicht bei festen Hintergründen.

Die Symbolleisten für Bilder und Deckblöcke zeigen jetzt ein Steuerelement für das Anwenden von Duotone-Filtern an, das einen Duotone-Picker mit vielen Voreinstellungen zur Auswahl zeigt.

Zwei Untersteuerungen erlauben die separate Anpassung von Schatten und Glanzlichtern. Der Effekt wird mit einem SVG-Filter angewendet, der mit Inline-Styles ausgeblendet und mit einem bestimmten Klassennamen angewendet wird.

Das neue Werkzeug kommt in Verbindung mit einer neuen Eigenschaft color.__experimentalDuotone, die es Entwicklern ermöglicht, den Duotone-Filter zu Blöcken oder Teilen von Blöcken in ihrer block.json-Datei hinzuzufügen (mehr dazu in der Farbobjekt-Referenz):

supports: {
	color: {
		__experimentalDuotone: '> .duotone-img, > .duotone-video',
		background: false,
		text: false
	}
}

Wenn ein Block Unterstützung für color.__experimentalDuotone deklariert, kann ein style-Attribut verwendet werden, um benutzerdefinierte Standardfarben festzulegen:

attributes: {
	style: {
		type: 'object',
		default: {
			color: {
				duotone: [
					'#FFF',
					'#000
				]
			}
		}
	}
}

Unten siehst du das selbe Bild mit zwei verschiedenen angewandten Duotone-Effekten:

Entwickler können Duotone-Voreinstellungen in der Datei theme.json (siehe nächster Abschnitt) definieren, wie im folgenden Ausschnitt gezeigt:

{
"version": 1,
"settings": {
	"color": {
		"duotone": [
			{
				"colors": [ "#000", "#7f7f7f" ],
				"slug": "black-and-white",
				"name": "dark-grayscale"
			}
		],
	...

Mehr über Duotone-Filter kannst du unter Coloring Your Images With Duotone Filters nachlesen.

Tabellenblockfarben und -ränder

WordPress 5.8 bringt auch eine Reihe von Verbesserungen für den Tabellenblock, einschließlich einer besseren Kontrolle über die Hintergrund- und Vordergrundfarben der Tabelle.

Eine weitere Ergänzung des Tabellenblocks ist die Unterstützung des Rahmenblocks, der dem Benutzer die Möglichkeit gibt, Farbe, Stil und Breite des Rahmens zu steuern.

Wenn das aktive Theme die neue Funktion unterstützt, bietet ein neues Rahmeneinstellungsfeld drei neue Steuerelemente für Benutzeranpassungen.

Entwickler können die Unterstützung für Randblöcke zu ihren Themes hinzufügen, indem sie den folgenden Code in die Datei theme.json einfügen:

"border": {
	"customColor": true,
	"customStyle": true,
	"customWidth": true
}

Verbesserungen am Blockeinsetzer

In WordPress 5.8 wurde der Block-Inserter mit einigen Ergänzungen versehen (PR #26938 und #21080):

1. Zweidimensionale Tastaturnavigation auf dem Block-Inserter. Jetzt können wir zwischen Blöcken präziser und intuitiver navigieren.

• Durch Drücken von Pfeil nach oben (↑) und Pfeil nach unten (↓) wird der Fokus auf die Zeile darüber bzw. darunter gesetzt.
• Durch Drücken der Tabulatortaste oder Umschalttaste + Tabulator kannst du den Fokus zwischen dem Suchfeld, der Tabulatorliste und dem ersten Element jeder Kategorie verschieben.

2. Eine neue „Theme“-Kategorie für Template-Teile und -Variationen erscheint nun im Inserter in Full Site Editing (siehe PR #30020).

3. Mehrere Wörter in der automatischen Vervollständigung von Phrasen sind jetzt erlaubt (siehe PR #29939).

Zusätzliche Verbesserungen im Block-Editor

WordPress 5.8 bringt eine Menge zusätzlicher kleiner und mittlerer Änderungen, die hier ein paar Zeilen wert sind. Unter diesen Verbesserungen würden wir die folgenden erwähnen:

Drag-and-Drop-Unterstützung in Abdeckblöcken

Jetzt kannst du Bilder von deinem Desktop ziehen und ablegen, um den Hintergrund eines Titelblocks zu ersetzen (siehe Gutenberg 10.3 und PR #29813).

Verbessertes Publishing UI

Seit WordPress 5.8 zeigt die Veröffentlichungs-UI das Seiten-Symbol und den Titel an, um deutlicher zu machen, wo du deine Beiträge oder Seiten veröffentlichen wirst (Gutenberg 10.4).

Diese Erweiterung ist von Vorteil, wenn du im Vollbildmodus oder auf mobilen Geräten arbeitest.

Blockeinstellungen und Stile mit theme.json

Mit WordPress 5.8 wird die Datei theme.json zu einem „zentralen Punkt der Konfiguration“ und bietet eine neue Möglichkeit für Theme-Entwickler, Editor-Einstellungen und Stile anzupassen.

Mithilfe einer theme.json-Datei können Themes benutzerdefinierte Voreinstellungen festlegen und/oder Unterstützung für neue Funktionen, wie z. B. Duotone und Tabellenränder, hinzufügen (siehe Globale Einstellungen & Stile).

Laut André Maneiro:

Dieser neue Mechanismus soll die verschiedenen add_theme_support-Aufrufe, die bisher zur Steuerung des Editors erforderlich waren, übernehmen und konsolidieren.

Du kannst zum Beispiel mit dem folgenden Code eine benutzerdefinierte Duoton-Voreinstellung global festlegen:

{
	"version": 1,
	"settings": {
		"color": {
			"duotone": [
				{
					"colors": [ "#000", "#0FF" ],
					"slug": "black-cyan",
					"name": "Black Cyan"
				}
			],

Dies würde die Standardvorgaben überschreiben, und du siehst nur eine Duotone-Option:

Der neue Mechanismus bietet eine Möglichkeit, die Einstellungen entweder global oder auf Basis einzelner Blöcke zu steuern. Du kannst z. B. eine benutzerdefinierte 12px-Schriftgröße global hinzufügen, indem du die folgende Voreinstellung zu deiner theme.json-Datei hinzufügst:

{
	"version": 1,
	"settings": {
		"typography": {
			"customLineHeight": true,
			"fontSizes": [
				{
					"slug": "extra-extra-small",
					"size": "12px",
					"name": "Extra extra small"
				},
				{...}

Dadurch steht dem Benutzer eine neue Schriftgröße zur Verfügung, die er für jeden Text in seinem Inhalt verwenden kann.

Wenn du nur den Absatzblock anpassen möchtest, wird dein Code etwas anders aussehen:

{
	"version": 1,
	"settings": {
		"blocks": {
			"core/paragraph": {
				"typography": {
					"fontSizes": [
						{
							"slug": "extra-extra-small",
							"size": "12px",
							"name": "Extra extra small"
						},
						{
							"slug": "extra-small",
							"size": "16px",
							"name": "Extra small"
						},
						{
							"slug": "small",
							"size": "18px",
							"name": "Small"
						},
						{
							"slug": "normal",
							"size": "20px",
							"name": "Normal"
						},
						{
							"slug": "large",
							"size": "24px",
							"name": "Large"
						}
					]
				}
			}
		}
	}
}

Das war’s! Du hast gerade deine benutzerdefinierten Schriftgrößenvorgaben für den Absatzblock festgelegt.

Coreblöcke wurden aktualisiert, um dem neuen Mechanismus zu folgen, während Blöcke von Drittanbietern mit dem React useSetting-Hook an den neuen Mechanismus angepasst werden können (lies mehr über diese Funktion in der Dev-Note und API-Dokumentation):

const isEnabled = useSetting( 'spacing.margin' );

Der neue Mechanismus, der auf der Datei theme.json basiert, gilt nicht nur für Blockeinstellungen. Tatsächlich wird es ab WordPress 5.8 nicht mehr notwendig sein, Editor-Stile zu erstellen und sie in die Warteschlange zu stellen. Es wird genügen, Presets in der theme.json-Datei zu deklarieren; die Engine wird die Klassen generieren und sie automatisch sowohl an den Editor als auch an das Frontend enqueuen.

Die Engine generiert auch die entsprechenden benutzerdefinierten CSS-Eigenschaften.

Im vorherigen Beispiel haben wir fünf fontSizes-Voreinstellungen für den Absatzblock festgelegt. Für diese Voreinstellungen werden die folgenden benutzerdefinierten CSS-Eigenschaften generiert:

p {
	--wp--preset--font-size--extra-extra-small: 12px;
	--wp--preset--font-size--extra-small: 16px;
	--wp--preset--font-size--small: 18px;
	--wp--preset--font-size--normal: 20px;
	--wp--preset--font-size--large: 24px;
}

Sobald du die Absatzschriftgröße in deiner theme.json-Datei festgelegt hast, erhält das entsprechende p-Element die Klasse has-{preset-slug}-{preset-category}.

Das bedeutet, dass ein Absatz mit einer extra-extra-small Schriftgröße die Klasse has-extra-extra-small-font-size erhält:

<p class="has-extra-extra-small-font-size">Lorem ipsum dolor...</p>

Und hier ist der CSS-Deklarationsblock:

p.has-extra-extra-small-font-size {
	font-size: var(--wp--preset--font-size--extra-extra-small) !important;
}

Für eine genauere Betrachtung der Einstellungen und Stile mit theme.json solltest du dir die Dev-Note und die API-Dokumentation ansehen.

Lies auch den FSE-Aufruf zum Testen von Anne McCarty für weitere nützliche Lektüre und eine spannende Herausforderung für Entwickler, die die neuen theme.json-Funktionen erkunden möchten.

Erweiterungen der Block-API

Die Erweiterungen der Block-API, die mit WordPress 5.8 kommen, verdienen die besondere Aufmerksamkeit von Plugin-Entwicklern.

Die Verwendung der Datei block.json wird nun als kanonischer Weg zur Registrierung von Blocktypen empfohlen und bietet mehrere Vorteile:

• Wenn das Thema „Lazy Loading“ von Assets unterstützt, wird durch die Registrierung von Blocktypen über die Datei „block.json“ das Enqueueing von Ressourcen automatisch optimiert, was die Leistung betrifft. Das liegt daran, dass die von den style– und scripteigenschaften angegebenen Ressourcen nur dann auf dem Frontend eingereiht werden, wenn der Block erkannt wird. Dies ermöglicht die Entwicklung von effizienteren Plugins, reduziert die Seitengröße und verhindert mehrere der in diesem Artikel behandelten Probleme.
• Die Datei „block.json“ vereinfacht die serverseitige Blockregistrierung, indem sie es dem REST-API-Endpunkt „Block Types“ ermöglicht, den Block aufzulisten.
• Die Datei block.json wird auch benötigt, wenn du dich entscheidest, dein Block-Plugin an das WordPress-Plugins-Verzeichnis zu übermitteln.

Änderungen an der Funktion register_block_type

Seit WordPress 5.8 wurde die Funktion register_block_type erweitert, um Metadaten aus der Datei block.json zu lesen. Jetzt akzeptiert der erste Parameter den Pfad zum Ordner, in dem sich die block.json-Datei befindet.

Die Funktion kann wie im folgenden Beispiel gezeigt verwendet werden:

function create_custom_block_init() {
	register_block_type( __DIR__ );
}
add_action( 'init', 'create_custom_block_init' );

Es gibt den registrierten Blocktyp oder bei Fehlschlag false zurück.

Wie du vielleicht bemerkst, wird die Funktion register_block_type jetzt auf die gleiche Weise verwendet wie die Funktion register_block_type_from_metadata, die bisher die einzige Funktion war, die zum Registrieren eines Blocktyps durch Lesen der Metadaten aus der Datei block.json zur Verfügung stand. Wie von Greg Ziółkowski erklärt:

Wir haben uns entschlossen, die bereits vorhandene Funktionalität, die mit der Methode register_block_type_from_metadata zur Verfügung steht, in register_block_type zu konsolidieren, um einige Verwirrungen zu vermeiden, die dadurch entstanden sind. Es ist immer noch möglich, beide Funktionen zu verwenden, aber wir planen, von nun an nur noch die kürzere Version in den offiziellen Dokumenten und Tools zu verwenden.

Sobald der Block auf dem Server registriert ist, musst du nur noch die Einstellungen auf dem Client mit demselben Blocknamen in deiner index.js-Datei registrieren.

Einen detaillierteren Überblick über die mit WordPress 5.8 eingeführten Block-API-Erweiterungen findest du in der Dev-Note von Greg Ziółkowski.

WebP-Unterstützung in WordPress 5.8

Hier bei Kinsta sind wir besessen von der Geschwindigkeit von Webseiten und der Leistung von WordPress. Deshalb ist die Unterstützung des WebP-Formats in WordPress 5.8 eine so aufregende Neuigkeit für uns.

WebP gilt als ein Format der nächsten Generation und ist ein von Google entwickeltes Bildformat, das „eine bessere Komprimierung als PNG oder JPEG bietet, was schnellere Downloads und weniger Datenverbrauch bedeutet.“

Laut Google:

WebP ist ein modernes Bildformat, das eine hervorragende verlustfreie und verlustbehaftete Komprimierung für Bilder im Web bietet. Mit WebP können Webmaster und Webentwickler kleinere, reichhaltigere Bilder erstellen, die das Web schneller machen.

WebP-verlustfreie Bilder sind im Vergleich zu PNGs um 26 % kleiner. Verlustbehaftete WebP-Bilder sind bei gleichem SSIM-Qualitätsindex 25-34 % kleiner als vergleichbare JPEG-Bilder.

Ab WordPress 5.8 kannst du das WebP-Bildformat genauso nutzen wie die Formate JPEG, PNG und GIF. Lade deine Bilder einfach in deine Medienbibliothek hoch und füge sie in deine Inhalt ein.

In einem früheren Artikel haben wir einen ausführlichen Blick auf das WebP-Format und die verfügbaren Tools zur Verwendung in WordPress geworfen. Nun, aufgrund der Unterstützung für WebP-Bilder in WordPress 5.8, Dinge ändern sich ein wenig. Da das WebP-Format von Haus aus unterstützt wird, musst du keine Plugins von Drittanbietern installieren, um WebP-Bilder in WordPress hochzuladen, zumindest nicht in den häufigsten Anwendungsfällen.

Beachte, dass, obwohl du jetzt deine WebP-Bilder über die Medienbibliothek in WordPress hochladen kannst, WordPress keine automatische Bildkonvertierung in das WebP-Format unterstützt. Um diese Funktion auf deiner Webseite zu aktivieren, benötigst du ein WebP-WordPress-Plugin eines Drittanbieters.

Wie man WebP-Bilder in WordPress verwendet

Du kannst deine Bilder auf viele verschiedene Arten in WebP konvertieren:

• Du kannst die vorkompilierten WebP-Dienstprogramme und die Bibliothek von Google für Linux, Windows oder Mac OS X verwenden.
• Mac-Benutzer können einen Paketmanager wie das Homebrew WebP-Paket oder das Macports WebP-Paket installieren.
• Du kannst ein Bildbearbeitungsprogramm verwenden, das WebP unterstützt, z. B. Squoosh von Google Chrome Labs, den Batch-Bildkonverter XnConvert, ein beliebtes Bildbearbeitungsprogramm wie GIMP und viele andere.
• Du kannst ein WebP-WordPress-Plugin installieren, um eine bessere Gesamtkontrolle über WebP-Bilder in WordPress zu erhalten.

Wenn du dich für ein Befehlszeilenwerkzeug entscheidest, kannst du deine Bilder mit den Dienstprogrammen cwebp und dwebp kodieren und dekodieren. Der folgende Befehl führt zum Beispiel eine einfache JPEG-zu-WebP-Konvertierung aus:

cwebp [options] original_image.jpg -o compressed_image.webp

Du kannst auch eine Massenkonvertierung deiner Bilder mit der Bash und cwebp durchführen (Beispiel von Jeremy Wagner):

find ./ -type f -name '*.png' -exec sh -c 'cwebp -q 75 $1 -o "${1%.png}.webp"' _ {} \;

Der obige Befehl konvertiert alle .png-Bilder in das .webp-Format mit einem Kompressionsfaktor von 75.

Sobald du deine WebP-Bilder hast, kannst du sie einfach über die WordPress-Medienbibliothek hochladen. Unten siehst du ein 127 KB großes JPEG-Bild vor der Konvertierung in der Medienbibliothek:

Die komprimierte WebP-Bildgröße ist 42 % kleiner als das ursprüngliche JPEG-Bild!

Schließlich haben WebP-Bilder die selben Bearbeitungsfunktionen wie JPEG-, PNG- und GIF-Bilder. Du kannst sie zuschneiden, drehen, spiegeln und skalieren sowie Änderungen an den Bildgrößen deiner Wahl vornehmen.

Vorbehalte gegen WebP in WordPress 5.8

Nach Adam Silverstein:

WebP-Bilder unterstützen verlustbehaftete und verlustfreie Komprimierung, sowie ein animiertes Format und Unterstützung für transparente Bilder. In WordPress wird das verlustfreie WebP-Format nur unterstützt, wenn der Hosting-Server Imagick (die PHP-Bibliothek) verwendet, bis LibGD Unterstützung hinzufügt. Außerdem werden animierte und Alpha-Formate noch nicht für größenveränderte Bilder unterstützt (wenn du Bilder in diesen Formaten hochlädst, werden stattdessen verlustbehaftete Bilder erstellt).

Wenn dein Webhost keine WebP-Bilder unterstützt, bekommst du eine Fehlermeldung, wenn du versuchst, sie hochzuladen. Wenn du nicht sicher bist, ob dein Webhost die Imagick-Bibliothek unterstützt, findest du auf der Registerkarte „Info“ des Tools „Site Health“ ein Feld für die Imagick-Bibliothek, das diese Information enthält.

Mit der WebP-Unterstützung führt WordPress 5.8 auch zwei zusätzliche Felder in den Abschnitt Medienbehandlung in Site Health ein: Die ImageMagick-Version und die von ImageMagick unterstützten Dateiformate.

Wenn WebP nicht unter den unterstützten Dateitypen aufgeführt ist, musst du dich an deinen Webhost wenden, um Unterstützung zu erhalten.

Die Dev-Note bietet zusätzliche Informationen zur WebP-Unterstützung in WordPress 5.8, hilfreiche FAQs und weitere Ressourcen.

Wenn du dich für das Thema Bildoptimierung interessierst, könnten dir auch die folgenden Tutorials gefallen:

• Optimieren von Bildern für Web und Leistung
• Warum und wie du verlustbehaftete Komprimierung für deine WordPress-Bilder verwendst
• Verwendung von WebP-Bildern in WordPress (und Verkleinerung der Bilddateigrößen um bis zu 35 %)
• 15 Beste Bilddateitypen
• Alles, was du über WordPress-Bildgrößen wissen musst

Zusätzliche Funktionen für Entwickler

In WordPress 5.8 findest du Dutzende von spannenden Funktionen für Entwickler. In diesem Artikel haben wir denjenigen mehr Aufmerksamkeit gewidmet, die den größten Einfluss auf deine Entwicklungsarbeit haben sollten. Aber es gibt in der Tat viele neue Funktionen, die Aufmerksamkeit verdienen, darunter die folgenden:

Block Unterstützt API

WordPress 5.8 fügt neue Block-Support-Flags hinzu, die es Entwicklern ermöglichen, registrierte Blöcke mit den neuesten Blockfunktionen anzupassen.

Zusätzlich zu der bereits erwähnten experimentellen Duotone-Block-Unterstützung (color._experimentalDuotone) bietet WordPress 5.8 auch Unterstützung für die Linkfarbe. Um diese Funktion zu nutzen, füge einfach das folgende Flag zu deinen Block-Metadaten hinzu:

supports: {
	color: {
		link: true;
	}
}

Du kannst Standardwerte über Attribute festlegen, wie im folgenden Beispiel gezeigt, oder deine Voreinstellungen in theme.json festlegen:

attributes: {
	style: {
		type: 'object',
		default: {
			color: {
				link: '#FF0000',
			}
		}

Zusätzliche Block-API-Änderungen umfassen:

• fontSize und lineHeight werden stabil unterstützt.
• Die Unterstützung für margin wurde erweitert, und du kannst nun border und padding sowie die Größen top, right, bottom und left individuell steuern.

Du kannst mehr über die Block unterstützt API in WordPress 5.8 in Block unterstützt API Updates dev-note lesen.

Eine genauere Übersicht über die Verwendung der Block Supports API findest du in der offiziellen Dokumentation der Block Supports API.

Site Health Benutzerdefinierte Registerkarten

Zwei neue Hooks ermöglichen es Entwicklern jetzt, der Site Health-Oberfläche ihre eigenen Registerkarten hinzuzufügen und die verfügbaren Bildschirme anzupassen.

Der site_health_navigation_tabs-Filter ist ein assoziatives Array von Registerkarten-IDs und Bezeichnungen, um eine neue Registerkarte im Bildschirm „Site Health“ zu registrieren. Du kannst den Filter verwenden, indem du den folgenden Beispielcode in die Funktionsdatei deines Themes oder deines benutzerdefinierten Plugins einfügst:

function kinsta_site_health_navigation_tabs( $tabs ) {
	$tabs['kinsta-site-health-tab'] = esc_html_x( 'Kinsta', 'Site Health', 'text-domain' );

	return $tabs;
}
add_filter( 'site_health_navigation_tabs', 'kinsta_site_health_navigation_tabs' );

Das Bild unten zeigt die neue Registerkarte Site Health:

Dank des Filters site_health_navigation_tabs ist es auch möglich, Registerkarten neu anzuordnen oder ein oder mehrere Elemente zu entfernen.

Die Aktion site_health_tab_content wird ausgelöst, wenn ein Benutzer den Bildschirm „Site Health“ besucht, mit Ausnahme des Standard-Statusbildschirms. Du kannst diesen Hook wie im folgenden Ausschnitt gezeigt verwenden (Beispiel aus Dev Note):

function kinsta_site_health_tab_content( $tab ) {
	// Return if this is not your tab.
	if ( 'kinsta-site-health-tab' !== $tab ) {
		return;
	}

	// Include the interface, kept in a separate file just to differentiate code from views.
	include trailingslashit( plugin_dir_path( __FILE__ ) ) . 'views/kinsta-site-health-tab.php';
}
add_action( 'site_health_tab_content', 'kinsta_site_health_tab_content' );

Zuerst wird erkannt, ob es sich bei der aktuellen Registerkarte um deine benutzerdefinierte Registerkarte handelt, dann wird der Inhalt des Site Health-Bildschirms aus einer .php-Datei geladen. Die Aktion site_health_tab_content ermöglicht es Entwicklern auch, die Standard-Registerkarte „Info“ zu erweitern, indem sie spezifische Informationen für ihre Plugins oder Themes hinzufügen.

Block-Editor-API-Änderungen zur Unterstützung mehrerer Admin-Bildschirme

Mit WordPress 5.8 ist der Beitragseditor nicht mehr der einzige Admin-Bildschirm, der den Block-Editor verwendet (der Widgets-Bildschirm ist ein Beispiel dafür).

Core-Mitarbeiter fanden mehrere auf dem Server definierte Hooks, die vom $post-Objekt abhängen. Dieses Objekt ist in den Bildschirmen „Site Edit“, „Widgets“ und „Navigation“ nicht vorhanden. Im weiteren Verlauf wurden mehrere Filter veraltet und durch kontextabhängige Ersetzungen ersetzt.

Zusätzlich wurde eine neue Klasse WP_Block_Editor_Context eingeführt, die den aktuellen Blockeditor-Kontext und verschiedene Methoden darstellt.

Diese Änderungen verbessern diese Bildschirme mit neuen Funktionen und ermöglichen es Entwicklern, ihre Anpassungen hinzuzufügen.

Eine umfassende Liste der Block-Editor-API-Änderungen in Bezug auf Admin-Bildschirme findest du in der Dev-Note von Greg Ziółkowski.

Zusätzliche Funktionen und Erweiterungen

Es gibt so viele neue Funktionen und Änderungen für Entwickler, die WordPress 5.8 mit sich bringt, dass es für uns unmöglich wäre, sie alle in diesem Artikel zu erwähnen. Aber wir haben eine Liste von Dev-Notes, die hier nicht behandelt wurden, für deine weitere Lektüre gesammelt:

• Einstellung der Unterstützung für Internet Explorer 11
• Verbesserungen beim Laden von Blockstilen in WordPress 5.8
• Blöcke in einem iframed (Template) Editor
• Zu Layout und Inhaltsbreite in WordPress 5.8
• Einführung des „Update URI“-Plugin-Headers in WordPress 5.8
• Verschiedene Block-Editor-API-Entfernungen in WordPress 5.8
• REST-API-Änderungen in WordPress 5.8
• Verschiedene entwicklerorientierte Änderungen in WordPress 5.8
• Blöcke in einem iframed (Template) Editor
• Einführung des „Update URI“-Plugin-Headers in WordPress 5.8
• Verschiedene Block Editor API Ergänzungen in WordPress 5.8

Zusammenfassung

WordPress 5.8 markiert einen Meilenstein auf dem Weg zum Full Site Editing. Aber das zweite WordPress-Release des Jahres bringt viel mehr als FSE. Benutzer und Entwickler finden tonnenweise Verbesserungen am Block-Editor, einen neuen theme.json-Mechanismus, eine leistungsfähigere Block-API, Unterstützung für das WebP-Bildformat und vieles mehr.

Besonders beeindruckt sind wir von den kleinen und großen Verbesserungen am Block-Editor und seiner Benutzeroberfläche. Wir lieben die verbesserte Navigation zwischen den Blöcken, die überarbeitete Block-Symbolleiste, die verbesserte Übersichtlichkeit der Oberfläche und die Verbesserungen an mehreren Blöcken.

Diese kleinen Änderungen verbessern die Bearbeitungserfahrung nach und nach und, ohne es fast zu merken, finden wir uns dabei wieder, eine bessere und robustere Software zu benutzen. Das ist WordPress!

Jetzt bist du dran! Was sind deine Gedanken über Full Site Editing? Und was sind deine Lieblingsänderungen, die mit WordPress 5.8 kommen?