WordPress 7.1 soll am 19. August erscheinen und verspricht ein spannendes Update für Entwickler, Profis, Agenturen und Blogger im gesamten Ökosystem zu werden.

Diese zweite große Veröffentlichung des Jahres bringt eine Vielzahl von Neuerungen mit sich, die nahezu jeden Aspekt des CMS abdecken. Unter den neuen Funktionen begeistert uns die clientseitige Medienverarbeitung am meisten. Der Grund dafür ist, dass wir hier bei Kinsta total auf Web-Performance und Seiten-Geschwindigkeit fixiert sind, und diese neue Medienarchitektur ist ein bedeutender Schritt nach vorne – sie sorgt für spürbare Verbesserungen bei der Server-Effizienz und schnellere Ladezeiten.

Über die Medienverwaltung hinaus bringt WordPress 7.1 bemerkenswerte Verbesserungen für die Teamzusammenarbeit mit sich, darunter neue Notizfunktionen sowie mehrere Optimierungen der Benutzeroberfläche im Admin-Dashboard – wie zum Beispiel eine dauerhaft angezeigte Admin-Leiste und den neuen Identitätsbildschirm im Site-Editor. Die Version enthält neue und verbesserte Blöcke, erweiterte Design-Tools und eine breite Palette an Updates für Entwickler.

Möchtest du wissen, was als Nächstes kommt? Tauchen wir gemeinsam in WordPress 7.1 ein.

Clientseitige Medienverarbeitung

Bis WordPress 7.0 wurden die Generierung von Bildabmessungen und Miniaturansichten für die Anzeige im Frontend, die Formatkonvertierung und die Verwaltung der Bilddrehung komplett serverseitig über PHP abgewickelt.

Mit WordPress 7.1 wird nun eine neue Architektur für die Medienverarbeitung eingeführt: Die Größenanpassung von Bildern, die Formatkonvertierung, die EXIF-Drehung und die Erstellung von Vorschaubildern erfolgen nun clientseitig, direkt im Browser des Nutzers.

Diese Änderung sollte die Leistung der Website deutlich verbessern und den Verbrauch von Serverressourcen reduzieren.

Schauen wir uns mal genauer an, was sich bei der Bildverarbeitung ändert:

1. Was ist clientseitige Medienverarbeitung?

Während Bilder zuvor auf dem Server per PHP unter Verwendung der GD- oder Imagick-Bibliotheken verarbeitet wurden, erfolgen die Erzeugung von Bildern in verschiedenen Größen, die Formatkonvertierung und die EXIF-Drehung nun direkt im Browser des Nutzers – vorausgesetzt, der Browser unterstützt den „ Document-Isolation-Policy “ (DIP)-Header, um Zugriff auf SharedArrayBuffer zu gewähren.

Da die Verarbeitung im Browser stattfindet, erhält WordPress nicht mehr nur ein einziges Bild, sondern alle resultierenden Bilddateien aus der Verarbeitungskette. Das hat zwei wesentliche Auswirkungen: eine geringere Auslastung von Server-CPU und -RAM sowie mehr HTTP-Anfragen zum Hochladen der einzelnen Miniaturansichten.

Zum Zeitpunkt der Erstellung dieses Artikels unterstützen nur Chrome 137+ und Microsoft Edge 137+ (Desktop) die „ Document-Isolation-Policy “ vollständig. Safari und Firefox unterstützen die WASM-Pipeline nicht, obwohl Safari die native Dekodierung von HEIC/HEIF-Formaten in JPG unterstützt.

Ablaufdiagramm für den Upload bei der clientseitigen Medienverarbeitung
Upload-Ablauf bei der clientseitigen Medienverarbeitung (Bildquelle: WordPress.org)

2. Was sind die technischen Merkmale der clientseitigen Medienverarbeitung?

Aus architektonischer Sicht wird die clientseitige Medienverarbeitung über drei Kernpakete verwaltet:

  • Das neue „ @wordpress/vips “-Paket übernimmt die clientseitige Verarbeitung mithilfe der libvips “-Bibliothek, die in WebAssembly kompiliert ist (wasm-vips). Diese gilt weithin als eine der schnellsten und effizientesten Bildverarbeitungsbibliotheken auf dem Markt. Sie läuft parallel in einem Web Worker – wodurch ein Einfrieren der Benutzeroberfläche verhindert wird und eine deutlich bessere Leistung als reines JavaScript erzielt wird.
  • Das „ @wordpress/upload-media “-Paket koordiniert die Upload-Pipeline, einschließlich der Verwaltung von Upload-Warteschlangen, der Upload-Parallelität (bis zu 5 gleichzeitige Uploads und 2 Bildverarbeitungsvorgänge), automatischer Wiederholungsversuche, der Wiederaufnahme unterbrochener Uploads und der Offline-Unterstützung.
  • Das „ @wordpress/media-utils “-Paket übernimmt den HTTP-Transport und die REST-API-Anfragen.
Architekturdiagramm zur clientseitigen Medienverarbeitung in WordPress 7.1
Übersicht über die Architektur der clientseitigen Medienverarbeitung (Bildquelle: WordPress.org)

Zusätzlich zur Bildverarbeitung führt diese neue Funktion die automatische Konvertierung von animierten GIFs in MP4-/WebM-Videos ein. Die Konvertierung wird vom neuen „ @wordpress/video-conversion “-Paket übernommen, das die Bibliothek „ mediabunny in einen Web Worker einbindet, um undurchsichtige GIFs (ohne transparenten Hintergrund) in kompakte Videodateien umzuwandeln.

Die clientseitige Medienverarbeitung führt außerdem neue REST-API-Endpunkte ein (sideload, finalize und replace_file) sowie zwei neue Parameter: generate_sub_sizes und convert_format.

3. Was sind die Vorteile für WordPress-Nutzer?

Die clientseitige Medienverarbeitung verlagert die Bildverarbeitung vom Server auf den Client. Dadurch wird der Server von der hohen Arbeitslast befreit, die durch das Erstellen von Miniaturansichten in verschiedenen Abmessungen, das Drehen von Bildern und das Konvertieren von Formaten entsteht – diese Aufgaben werden direkt auf den Browser des Nutzers verlagert.

Hier sind einige der Vorteile für Nutzer, die die Medienverarbeitung auf den Client verlagern:

  • Weniger PHP-Out-of-Memory-Fehler: Die clientseitige Medienverarbeitung beseitigt Speicherauslastungsfehler (PHP memory limit exceeded), die zuvor bei der Verarbeitung großer Bilddateien auftraten.
  • Geringerer CPU- und RAM-Verbrauch: Ein weiterer großer Vorteil für den Server ist eine erhebliche Reduzierung der CPU- und RAM-Auslastung des Hosts, wodurch Ressourcen für andere Aufgaben freigesetzt werden.
  • Bessere Website-Performance: Die libvips-Bibliothek nutzt fortschrittliche Komprimierungsalgorithmen, die Bilder erzeugen, die im Durchschnitt etwa 15 % kleiner sind als die von GD oder Imagick generierten. Das führt zu schlankeren Bildern und schnelleren Ladezeiten.
  • Höhere Ausfallsicherheit beim Hochladen: Jeder Bild-Upload erfordert eine eigenständige HTTP-Anfrage. Das führt zwar zu einem höheren Volumen an HTTP-Anfragen, stellt aber sicher, dass jedes Bild unabhängig verarbeitet wird. Fehlgeschlagene Anfragen werden automatisch angehalten und erneut versucht.

Außerdem können animierte GIFs automatisch in effizientere Autoplay-Videos umgewandelt werden, von iPhones hochgeladene HEIC-Fotos können vom Browser vor dem Upload in JPG konvertiert werden (wodurch mögliche Kompatibilitätsprobleme mit dem Server umgangen werden), und die AVIF-Unterstützung funktioniert nun auch ohne serverseitige AVIF-Fähigkeiten (die MIME-Typ-Prüfung wird bei clientseitig dekodierten Uploads umgangen).

4. Was ändert sich für Entwickler?

Entwickler können die clientseitige Medienverarbeitung mithilfe des neuen Filters „ wp_client_side_media_processing_enabled “ deaktivieren. Hier ist ein Beispiel:

add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );

Darüber hinaus gibt es keine größeren Beeinträchtigungen für Plugin-Entwickler. Hooks, die mit der Medienverarbeitung verbunden sind, werden weiterhin ausgelöst, genau so, als würden die Bilder auf dem Server verarbeitet.

Bestehende Filter lesen die Einstellungen vom Server und funktionieren weiterhin wie erwartet. Der Filter „ wp_generate_attachment_metadata “ wird beispielsweise zweimal ausgeführt: zuerst beim ersten Upload (create) und ein zweites Mal, nachdem der Finalisierungs-Endpunkt aufgerufen wurde (update). Plugins, die diesen Filter nutzen, funktionieren weiterhin wie erwartet.

Für Theme-Entwickler werden Bildgrößen, die über add_image_size() registriert wurden, nun clientseitig generiert. Wenn ein Theme eine Bildgröße mit Abmessungen definiert, die mit einer Standardgröße von WordPress identisch sind, werden die Bilder zu einer einzigen Bilddatei „zusammengeführt“, die unter beiden Größenbezeichnungen registriert ist.

5. Was sind die Vorteile für die Sicherheit?

Obwohl die clientseitige Medienverarbeitung in erster Linie auf Leistung und Effizienz und nicht auf Sicherheit ausgelegt ist, bietet sie mehrere Vorteile, die die Sicherheit von WordPress-Seiten verbessern.

Erstens verringert sie die Angriffsfläche. Wie bereits erwähnt, stützte sich die Bildverarbeitung vor WordPress 7.1 auf serverseitige Bibliotheken wie GD und Imagick. Im Laufe der Zeit waren diese Bibliotheken von verschiedenen Sicherheitslücken im Zusammenhang mit der Bilddekodierung betroffen.

Bei der clientseitigen Bildverarbeitung benötigt der Server weder GD noch Imagick mehr, da er bereits vorverarbeitete Bilder erhält. Dadurch wird die Menge an sensiblem Code, der auf dem Server ausgeführt wird, erheblich reduziert.

Ein weiterer Sicherheitsvorteil besteht darin, dass die Bildverarbeitung in einer isolierten Browserumgebung stattfindet, wobei WebAssembly in einem Web Worker genutzt wird.

Die clientseitige Verarbeitung verringert zudem das Risiko von Denial-of-Service-Angriffen (DoS), da die Rechenlast auf dem Client liegt.

Um Bilder auf dem Client zu verarbeiten, nutzt WordPress SharedArrayBuffer, ein JavaScript-Objekt, das es dem Hauptthread und den Web Workers ermöglicht, denselben Speicherbereich zu nutzen.

Um den Zugriff auf „ SharedArrayBuffer “ zu gewähren, aktiviert WordPress den HeaderDocument-Isolation-Policy: isolate-and-credentialless “. Dies bietet einen isolierten Ausführungskontext für den Block-Editor in Chromium-137+-Browsern (Chrome 137+ und Edge 137+).

Kurz gesagt: Während das Hauptziel der clientseitigen Medienverarbeitung darin besteht, die Leistung und Effizienz bei der Medienverarbeitung zu verbessern, bringt diese neue Funktion auch bemerkenswerte Sicherheitsverbesserungen mit sich.

6. Offizielle Ressourcen

Die clientseitige Medienverarbeitung wurde sowohl für Nutzer als auch für Entwickler ausführlich dokumentiert. Schau dir die folgenden Ressourcen an, um mehr zu erfahren:

Verbesserungen bei den Notizen

Notizen wurden erstmals in WordPress 6.9 eingeführt und haben seitdem zahlreiche Ergänzungen und Verbesserungen erhalten, die sie zu einem umfassenderen Tool für die Zusammenarbeit machen.

Zunächst einmal bietet WordPress 7.1 nun Unterstützung für Rich Text in Notizen, wodurch diese „ausdrucksstärker, besser lesbar und besser an die Erwartungen der Nutzer an Tools wie Google Docs, Figma, GitHub und andere kollaborative Editoren angepasst“ sind.

Dazu gehören grundlegende Inline-Formatierungen wie Fettdruck (Strg/⌘ B), Kursivschrift (Strg/⌘ I), Links (Strg/⌘ K) und Emojis.

Notizen verfügen nun über grundlegende Formatierungsoptionen
Notizen verfügen nun über grundlegende Formatierungsoptionen

Jetzt kannst du Inline-Notizen hinzufügen, indem du Textfragmente anstelle eines ganzen Blocks auswählst (Inline-Block-Kommentare). Es ist auch möglich, mehrere Notizen zum selben Block oder zur selben Textauswahl hinzuzufügen.

WordPress 7.1 führt außerdem @Erwähnungen ein, mit denen du deine Mitwirkenden in Notizen markieren kannst, wodurch die Notiz-Funktion populären Kollaborations-Tools ähnlicher wird. Wenn du das @-Zeichen eingibst, erscheint ein Fenster mit einer Liste der Nutzer deiner Seite, aus der du ganz einfach auswählen kannst. Der Empfänger der Erwähnung erhält eine E-Mail-Benachrichtigung mit einem Link zurück zum Beitrag.

Eine weitere Neuerung betrifft den sichtbaren Teil der Notizen. Lange Notizen werden nun standardmäßig ausgeblendet, damit sie nicht zu viel Platz auf dem Bildschirm einnehmen. Über einen Schalter „Mehranzeigen/Weniger anzeigen “ kannst du den vollständigen Text ein- oder ausblenden.

Ein Schalter zeigt den Text in langen Notizen an oder blendet ihn aus
Ein Schalter zeigt den Text in langen Notizen an oder blendet ihn aus

Die vollständige Liste der neuen Funktionen für Notizen in WordPress 7.1 findest du in der Notizen-Iteration für WordPress 7.1.

Verbesserungen an der Admin-Benutzeroberfläche

Die Admin-Benutzeroberfläche erhält mehrere Aktualisierungen, die die Konsistenz der Oberfläche verbessern und die Navigation zwischen den Bildschirmen vereinfachen.

Permanente Admin-Leiste im Beitrags- und Site-Editor

Vor WordPress 7.1 wurde die Admin-Leiste im Beitrags- und im Website-Editor nicht angezeigt. Dieses Verhalten war inkonsistent, da die Admin-Leiste das am häufigsten genutzte Element der Admin-Oberfläche ist und ihr Weglassen in den Editoren nicht als optimal angesehen wurde. Ab WordPress 7.1 ändert sich dieses Verhalten, und die Admin-Symbolleiste ist nun im Beitrags- und im Site-Editor sichtbar.

Die Admin-Symbolleiste im Beitrags-Editor
Die Admin-Symbolleiste im Beitrags-Editor
Die Admin-Symbolleiste im Site-Editor
Die Admin-Symbolleiste im Site-Editor

Das Farbschema des Benutzers wurde auf den Site-Editor ausgeweitet

Eine weitere Verbesserung, die darauf abzielt, das Erscheinungsbild aller Admin-Bereiche einheitlich zu gestalten, besteht darin, das vom Benutzer auf seiner Einstellungsseite festgelegte Farbschema nun auch auf den Site-Editor anzuwenden. Vor Version 7.1 war die Seitenleiste des Site-Editors fest auf Schwarz eingestellt.

Die Benutzeroberfläche des Site-Editors in WordPress 7.1
Die Farbe der Seitenleiste des Site-Editors passt sich nun der in den Benutzereinstellungen festgelegten Farbe an.

Auch die Editor-Seitenleiste erhält mit WordPress 7.1 ein Update. Das Website-Symbol wurde aus der Editor-Symbolleiste entfernt und erscheint nun in der WordPress-Symbolleiste.

In früheren Versionen musstest du auf das Website-Symbol klicken, um zum WordPress-Admin-Bereich zurückzukehren – dabei handelte es sich technisch gesehen nicht um eine Zurück-Schaltfläche.

Die Editor-Symbolleiste in WordPress 7.0
Die Editor-Symbolleiste in WordPress 7.0

Daher erscheint das Website-Symbol nun nur noch in der Admin-Symbolleiste, während in der Editor-Symbolleiste eine deutlich erkennbare Zurück-Schaltfläche angezeigt wird.

Die Editor-Symbolleiste in WordPress 7.1
Die Editor-Symbolleiste verfügt nun über eine richtige Zurück-Schaltfläche

Befehlskategorien und verbesserte Benutzeroberfläche der Befehlspalette

Die Befehlspalette wurde um mehrere Ergänzungen und Änderungen erweitert, um ihre Benutzerfreundlichkeit zu verbessern. Zunächst wurden die verfügbaren Befehle in Abschnitte unterteilt (Zuletzt verwendet, Vorschläge und Ergebnisse), damit sie leichter zu finden sind.

Bereiche der Befehlspalette in WordPress 7.1
Befehle sind nun in Abschnitte gruppiert

Die Größe des Modals wurde angepasst (512px), und die Befehle sind jetzt besser lesbar.

Das neue Modalfenster für die Befehlspalette in WordPress 7.1
Das neue Modal der Befehlspalette

Bildschirm „Identität“ im Site-Editor

Unter dem Menü „Design“ im Site-Editor erscheint jetzt ein neuer Eintrag „Identität “. Auf dem entsprechenden Bildschirm kannst du den Titel, den Slogan, das Logo und das Symbol deiner Website konfigurieren. So kannst du die Identitätseinstellungen deiner Website bearbeiten , ohne den Site-Editor verlassen zu müssen.

Identitätseinstellungen in den globalen Stilen
Identitätseinstellungen in den globalen Stilen

Unendliches Scrollen für die Rasteransicht der Medienbibliothek

Bis WordPress 7.0 war es möglich, das unendliche Scrollen für die Rasteransicht der Medienbibliothek über den Filter „ media_library_infinite_scrolling “ zu aktivieren, der standardmäßig auf „ false “ gesetzt war. Entwickler konnten die Standardeinstellung ändern, indem sie die folgende Zeile in ihre Plugins einfügten:

add_filter( 'media_library_infinite_scrolling', '__return_true' );

Ab WordPress 7.1 ist der Filter „ media_library_infinite_scrolling “ auf „ true “ gesetzt, was bedeutet, dass das unendliche Scrollen in der Rasteransicht der Medienbibliothek standardmäßig für alle Nutzer aktiv ist.

Außerdem kannst du über eine neue Einstellung auf der Benutzerprofilseite im WordPress-Admin-Bereich deine Einstellungen für das unendliche Scrollen festlegen.

Option „Unendliches Scrollen in der Rasteransicht der Medienbibliothek deaktivieren“
Option „Unendliches Scrollen in der Rasteransicht der Medienbibliothek deaktivieren“

WordPress speichert die Auswahl des Benutzers in den Benutzeroptionen unter dem Meta-Schlüssel „ infinite_scrolling “. Du kannst die Benutzereinstellung folgendermaßen abrufen:

$infinite_scrolling = get_user_option( 'infinite_scrolling', $user_id );

Kernblöcke und Verbesserungen an Blöcken

WordPress 7.1 führt zwei neue Blöcke ein und bringt verschiedene Verbesserungen an bestehenden Blöcken mit sich.

Neue Blöcke „Playlist“ und „Tabs“

Mit dem neuen Playlist-Block kannst du eine einfache Wiedergabeliste in deinen Inhalt einbetten.

Der Playlist-Block in WordPress 7.1
Der Playlist-Block in WordPress 7.1

Du kannst verschiedene Aspekte des Aussehens des Blocks anpassen, darunter Typografie, Hintergrund, Abmessungen, Rahmen und Elemente. Zu den spezifischen Stiloptionen dieses Blocks gehören „Wellenform & Wiedergabetaste“ und „Hintergrund der Wellenform“. Mit der Option „Form“ kannst du die Audio-Visualisierung der Wellenform umschalten.

Den Stil des Playlist-Blocks anpassen
Den Stil des Playlist-Blocks anpassen

Der Playlist-Block unterstützt alle Audiodateien, die mit deiner WordPress-Installation kompatibel sind. Wenn du Unterstützung für einen neuen MIME-Typ hinzufügst, übernimmt der Block diesen automatisch.

Der neue Kernblock „Tabs“ dient dazu, Inhalte in Registerkarten zu organisieren. Jede Registerkarte kann beliebige Blöcke enthalten, was ihn besonders nützlich für themenbezogene Inhalte, FAQs oder Produkt-/Dienstleistungsvergleiche macht.

Der „Tabs“-Block in WordPress 7.1
WordPress 7.1 bietet einen neuen „Tabs“-Block

Bearbeitbare Blöcke innerhalb des „Benutzerdefiniertes HTML“-Blocks

Der „Benutzerdefiniertes HTML“-Block wurde um eine neue Funktion erweitert. Jetzt kannst du bearbeitbare Blöcke direkt in den HTML-Code einfügen. So kannst du statisches HTML und bearbeitbare Blöcke innerhalb desselben Snippets kombinieren.

Der „Benutzerdefinierter HTML“-Block in WordPress 7.1
Der „Benutzerdefiniertes HTML“-Block kann nun sowohl statisches HTML als auch bearbeitbare Blöcke enthalten

Obwohl sie bearbeitet werden können, lassen sich bearbeitbare Blöcke weder verschieben noch entfernen, und es können auch keine zusätzlichen Blöcke über den visuellen Editor hinzugefügt werden. Der zugrunde liegende Code bleibt jedoch im Code-Editor vollständig bearbeitbar.

Vor WordPress 7.1 mussten deine Inhalte entweder vollständig aus statischem HTML bestehen oder ausschließlich aus Blöcken. Jetzt kannst du HTML und Blöcke frei mischen, was besonders hilfreich ist, wenn du Inhalte mithilfe von KI-Modellen erstellst.

Diese Änderung geht einher mit der Möglichkeit, statischen HTML-Code zu Blockvarianten hinzuzufügen. Dank der neuen Unterstützung für „ innerContent “ kannst du eine Variante des HTML-Code-Blocks registrieren, wie im folgenden Beispiel gezeigt:

wp.blocks.registerBlockVariation( 'core/html', {
	name: 'custom-image-card',
	title: 'Custom image card',
	description: 'A custom HTML block with static header/footer and an editable image.',
	innerContent: [ 
		'<h2>Static heading</h2>\n', 
		null, 
		'\n<footer>Static footer</footer>' 
	],
	innerBlocks: [ 
		[ 
			'core/image', 
			{ 
				id: 419,
				sizeSlug: 'medium',
				linkDestination: 'none',
				url: 'https://example.com/wp-content/uploads/...',
				alt: ''
			} 
		] 
	],
} );

Der Wert „ null “ unter „ innerContent “ dient als Platzhalter für den Bildblock.

Beachte, dass „ innerContent “ nur für den Block „Benutzerdefiniertes HTML“ verfügbar ist. Wenn du es auf Varianten anderer Blöcke anwendest, hat das keine Wirkung.

Verbesserungen am SVG-Icon-System

Mit WordPress 7.0 wurden ein neuer Icon-Block und eine Icon-Bibliothek eingeführt. Mit WordPress 7.1 erhält das Icon-Verwaltungssystem eine öffentliche API, die es ermöglicht, Icons programmgesteuert zu registrieren, darzustellen und zu löschen sowie über die REST-API abzurufen.

Icons registrieren und deregistrieren

Um ein Symbol oder einen Symbolsatz zu registrieren, musst du zunächst eine Symbolsammlung registrieren, indem du die neue Funktion „ wp_register_icon_collection() “ in die „init“-Aktion einbindest:

function custom_icons_register_icon_collection() {
	wp_register_icon_collection(
		'my-icon-set',
		array(
			'label'       => __( 'My awesome icons', 'my-plugin' ),
			'description' => __( 'My personal set of icons.', 'my-plugin' ),
		)
	);
}
add_action( 'init', 'custom_icons_register_icon_collection' );

Eine Sammlung hat einen eindeutigen Namen, der sie von Kern-Icons und anderen, von Plugins von Drittanbietern registrierten Icon-Sets unterscheidet. Der Name der Sammlung muss mit einem Kleinbuchstaben beginnen und enden und darf Kleinbuchstaben, Zahlen, Bindestriche und Unterstriche enthalten.

Das zweite Argument der Funktion ist ein Array, das die in der Icon-Bibliothek angezeigte Bezeichnung der Sammlung sowie eine optionale Beschreibung enthält.

Um eine Sammlung zu entfernen, verwende die Funktion „ wp_unregister_icon_collection() “. Beim Entfernen einer Sammlung werden automatisch alle damit verbundenen Icons gelöscht.

Um ein einzelnes Icon zu registrieren, verwende die Funktion „ wp_register_icon() “, wie im folgenden Beispiel gezeigt:

wp_register_icon(
	'my-icon-set/motorbike',
	array(
		'label'   => __( 'Motorbike', 'my-plugin' ),
		'content' => '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">...</svg>',
	)
);

Im obigen Beispiel haben wir ein Icon mithilfe einer SVG-Zeichenkette registriert. Du kannst ein Icon auch direkt aus einer „ .svg “-Datei registrieren:

wp_register_icon(
	'my-icon-set/motorbike',
	array(
		'label'   => __( 'Motorbike', 'my-plugin' ),
		'file_path' => plugin_dir_path( __FILE__ ) . 'icons/motorbike.svg',
	)
);

Beachte bitte, dass die SVG-Datei mit ` wp_kses ` bereinigt wird und derzeit nur die Elemente ` <svg> `, ` <path> ` und ` <polygon> ` zulässig sind. Alle anderen Elemente werden herausgefiltert, wobei die Zulassungsliste in Zukunft möglicherweise um weitere Elemente und Attribute erweitert wird.

Um ein Symbol zu löschen, kannst du die Funktion ` wp_unregister_icon() ` verwenden.

Aktualisierungen der Icon-Bibliothek und der Blöcke

Die Icon-Bibliothek wurde entsprechend aktualisiert und verfügt nun über eine Seitenleiste, in der die Liste der auf der Seite registrierten Icon-Sammlungen angezeigt wird.

Die WordPress-Icon-Bibliothek
Die Icon-Sammlung des WordPress-Kerns
Die WordPress-Icon-Bibliothek
Eine benutzerdefinierte Icon-Sammlung in WordPress 7.1

Der Icon-Block wurde ebenfalls aktualisiert. Standardmäßig zeigt der Block nun das Info-Symbol an, anstatt wie in früheren Versionen einen leeren Platzhalter. Außerdem kannst du mit zwei neuen Steuerelementen in der Block-Symbolleiste das Symbol vertikal und horizontal spiegeln.

Icon-Block-Einstellungen in WordPress 7.1
Icon-Block-Einstellungen in WordPress 7.1

Neue REST-API-Endpunkte für Symbole

Es wurden außerdem neue schreibgeschützte REST-API-Endpunkte eingeführt, um auf Icon-Sammlungen oder bestimmte Icons zuzugreifen.

Für Icon-Sammlungen verwendest du die folgenden Endpunkte:

GET /wp/v2/icon-collections
GET /wp/v2/icon-collections/<collection>

Zum Lesen von Symbolen verwendest du stattdessen die folgenden Endpunkte:

GET /wp/v2/icons - Introduced with WordPress 7.0.
GET /wp/v2/icons/<collection>
GET /wp/v2/icons/<collection>/<name>

Ein Benutzer mit der Berechtigung „edit_posts“ muss die Anfragen authentifizieren.

Einen ausführlicheren Überblick über das Icon-System in WordPress 7.1 findest du in den Entwicklerhinweisen.

Neue Design-Tools

Ersteller und Redakteure verfügen nun über neue, verbesserte Design-Tools, mit denen sie Inhaltsblöcke gestalten können, ohne auf benutzerdefiniertes CSS zurückgreifen zu müssen.

Unterstützung für Hintergrundverläufe

WordPress 7.1 führt die Unterstützung für „ background.gradient sowie eine neue Admin-Oberfläche für Hintergrundverläufe ein.

In der Seitenleiste der Blockeinstellungen ermöglicht dir ein neues „Hintergrund“-Panel mit separaten Steuerelementen für „Bild“, „Farbe“ und „Farbverlauf“, mit verschiedenen Kombinationen aus Hintergrundbildern, Farben und Farbverläufen zu experimentieren und dabei Konflikte zu vermeiden.

Hintergrund Farbverlaufssteuerung in WordPress 7.1
WordPress 7.1 bietet ein neues Steuerelement für Hintergrundfarbverläufe

In WordPress 7.1 ist die Unterstützung für „ background.gradient “ standardmäßig für die Blöcke „Gruppe“, „Akkordeon“, „Zitat“, „Beitragsinhalt“ und „Zitat“ aktiviert. Theme-Entwickler können die Unterstützung für „ background.gradient “ in der Datei „block.json“ hinzufügen, indem sie eine „gradient“-Eigenschaft unter „styles.background“ oder blockweise einfügen, wie im folgenden Code gezeigt:

{
	"styles": {
		"background": {
			"gradient": "linear-gradient( 135deg, #1e3c72 0%, #2a5298 100% )"
		},
		"blocks": {
			"core/group": {
				"background": {
					"gradient": "linear-gradient( 135deg, #f5f7fa 0%, #c3cf8d 100% )"
				}
			}
		}
	}
}

Unterstützung für Mindestbreite

Eine weitere Neuerung in WordPress 7.1, die Designer und Theme-Entwickler begeistern wird, ist die Unterstützung für die Abmessung „ minWidth. Diese ergänzt die bereits vorhandene Unterstützung für „ height “, „ minHeight “ und „ width “ und vervollständigt damit die Palette der Design-Tools für Abmessungen.

Theme-Entwickler können die Unterstützung für die Mindestbreite über „ theme.json “ hinzufügen, entweder durch Aktivieren der „Appearance Tools“ oder durch Hinzufügen des Feldes „ dimensions.minWidth “ unter „Einstellungen“:

{
	"settings": {
		"dimensions": {
			"minWidth": true
		}
	}
}
Steuerung der Mindestbreite in WordPress 7.1
Steuerung der Mindestbreite in WordPress 7.1

Du kannst die Unterstützung für die Mindestbreite auch global oder blockweise hinzufügen:

{
	"styles": {
		"dimensions": {
			"minWidth": "400px"
		},
		"blocks": {
			"core/group": {
				"dimensions": {
					"minWidth": "400px"
				}
			}
		}
	}
}

Block-Entwickler können die Unterstützung für „ minWidth “ auf ähnliche Weise unter „ block.json “ hinzufügen:

{
	"supports": {
		"dimensions": {
			"minWidth": true
		}
	}
}

Die Steuerung ist standardmäßig in der Seitenleiste ausgeblendet, du kannst die Standardeinstellung jedoch über „ __experimentalDefaultControls “ ändern. In den globalen Stilen ist die Steuerung standardmäßig sichtbar.

Unterstützung für Textschatten in den globalen Stilen

WordPress 7.1 führt die Unterstützung für „ text-shadow “ in den „Global Styles“ ein. Bisher hättest du dafür ein Plugin benötigt oder auf benutzerdefiniertes CSS zurückgreifen müssen.

Beachte, dass es sich hierbei um eine erste Implementierung handelt. Einige wichtige Entscheidungen stehen noch aus, beispielsweise welche UI-Steuerelemente für die Anpassung von Textschatten im Editor verwendet werden sollen und ob „ text-shadow “ als Voreinstellung verfügbar sein soll. Derzeit ist es nur möglich, „ text-shadow “ in deinen „ theme.json “ auf eine der folgenden Arten zu definieren:

{
	"$schema": "https://schemas.wp.org/wp/6.7/theme.json",
	"version": 3,
	"settings": {},
	"styles": {
		"typography": {
			"textShadow": "1px 1px 2em white, 0 0 2em yellow, 0 0 0.2em red;"
		},
		"blocks": {
			"core/paragraph": {
				"typography": {
					"textShadow": "1px 1px 2px red, 0 0 1em red, 0 0 0.2em red"
				}
			}
		},
		"elements": {
			"h2": {
				"typography": {
					"fontSize": "var:preset|font-size|x-large",
					"textShadow": "1px 1px 2em white, 0 0 2em yellow, 0 0 0.2em red;"
				}
			}
		}
	}
}

Das folgende Bild zeigt das Ergebnis der oben genannten Definitionen.

WordPress 7.1 unterstützt Text-Schatten über theme.json
WordPress 7.1 unterstützt Text-Schatten über theme.json

Neuerungen für Entwickler

Die Neuerungen, die WordPress 7.1 für Theme- und Plugin-Entwickler mit sich bringt, sind bemerkenswert. Die zahlreichen Ergänzungen und Verbesserungen an der Abilities-API und dem Design-System-Theming erscheinen uns dabei als besonders erwähnenswert.

Design-System-Theming

WordPress 7.1 führt ein neues Design-System ein, mit dem Plugin-Entwickler das Styling von Elementen der Admin-Oberfläche anpassen können. Das neue System besteht aus zwei Teilen: Design-Tokens und einer neuen ThemeProvider- React Komponente.

Design-Token

WordPress-Design-Tokens sind benutzerdefinierte CSS-Eigenschaften, die einem festgelegten Muster folgen. Hier ist zum Beispiel das Muster für die „Color“-Token-Familie:

--wpds-color-<property>-<target>-<tone>[-<emphasis>][-<state>]

Basierend auf dem obigen Muster legt die folgende Variable die Hintergrundfarbe für Bereiche mit normaler Hervorhebung fest:

--wpds-color-background-surface-neutral-strong

Ab WordPress 7.1 können Design-Tokens von jedem Plugin verwendet werden, das Elemente der Admin-Oberfläche generiert – dank eines neuen Stylesheets „ wp-theme “, das einen vollständigen Satz semantischer Design-Tokens enthält und als Plugin-Abhängigkeit verfügbar ist. Du kannst ein benutzerdefiniertes Stylesheet, das „ wp-theme “ verwendet, wie unten gezeigt in die Warteschlange einreihen:

function myplugin_enqueue_admin_assets( $hook_suffix ) {
	wp_enqueue_style(
		'myplugin-admin-style',
		plugin_dir_url( __FILE__ ) . 'assets/css/admin.css',
		array( 'wp-theme' ),
		'1.0.0'
	);
}
add_action( 'admin_enqueue_scripts', 'myplugin_enqueue_admin_assets' );

Der Vorteil von Design-Tokens besteht darin, dass sie fest codierte CSS-Eigenschaftswerte ersetzen können. Sieh dir das folgende Beispiel aus den Entwicklerhinweisen an:

.card {
	background-color: var(--wpds-color-background-surface-neutral-strong);
	color: var(--wpds-color-foreground-content-neutral);
	border: var(--wpds-border-width-xs) solid var(--wpds-color-stroke-surface-neutral-weak);
	border-radius: var(--wpds-border-radius-lg);
	padding: var(--wpds-dimension-padding-2xl);
}

Design-Tokens können in Verbindung mit der ThemeProvider-Komponente verwendet werden, um das Erscheinungsbild bestimmter Bereiche der Admin-Seite anzupassen.

ThemeProvider

Du kannst die vom Stylesheet „ wp-theme “ bereitgestellten Standardwerte für Design-Tokens überschreiben, indem du den Inhalt des Admin-Bereichs in die neue React-Komponente „ ThemeProvider “ einbindest, wie im folgenden Beispiel aus dem Entwicklerhinweis gezeigt:

import { ThemeProvider } from '@wordpress/theme';
import { Card } from '@wordpress/ui';

function Application() {
	return (
		<ThemeProvider
			color={
				{
					primary: '#3858e9', 
					background: '#11004d' 
				}
			}
			cornerRadius="pronounced"
		>
			<Card.Root>
				<Card.Content>
					Card content
				</Card.Content>
			</Card.Root>
		</ThemeProvider>
	);
}

Anhand einer Primär- und einer Hintergrund-Ausgangsfarbe generiert die Komponente automatisch einen harmonischen und einheitlichen Farbverlauf, der für einen barrierefreien Kontrast zwischen den Elementen der Benutzeroberfläche sorgt.

Der ThemeProvider ermöglicht es Plugin-Entwicklern, ihre Markenidentität in den Oberflächenbereichen zum Ausdruck zu bringen und gleichzeitig den Gesamtstil der WordPress-Admin-Oberfläche beizubehalten.

Für eine ausführlichere Analyse schau dir bitte den Entwicklerhinweis und die offizielle Dokumentation zu Design-Tokens und ThemeProvider an.

Erweiterungen der Abilities-API

Mit der Veröffentlichung von WordPress 7.1 erhält die Abilities-API mehrere Ergänzungen, die ihre Funktionalität erweitern.

Neuer Ausführungszyklus für die Abilities-API

Zunächst einmal wird der Ausführungszyklus um vier neue Filter erweitert, die vor, während und nach der Ausführung einer Fähigkeit ausgeführt werden.

Ausführungszyklus der Abilities-API in WordPress 7.1
Neuer Ausführungszyklus für die Abilities-API in WordPress 7.1 (Quelle: WordPress.org)

Der Filter „ wp_pre_execute_ability “ wird zu Beginn von „ WP_Ability::execute() “ ausgeführt und dient dazu, die Ausführung einer Aktion abzufangen und abzubrechen, noch bevor WordPress mit der Verarbeitung beginnt. Wenn der Filter einen anderen Wert als den Standardwert „ $pre “ zurückgibt (einen Fehler, Daten oder einen booleschen Wert), stoppt WordPress sofort, umgeht alle Prüfungen und gibt diesen Wert zurück.

Dieser Filter eignet sich für interessante Anwendungsfälle, wie zum Beispiel das Deaktivieren einer Funktion während der Wartung der Website, die Begrenzung der Anzahl von Anfragen, die von derselben IP-Adresse stammen, oder das Simulieren der Antwort einer Funktion (Unit-Tests).

Der Filter „ wp_ability_normalize_input “ wird direkt nach der Anwendung der Standardwerte und vor der formalen Schemavalidierung sowie den Berechtigungsprüfungen ausgeführt. Er wird verwendet, um eingehende Daten vorzubereiten oder umzuwandeln, bevor sie von der Funktion validiert und verarbeitet werden – zum Beispiel, um kontextbezogene Metadaten hinzuzufügen, Daten vor der Validierung zu normalisieren, eine KI-Eingabeaufforderung anzureichern oder die Ausführung der Funktion im Fehlerfall zu stoppen.

Mit dem Filter „ wp_ability_permission_result “ kannst du das Ergebnis der Berechtigungsprüfungen ändern, die vor der Ausführung einer Funktion durchgeführt werden. Du kannst ihn nutzen, um detailliertere Autorisierungsregeln hinzuzufügen, ein benutzerdefiniertes Berechtigungssystem zu erstellen oder Berechtigungen in bestimmten Fällen zu umgehen.

Beachte, dass du diesen Filter mit Vorsicht verwenden solltest:

Plugins sollten bei diesem Filter besonders vorsichtig sein, da die Rückgabe von „ true “ eine Ablehnung durch den ursprünglichen „ permission_callback “ der Fähigkeit überschreiben kann.

Der Filter „ wp_ability_execute_result “ wird nach dem Ausführungs-Callback der Fähigkeit und vor der Ausgabevalidierung ausgeführt, sodass du das von einer Fähigkeit zurückgegebene Endergebnis ändern kannst. Er ermöglicht es dir, die von der Verarbeitung der Fähigkeit erzeugte Antwort umzuwandeln, bevor sie an den Aufrufer zurückgegeben wird.

Filtern und Bearbeiten von Fähigkeiten

Vor WordPress 7.1 musstest du zum Filtern registrierter Fähigkeiten die Registrierungsdatenbank manuell mit ` array_filter() ` durchlaufen. Ab WordPress 7.1 akzeptiert ` wp_get_abilities() ` ein optionales Array von Argumenten, um registrierte Fähigkeiten nach ` category `, ` namespace `, ` meta ` oder einer Kombination davon zu filtern.

Das folgende Beispiel zeigt, wie du Fähigkeiten einer bestimmten Kategorie abrufen kannst:

$abilities = wp_get_abilities(
	array(
		'category' => 'content-generation',
	)
);

Du kannst auch mehrere Parameter kombinieren:

$abilities = wp_get_abilities(
	array(
		'category'  => 'content-generation',
		'meta'      => array(
			'public' => true,
		),
	)
);

Für fortgeschrittenere Filterfunktionen bietet die API die Parameter „ item_include_callback “ und „ result_callback “ – zwei Callbacks, mit denen du Fähigkeiten zum Array hinzufügen oder daraus ausschließen sowie die Ergebnismenge vor der Rückgabe sortieren oder bearbeiten kannst.

Zusammen mit den Aktualisierungen an „ wp_get_abilities() “ führt WordPress 7.1 zwei neue globale Filter ein:

  • wp_get_abilities_item_include: Wird für jede Fähigkeit ausgeführt, die die deklarativen Filter und „ item_include_callback “ passiert. Mit diesem Filter kannst du bestimmte Fähigkeiten siteweit ein- oder ausschließen.
  • wp_get_abilities_result: Wird nach „ result_callback “ ausgeführt. Damit kannst du die gesamte Ergebnismenge der Fähigkeiten siteweit bearbeiten.

Eine ausführlichere Übersicht über die Aktualisierungen von „wp_get_abilities()“ und den zugehörigen Filtern findest du in den Entwicklerhinweisen.

Neues Flag für öffentliche Zugänglichkeit

WordPress 7.1 führt außerdem ein neues Metadaten-Flag ein, das angibt, dass eine Berechtigung für den Zugriff durch externe Clients wie die REST-API, MCP-Adapter und KI-Agenten verfügbar ist.

Wenn du eine Fähigkeit registrierst, kannst du nun „ meta.public “ verwenden, damit deine Fähigkeit über die REST-Endpunkte für Fähigkeiten erkannt und aufgerufen werden kann. Bisher musstest du die Freigabe für jeden Kanal separat festlegen – zum Beispiel durch die Einstellung „ ’show_in_rest‘ => true “, um eine Fähigkeit über REST sichtbar zu machen.

Weitere Verbesserungen an der Abilities-API

Zusätzlich zu den oben genannten Neuerungen führt WordPress 7.1 weitere Verbesserungen ein, die verschiedene Aspekte der API abdecken.

Zwei neue Filter, „ wp_ability_validate_input “ und „ wp_ability_validate_output “, ermöglichen es Plugins, Eingabe- und Ausgabedaten anhand komplexerer Regeln zu validieren, als sie durch das WordPress-JSON-Schema ausgedrückt werden können. Der erste Filter wird ausgeführt, nachdem die Eingabe aufbereitet wurde und die anfängliche Schema-Validierung erfolgreich war. Der zweite Filter wird ausgeführt, nachdem die Funktion ausgeführt wurde und bevor das Endergebnis zurückgegeben wird.

Die Aktion „ wp_ability_invoked “ wird zu Beginn von „ WP_Ability::execute() “ ausgeführt und kann verwendet werden, um jeden Versuch, eine Funktion aufzurufen, zu verfolgen und zu protokollieren. Du kannst diese Aktion nutzen, um Zugriffsversuche auf eine bestimmte Funktion zu protokollieren, die Serverauslastung zu messen, tägliche oder monatliche Nutzungszähler einzurichten und Brute-Force-Aufrufversuche zu erkennen.

Sei jedoch vorsichtig:

Die Aktion erhält rohe, unnormalisierte Eingaben. Plugins sollten es daher vermeiden, Eingaben wahllos zu protokollieren, da diese Anmeldedaten, persönliche Informationen oder andere sensible Daten enthalten können.

Weitere Updates für Entwickler

Die Updates für Entwickler hören hier noch nicht auf. WordPress 7.1 bringt eine beeindruckende Anzahl an Verbesserungen und Neuerungen mit sich und bietet neue sowie zuverlässigere Entwicklungstools. Mit dieser neuen Version findest du außerdem:

Responsive-Stile in WordPress 7.1
Du kannst spezifische CSS-Regeln für Mobilgeräte und Tablets im visuellen Editor, unter „Globale Stile“ oder in der Datei „theme.json“ definieren.

Hosting der nächsten Generation für WordPress der nächsten Generation

WordPress 7.1 markiert in mehrfacher Hinsicht einen großen Schritt nach vorn für das CMS.

Die clientseitige Medienverarbeitung stellt einen Wendepunkt im Bildmanagement dar. Die Verarbeitung erfolgt nun auf der Clientseite, was zu einer effizienteren Nutzung der Serverressourcen und einer schnelleren Seitenleistung führt.

Was die KI-Fähigkeiten angeht, markiert WordPress 7.1 nach den bahnbrechenden Updates in den Versionen 6.9 und 7.0 einen Moment der Konsolidierung. Die Abilities-API erhält neue Funktionen, die es Entwicklern ermöglichen, zuverlässigere und sicherere KI-Integrationen und -Funktionen zu erstellen.

Eine weitere leistungsstarke Neuerung, die Entwickler und Agenturen zu schätzen wissen werden, ist der „Theme Provider“, der es Plugins ermöglicht, ihre Markenidentität im Admin-Bereich zum Ausdruck zu bringen und dabei die Konsistenz mit der WordPress-Dashboard-Oberfläche zu wahren.

Außerdem gibt es Verbesserungen bei den Notizen, neue Blöcke, ein leistungsfähigeres SVG-Symbolsystem und vieles mehr. Kurz gesagt: WordPress ist weit davon entfernt, an Schwung zu verlieren, und ist zukunftsorientierter denn je.

Für ein immer fortschrittlicheres CMS ist die Wahl eines Hosting-Anbieters, der mit modernen Technologien Schritt hält, unerlässlich. Kinsta bietet die ideale Umgebung für WordPress-Seiten der nächsten Generation: containerisierte Cloud-Infrastruktur, herausragende Leistung, solide Sicherheit und schnellen, erstklassigen Support.

Wenn du unser Hosting noch nicht ausprobiert hast, nutze die kostenlose Testphase für ausgewählte Tarife oder kontaktiere uns, um mehr zu erfahren.

Carlo Daniele Kinsta

Carlo ist ein leidenschaftlicher Liebhaber von Webdesign und Frontend-Entwicklung. Er beschäftigt sich seit über 10 Jahren mit WordPress, auch in Zusammenarbeit mit italienischen und europäischen Universitäten und Bildungseinrichtungen. Er hat Dutzende von Artikeln und Leitfäden über WordPress geschrieben, die sowohl auf italienischen und internationalen Websites als auch in gedruckten Magazinen veröffentlicht wurden. Du kannst Carlo auf X und LinkedIn finden.