Was ist neu in WordPress 5.7 (Lazy-Loading, HTTPS, UI Updates, neue APIs und vieles mehr)

Wir sind daran gewöhnt, dass bei jeder neuen Version kleine und nicht so kleine Änderungen und neue Funktionen zum WordPress-Core hinzugefügt werden. WordPress 5.7 ist da keine Ausnahme und es ist großartig zu sehen, wie jede neue Version uns dem großen Ganzen ein Stück näher bringt.

Mit mehreren Versionen des Block-Editors, die in den Core integriert wurden, verbessert die neue Version das gesamte Bearbeitungserlebnis und ermöglicht es Entwicklern, fortgeschrittenere Blöcke zu erstellen und dem Block-Editor leistungsfähigere Anpassungen hinzuzufügen.

Abgesehen vom Editor bringt WordPress 5.7 auch tonnenweise Änderungen und großartige Funktionen mit sich, darunter Lazy Loading Iframes, Aktualisierungen der Anmelde- und Registrierungsschnittstelle, Links zum Zurücksetzen von Passwörtern, eine große Anzahl von Bugfixes und vieles mehr.

Wir haben unsere Tests auf DevKinsta durchgeführt und sind bereit, unsere Lieblingsfunktionen und -änderungen, die mit WordPress 5.7 kommen, mit euch zu teilen – natürlich mit zahlreichen Screenshots und Code-Snippets.

Wenn du tiefer in die erste große Version von 2021 eintauchen möchtest, schau dir den WordPress 5.7 Entwicklungszyklus, die Planungsübersicht und den Praxisleitfaden an.

Während wir also weiterhin auf die vollständige Website-Bearbeitung (im Core von WordPress 5.8) warten, machen wir es uns gemütlich und genießen, was in WordPress 5.7 neu ist!

Was ist neu im Block Editor

WordPress 5.7 bringt viele Versionen des Gutenberg Plugins in den Core. Es wäre unmöglich, all diese Ergänzungen hier zu erwähnen, zusätzlich zu den vielen Änderungen und Fehlerbehebungen, die dem Editor hinzugefügt wurden, aber du kannst die folgenden Links besuchen, um tief in jede Version einzutauchen: 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9.

Fehlerbehebungen und Leistungsverbesserungen aus Gutenberg 10.0 und 10.1 sind auch Teil von WordPress 5.7.

Gehen wir also durch unsere handverlesene Liste der spannendsten Features und Änderungen, die mit WordPress 5.7 zum Block-Editor hinzugefügt wurden:

Blockvariationen Funktionen, Erweiterungen und APIs

Die mit WordPress 5.4 eingeführten Blockvariationen bieten dem Nutzer die Möglichkeit, eine andere Instanz desselben Blocks auszuwählen.

Diese Funktion arbeitet mit der Block Variations API zusammen, einem mächtigen Tool, das es Entwicklern erlaubt, Variationen von Blöcken hinzuzufügen, zu verwalten oder zu entfernen.

WordPress 5.7 führt mehrere Verbesserungen, Funktionen und neue APIs für Blockvariationen ein, die ein besseres UI und leistungsfähigere Tools für Entwickler bieten. Lass uns eintauchen.

Block Variationen Transformationen

Erstmals mit Gutenberg 9.4 eingeführt und nun in WordPress 5.7 hinzugefügt, erscheint ein Transform to variation Switcher unterhalb der Blockkarte für Blöcke, die dieses Feature unterstützen.

Der Transform to Variation Schalter für einen Buttons Block

Bei der Registrierung einer neuen Blockvariation können Blockentwickler den Variationswechsler zum Blockinspektor hinzufügen, indem sie die neue transform option zum Blockvariations scope-Feld hinzufügen, wie im folgenden Beispiel gezeigt (nur JS-Code):

wp.blocks.registerBlockVariation( 'core/heading', { 
	name: 'green-text', 
	title: 'Green Text', 
	description: 'This block has green text. It overrides the default description.',  
	attributes: { 
		content: 'Green Text', 
		textColor: 'vivid-green-cyan' 
	}, 
	icon: 'palmtree', 
	scope: [ 'inserter', 'transform' ] 
} );

In diesem Beispiel erscheint eine Block-Variation in zwei Bereichen der Editor-Oberfläche – dem Block-Inserter und dem Block-Inspektor.

Block Variation Beispiel mit Transformationsbereich

Für einen detaillierten Überblick über Block Variation Transformations, siehe auch PR #26687.

Blockinformationen passen nun zu Blockvariationen

Seit WordPress 5.7 (und Gutenberg 9.7) zeigt das UI spezifischere Informationen zu Blockvariationen an, während es vorher nur generische Informationen anzeigte.

Vor WordPress 5.7 zeigten die Interface-Elemente generische Informationen über Blockvariationen

Embed-Blöcke und Social Icons sind als Block-Variationen aufgebaut; sie sind gute Beispiele dafür, dass WordPress Block-Informationen mit Block-Variationen zusammenbringt.

Die Oberflächenelemente zeigen nun Informationen, die spezifisch für die Blockvarianten sind

Diese Änderungen betreffen den Block-Inspektor, die Block-Navigationsleiste und die Breadcrumbs. Seit Gutenberg 9.8 gilt diese UI-Verbesserung auch für den Block-Switcher.

UI-Erweiterung für Blockvariationen im Block Switcher

Neue Block-Variationen APIs

WordPress 5.7 führt auch neue APIs ein, die Entwickler bei der Registrierung von Blockvariationen verwenden können, um die korrekten Informationen einer Blockvariation anzuzeigen (Gutenberg 9.7).

Die neue Eigenschaft isActive ist eine Funktion, die die Attribute eines Blocks akzeptiert. Du kannst die Attribute der Variation verwenden, um festzustellen, ob eine Variation aktiv ist (siehe auch Block-API-Referenz).

Blockentwickler können diese Funktion verwenden, um Variationsinformationen anstelle von Blockinformationen anzuzeigen. Ein Beispiel könnte der embed-Block sein, wo wir den Wert des providerNameSlug-Attributs ändern können (ein Beispiel aus der Dev Note):

const variations = [
{
	name: 'wordpress',
	title: 'WordPress',
	keywords: [ __( 'post' ), __( 'blog' ) ],
	description: __( 'Embed a WordPress post.' ),
	attributes: { providerNameSlug: 'wordpress' },
	isActive: ( blockAttributes, variationAttributes ) =>
		blockAttributes.providerNameSlug === variationAttributes.providerNameSlug,
},
];

Im folgenden Beispiel wird die Eigenschaft isActive verwendet, um das Farbattribut zu ändern:

variations: [
{
	name: 'blue',
	title: __( 'Blue Quote' ),
	isDefault: true,
	attributes: { color: 'blue', className: 'is-style-blue-quote' },
	icon: 'format-quote',
	isActive: ( blockAttributes, variationAttributes ) =>
		blockAttributes.color === variationAttributes.color
},
],

Der neue useBlockDisplayInformation Hook gibt Informationen über einen bestimmten Block zurück. Der neue Hook berücksichtigt die isActive -Eigenschaft einer Blockvariation und gibt den title, das icon, und die description des Blocks zurück.

Diese Änderungen betreffen die Blockkarte (Inspector Tools), die Navigationslistenansicht (Top Bar) und Breadcrumbs (siehe auch PR #27469).

Neue Buttons Block Features

Ein paar neue Features verbessern die Funktionalität und das Interface des Buttons Blocks.

Button Abmessungen

Ein neues Steuerelement in den Einstellungen der Sidebar erlaubt es uns nun, eine prozentuale Breite für Buttons in Buttons-Blöcken festzulegen (Gutenberg 9.4).

Wähle einfach einen Button und wähle 25%, 50%, 75% oder 100%. Die Prozentangaben beziehen sich auf den übergeordneten Container. Das Bild unten zeigt verschiedene Kombinationen von Buttongrößen.

Kombinationen von Buttons mit unterschiedlichen Breitenwerten

Für weitere technische Einblicke, schau dir die Pull Requests #25999 und #26781 an.

Vertikales Layout

Diese neue Funktion fügt Variationen für die vertikale Ausrichtung des Buttons-Blocks hinzu. Nutzer können von einem horizontalen Layout zu einem vertikalen Layout wechseln, indem sie den Transformations-Switcher im Block-Einstellungspanel nutzen (Gutenberg 9.6).

Buttons Block mit vertikaler Ausrichtung

Social Icons Erweiterungen

WordPress 5.7 fügt neue Anpassungsoptionen für Social Icons hinzu: Support für benutzerdefinierte Größe und benutzerdefinierte Farben.

Social Icons Größe

Wenn der Social Icons-Block ausgewählt ist, bietet die Block-Symbolleiste jetzt ein Größen-Optionsmenü mit verfügbaren Größen (Gutenberg 9.4).

'Riesige' Größe für soziale Symbole — ‚Riesige‘ Größe für soziale Symbole

Benutzerdefinierte Farben in sozialen Icons

Der gleiche Block unterstützt nun Farbeinstellungen, wodurch wir verschiedene benutzerdefinierte Farben für Icons und Hintergründe einstellen können (Gutenberg 9.9).

Soziale Icons mit schwarzer Hintergrundfarbe

Du kannst nun die Farbpalette des Themes für Social Icons verwenden, um zu verhindern, dass die Farben der Icons mit dem Farbschema deiner Webseite kollidieren (siehe auch PR #28084).

Font Size Support

WordPress 5.7 fügt Support für die Schriftgröße für Listen- und Code-Blöcke hinzu.

Schriftgröße im Listenblock

Eine Typografiekarte mit Steuerelementen für die Schriftgröße wurde zu den Einstellungen des Listenblocks hinzugefügt (Gutenberg 9.4).

Schriftgröße in den Einstellungen des Listenblocks

Der Benutzer kann eine der verfügbaren Schriftgrößen für Listenelemente auswählen oder eine eigene Schriftgröße in Pixeln festlegen. Die Schaltfläche „Zurücksetzen“ stellt die Standardwerte wieder her.

Schriftgrößen Support im Code Block

WordPress 5.7 bietet auch Support für die Verwaltung der Schriftgröße in Code-Blöcken. Wenn ein Code-Block ausgewählt ist, wird in der Sidebar der Blockeinstellungen ein neues Steuerelement für die Schriftgröße angezeigt. Mit diesem Steuerelement kannst du entweder eine der voreingestellten Größen auswählen, die in deinem Theme verfügbar sind, oder einen benutzerdefinierten Wert in Pixel festlegen (Gutenberg 9.5).

Globale Schriftgrößen in Twenty Twenty verfügbar

Die Implementierung dieses Features erlaubt auch die Verwendung von globalen Style-Variablen im CSS von Code-Blöcken (siehe auch PR #27294). Das Bild unten zeigt einen Code-Block im Frontend mit dem installierten Twenty Twenty Theme.

Ausrichtung in voller Höhe im Cover Block

WordPress 5.7 führt eine neue Full Height Toolbar Alignment Komponente ein. Es wurde erstmals mit Gutenberg 9.5 in den Block-Editor integriert. Jetzt wurde es in den Core integriert und in den Cover-Block implementiert.

Full Height Alignment wurde im Cover Block implementiert

Wenn du den Block-Toolbar-Button umschaltest und dabei die minimale Höhe im Auge behältst, wirst du sehen, dass die Ausrichtung in voller Höhe nur eine Abkürzung für 100vh ist (lies mehr über die prozentuale Länge des Viewports).

Ausrichtung in voller Höhe in einem Abdeckblock

Du kannst Full Height Alignment in Kombination mit anderen Steuerungseinstellungen wie fester Hintergrund, Inhaltsposition und so weiter verwenden. Du wirst wahrscheinlich von der Anzahl der beeindruckenden Effekte überrascht sein, die du auf deinen Seiten erzeugen kannst.

Drag & Drop von Blöcken und Mustern aus dem Inserter

Der Block-Inserter unterstützt jetzt Drag & Drop für Blöcke und Muster. Nutzer können jeden Block oder jedes Muster aus dem Inserter ziehen und es an einer beliebigen Stelle auf der Beitragsfläche platzieren (Gutenberg 9.6 und 9.7).

Jetzt kannst du Blöcke oder Muster aus dem Inserter auf die Post Canvas ziehen

Beachte, dass Drag & Drop nur funktioniert, wenn dein Theme Blockmuster unterstützt.

Semi-transparenter Spacer-Block

Anstelle der früheren undurchsichtigen grauen Farbe hat der Spacer-Block jetzt einen halbtransparenten Hintergrund (Gutenberg 9.8).

Ein undurchsichtiger Spacer Block in WordPress 5.6

Dieses Feature soll es einfacher machen, den Spacer-Block auf einer beliebigen Hintergrundfarbe zu identifizieren.

Ein halbtransparenter Spacer-Block in WordPress 5.7

Zusätzliche Verbesserungen im Block-Editor, die erwähnenswert sind

Unsere Liste wird nicht alle Features und Verbesserungen abdecken, die in Core integriert wurden, daher solltest du dir die offizielle Dokumentation und die Dev-Notes ansehen, um ein umfassenderes Register der Neuerungen im Block-Editor mit WordPress 5.7 zu erhalten.

Aber um nur einige zu nennen, in 5.7 wirst du auch Folgendes finden:

Automatisches Einschalten des Dark-Modus, wenn der dunkle Hintergrund aktiviert ist (PR #28233)
Patreon, Telegram und TikTok Icons zu den Social Icons hinzugefügt (PR #26118)
Alle Einheiten werden in den Schriftgrößeneinstellungen unterstützt (PR #26475)
Blocktransformationen in der Vorschau (PR #27861)
Verbesserte Blockmuster-Vorschau im Block-Inserter (PR #27204)
Das Options-Modal wurde verbessert und der Name in Preferences geändert
Änderungen in @wordpress/data API
Inner Blocks API Änderungen
Erweiterungen der Import/Export-Funktion
Änderungen an Block-Editor-Komponenten und Blöcken

Blocktransformationen Vorschau in WordPress 5.7

Lazy-Loading iframes

Lazy Loading ist eine Optimierungstechnik, die das Laden von nicht kritischen Ressourcen aufschiebt, bis sie sich im viewport des Benutzers befinden. Lazy Loading Bilder und eingebettete Ressourcen werden erst heruntergeladen und gerendert, wenn sie benötigt werden. Es kann die Leistung einer Webseite erheblich verbessern, insbesondere bei Webseiten mit hochauflösenden Bildern und Videos.

Vor dem nativen Lazy Loading konnten Entwickler Assets nur über JavaScript laden. WordPress-Benutzer waren gezwungen, ein Plugin zu verwenden, um den gleichen Effekt zu erzielen. Seitdem Lazy Loading jedoch zum Standard geworden ist, können Bilder und iframes durch einfaches Hinzufügen des loading="lazy" -Attributs zu img und iframe-Tags lazy-geladen werden.

Safari unterstützt das Lazy Loading von Bildern als experimentelle Funktion

Mit WordPress 5.5 wurde im WordPress-Core das Native Image Lazy Loading eingeführt, das automatisch das Attribut loading="lazy" zu img-Tags mit angegebenen Attributen für width und height hinzufügt.

Seit WordPress 5.7 wird Lazy Loading nun auch auf iframe-Tags ausgeweitet. Wie bei Bildern wird loading="lazy" nur zu iframe-Tags mit width– und height-Attributen hinzugefügt, um Layout-Verschiebungen zu verhindern.

In WordPress funktioniert das native Lazy Loading mit iframes in den folgenden Kontexten:

iframes in post content (the_content)
iframes in post excerpts (the_excerpt)
iframes in text widgets (widget_text_content)

Lazy Loading-Einstellungen in Chrome (verfügbar unter chrome://flags/)

In WordPress setzen die meisten iframes auf die oEmbed-Integration, die eine URL automatisch in das entsprechende iframe-Tag umwandelt. Leider stellt nicht jeder Webdienst width– und heightattribute für iframes zur Verfügung; dies verhindert, dass WordPress das loading-Attribut zu diesen iframes hinzufügen kann.

Das Bild unten zeigt ein iframe-Tag mit dem Attribut loading="lazy":

Lazy Loading mit einem eingebetteten YouTube-Video

Mit den Worten von Felix Arntz:

Das Markup dieser iframe-Tags wird durch den jeweiligen Webdienst gesteuert, und nur einige dieser Webdienste folgen der bewährten Praxis, das Attribut width und height anzugeben. Da WordPress die Abmessungen der eingebetteten Ressource nicht erraten kann, wird das loading="lazy"-Attribut nur hinzugefügt, wenn das oEmbed-iframe-Tag mit beiden Dimensionsattributen vorhanden ist.

Das folgende Bild zeigt ein iframe-Tag ohne das Attribut loading="lazy":

Lazy-Loading iframes für Entwickler

Aus der Sicht eines Entwicklers erforderte die neue Funktion mehrere Änderungen, darunter:

Das Verhalten der Funktion wp_filter_content_tags() wurde erweitert, um das loading-Attribut zu iframe-Tags hinzuzufügen. Das loading-Attribut wurde bisher nur zu img-Tags hinzugefügt.
Standardmäßig gibt die Funktion wp_lazy_loading_enabled() nun true für iframe-Tags zurück (wenn aktiviert).
Die neue Funktion wp_iframe_tag_add_loading_attr() ermöglicht das Hinzufügen des loading-Attributs zu iframe-Tags (ähnlich wie bei wp_img_tag_add_loading_attr() – siehe Code-Referenz).
Der Filter wp_iframe_tag_add_loading_attr ermöglicht die Anpassung des Lazy Loading für bestimmte iframes. Wird false oder ein leerer String zurückgegeben, wird das Attribut nicht hinzugefügt.

Du kannst das Standardverhalten überschreiben, indem du den bestehenden wp_lazy_loading_enabled Filter verwendest, der nun true für iframe Tags zurückgibt.

add_filter(
	'wp_lazy_loading_enabled',
	function( $default, $tag_name, $context ){
		if ( 'iframe' === $tag_name && 'the_content' === $context ){
			return false;
		}
		return $default;
	},
	10,
	3
);

Du kannst auch den neuen wp_iframe_tag_add_loading_attr Filter verwenden, der die Anpassung des Verhaltens eines bestimmten iframe Tags erlaubt. Du könntest zum Beispiel Lazy Loading für YouTube-Videos in einem bestimmten Kontext deaktivieren.

Der folgende Code basiert auf einem Beispiel aus der Dev Note und zeigt, wie man Lazy Loading für Iframes, die YouTube-Videos einbetten, deaktivieren kann:

add_filter(
	'wp_iframe_tag_add_loading_attr',
	function( $value, $iframe, $context ){
		if ( 'the_content' === $context && false !== strpos( $iframe, 'youtube.com' ) {
		return false;
	},
	10,
	3
);

Beachte, dass zum Zeitpunkt dieses Artikels nicht alle Webbrowser Lazy Loading generell unterstützen. Du kannst unten sehen, dass Firefox und Safari nur Lazy Loading für Bilder unterstützen.

Lazy Loading per Attribut für Bilder & iframes (Quelle: caniuse.com)

Ein-Klick-Migration deiner Webseite von HTTP zu HTTPS

Seit Version 5.7 erkennt WordPress, ob die Umgebung einer Webseite HTTPS unterstützt. Wenn dies der Fall ist, bietet der HTTPS-Status-Bereich im Site Health Tool einen Call-to-Action-Button, mit dem Seitenadministratoren ihre Webseiten mit einem einzigen Klick von HTTP auf HTTPS umstellen können. Der Inhalt deiner Webseite wird sofort migriert, so dass wir keine Mixed Content Warnungen erhalten.

Aktualisiere deine Webseite, um HTTPS in WordPress 5.7 zu verwenden (Bildquelle: WordPress.org)

WordPress zeigt eine Benachrichtigung an, wenn HTTPS nicht unterstützt wird.

HTTP zu HTTPS Migration für Entwickler

Neben der neuen automatischen Funktion, die über das Site Health Tool zugänglich ist, führt WordPress 5.7 neue Funktionen ein, die es Entwicklern ermöglichen, verschiedene Aspekte der HTTPS-Erkennung und -Migration zu testen und anzupassen.

Die neue Funktion wp_is_using_https() gibt true zurück, wenn sowohl „Site Address“ (home_url()) als auch „WordPress Address“ (site_url()) eine URL mit https. Diese neue Funktion wird von Felix Arntz in der Dev Note anschaulich dargestellt:

Im Wesentlichen bedeutet das Ändern dieser beiden URLs in HTTPS, dass die Webseite HTTPS verwendet. Während es andere Möglichkeiten gibt, HTTPS teilweise in WordPress zu aktivieren (z.B. mit der Konstante FORCE_SSL_ADMIN), konzentriert sich der neue Erkennungsmechanismus auf die Verwendung von HTTPS auf deiner gesamten Webseite, d.h. im Frontend und Backend.

Während die Funktion wp_is_using_https() das Vorhandensein von https in der URL überprüft, prüft wp_is_https_supported()ob die Umgebung der Webseite HTTPS korrekt unterstützt.

Diese Funktion prüft im Wesentlichen auf das Vorhandensein der Option https_detection_errors in der Datenbank und gibt true zurück, wenn keine Fehler gefunden werden. Für den Fall, dass deine Umgebung HTTPS nicht unterstützt, wird die Option https_detection_errors in der Tabelle wp_options vorhanden sein, wie im folgenden Bild gezeigt:

Wie bereits erwähnt, werden hartkodierte URLs im Inhalt deiner Webseite mit Hilfe von zwei neuen Funktionen geändert: wp_replace_insecure_home_url() und wp_should_replace_insecure_home_url().

Um eine Webseite von HTTP auf HTTPS zu migrieren, müsste der Seitenadministrator lediglich „Site Address“ und „WordPress Address“ manuell aktualisieren, um HTTPS anstelle von HTTP einzuschließen. Um die Dinge jedoch noch einfacher zu machen, führt WordPress 5.7 die neue Funktion wp_update_urls_to_https() ein.

Diese letztgenannte Funktion ermöglicht die Migration einer Webseite und all ihrer Inhalte von HTTP zu HTTPS mit einem einzigen Klick (zumindest in den häufigsten Szenarien, z.B. wenn „Site Address“ mit „WordPress Address“ übereinstimmt). Es ist eine absolute Neuheit und eine erhebliche Verbesserung der WordPress-Administrationserfahrung.

Für weitere technische Aspekte der HTTPS-Erkennung und -Migration siehe die Dev-Note von Felix Arntz, sowie die Tickets #47577 und #51437

Neue Post Parent bezogene Funktionen

WordPress 5.7 führt zwei neue Post Parent-Funktionen ein. Sie sind einfach zu benutzen und helfen dir, die Logik in Plugins und Themes zu reduzieren.

has_parent_post()

Die has_parent_post() Funktion ist ein Conditional Tag, das prüft, ob ein gegebener Post einen Parent hat und entsprechend true oder false zurückgibt. Es akzeptiert die Post ID oder das WP_Post Objekt als Parameter und verwendet die globale Variable $post, falls vorhanden. Siehe das folgende Beispiel:

<?php if ( has_parent_post( get_the_ID() ) ) : ?>
	// your code here
<?php endif; ?>

get_parent_post()

Die Funktion get_parent_post() ist ein Template-Tag, der das übergeordnete WP_Post-Objekt für einen bestimmten Beitrag abfragt. Wie die vorherige Funktion akzeptiert sie die Post ID oder das WP_Post Objekt als Parameter. Siehe das folgende Beispiel für die Verwendung:

<a href="<?php the_permalink( get_parent_post( get_the_ID() ) ); ?>"><?php echo get_the_title( get_parent_post( get_the_ID() ) ); ?></a>

In der realen Welt würden wir diese Funktionen in Verbindung verwenden. Du kannst selbst einen Test durchführen, indem du den folgenden Code aus der Dev Note in die single.php Template Datei deines Themes einfügst:

<?php if ( has_parent_post( get_the_ID() ) ) : ?>
	<p><a href="<?php the_permalink( get_parent_post( get_the_ID() ) ); ?>">
	<?php
		echo sprintf(
			esc_html__( 'Parent page: %s', 'text-domain' ),
			get_the_title( get_parent_post( get_the_ID() ) )
		);
	?>
	</a></p>
<?php endif; ?>

Login und Registrierung Interface Updates

WordPress 5.7 bringt einige Verbesserungen für die Login- und Registrierungsfunktion, mit einem verbesserten Reset Password Interface, neuen Hooks und anderen kleinen Änderungen.

Passwort zurücksetzen Fenster

Das Fenster zum Zurücksetzen des Passworts bietet nun zwei Buttons: Passwort generieren und Passwort speichern. Der erste Button generiert bei jedem Klick ein neues starkes Passwort, während der zweite Button dein Passwort speichert. Diese Änderung sollte zu einer verbesserten Erfahrung beim Zurücksetzen des Passworts für neue WordPress-Nutzer führen.

Das Bild unten vergleicht die Bildschirme zum Zurücksetzen des Passworts in WordPress 5.6 und 5.7:

Der Bildschirm Passwort zurücksetzen in WordPress 5.6 vs. 5.7

Neue Filter

Mit dem neuen lostpassword_user_data Hook können wir die Variable $user_data beim Zurücksetzen des Passworts filtern. Entwickler können nun eine Benutzervalidierung mit benutzerdefinierten Daten anstelle eines Benutzernamens oder einer Emailadresse durchführen. Für ein Beispiel aus der Praxis, schau dir diesen Kommentar von Marcelo Villela Gusmão an.

Der neue Filterhook login_site_html_link ermöglicht es uns, den HTML-Code, der den „Zurück zu {site_name}“-Link generiert, komplett durch eigenen Code/Link zu ersetzen. Jetzt können Entwickler einen benutzerdefinierten Text für den Link setzen, sowie den Link selbst ändern. Du kannst den Filter wie im folgenden Beispiel verwenden:

function custom_login_site_html_link( $link ) {
	return '<a href="' . esc_url( home_url( '/blog/' ) ) . '">' . __( 'Back to my awesome blog', 'textdomain' ) . '</a>';
}
add_filter( 'login_site_html_link', 'custom_login_site_html_link', 10, 1 );

Das Bild unten zeigt die Ausgabe auf dem Bildschirm:

Benutzerdefinierter „Zurück zu {site_name}“ Link in WordPress 5.7

Weitere Änderungen findest du in den Änderungen der Login- und Registrierungsbildschirme in WordPress 5.7 Dev Note.

Neue Funktionen, um zu prüfen, ob ein Beitrag öffentlich einsehbar ist

WordPress 5.7 führt zwei neue Funktionen ein, mit denen Entwickler prüfen können, ob ein Beitrag öffentlich einsehbar ist.

is_post_status_viewable()

Die neue Funktion is_post_status_viewable() ermöglicht es Entwicklern zu prüfen, ob ein Beitrag öffentlich einsehbar ist, abhängig vom Status des Beitrags.

Diese neue Funktion bietet einen besseren Weg, um zu prüfen, ob ein Beitrag sichtbar ist, als die existierende is_post_type_viewable() Funktion, die zwar prüfen kann, ob ein Beitragstyp für anonyme Benutzer sichtbar ist, aber nicht dabei hilft, zu bestimmen, ob ein bestimmter Beitrag sichtbar ist oder nicht.

Für eingebaute Beitragstypen prüft is_post_status_viewable() das public-Attribut. Bei benutzerdefinierten Beitragstypen prüft sie stattdessen das Attribut publicly_queryable.

Wir haben den folgenden Code, basierend auf dem Beispiel aus der Dev Note, in einer lokalen Installation getestet:

$current_post_status = get_post_status( $post );
if ( is_post_status_viewable( $current_post_status ) ) {
	echo '<p>This post uses a public post status.' . ' Current status: <strong>' . $current_post_status . '</strong></p>';
} else {
	echo '<p>This post uses a non public post status.' . ' Current status: <strong>' . $current_post_status . '</strong></p>';
}

is_post_status_viewable() akzeptiert einen erforderlichen Parameter:

$post_status (string|stdClass) Der Name oder das Objekt des Poststatus.

In einem öffentlichen Blogpost würde der obige Code das folgende Ergebnis produzieren:

Der aktuelle Status eines öffentlich einsehbaren Beitrags

In einer privaten Post würde das Ergebnis wie folgt lauten:

Der aktuelle Status eines privaten Beitrags

Jean-Baptiste Audras, der Autor von dev note, warnt:

Bitte beachte, dass passwortgeschützte Beiträge als öffentlich einsehbar gelten, während private Beiträge nicht einsehbar sind.

is_post_publicly_viewable()

Die neue Funktion is_post_publicly_viewable() gibt true zurück, wenn sowohl is_post_status_viewable() als auch is_post_type_viewable() true zurückgeben. Sie lässt uns auch feststellen, ob ein bestimmter Beitrag öffentlich einsehbar ist (d.h. ob er für ausgeloggte Benutzer einsehbar ist).

is_post_publicly_viewable() akzeptiert einen optionalen Parameter:

$post (string|stdClass) Eine Post-ID oder ein Objekt. Standardmäßig wird das globale $post Objekt übergeben.

Ein neuer dynamischer Hook zum Filtern des Inhalts eines bestimmten Blocktyps

WordPress 5.7 führt einen neuen dynamischen Hook ein, der es Entwicklern ermöglicht, den Inhalt eines bestimmten Blocktyps zu filtern.

Dieser neue render_block_{$this->name} Filter ist ähnlich dem bestehenden render_block Filter, mit einem entscheidenden Unterschied: render_block filtert den Inhalt eines einzelnen Blocks, während der neue dynamische Hook den Inhalt des Blocktyps {$this->name} filtert.

Um diesen Filter zu verwenden, solltest du die folgenden Parameter angeben:

$block_content (string): Der Blockinhalt, der angehängt werden soll.
$block (array): Der komplette Block, inklusive Name und Attribute.

Der Callback gibt den geänderten Blockinhalt zurück.

Das folgende Beispiel zeigt einen Anwendungsfall für diesen Filter auf einen Absatzblock:

add_filter( 
	'render_block_core/paragraph', 
	function( $block_content, $block ) {
		$content  = '<div class="my-custom-wrapper">' . $block_content . '</div>';
		return $content;
	}, 
	10, 
	2 
);

In diesem Beispiel ist das Suffix core/paragraph der Slug des Core-Absatzblocktyps. Für benutzerdefinierte Blöcke sollte der Slug etwas wie my-custom-plugin/my-custom-block sein.

Siehe die Dev Note für eine ausführlichere Übersicht und weitere Anwendungsbeispiele.

Neue Robots API

Das robots-Meta-Tag ermöglicht es Betreibern von Webseiten, zu kontrollieren, wie eine Webseite indexiert und den Nutzern in den Suchmaschinenergebnissen angezeigt werden soll (siehe übrigens auch unseren Leitfaden zu WordPress SEO).

WordPress 5.7 führt eine neue Robots-API ein, die es Entwicklern ermöglicht, diesen robots-Meta-Tag zu kontrollieren. Die neue API bietet einen wp_robots-Filter für Theme-Entwickler, um ihre eigenen Direktiven zum robots-Meta-Tag hinzuzufügen.

Zusätzlich wird die max-image-preview:large Direktive nun standardmäßig zu Webseiten hinzugefügt, die für Suchmaschinen sichtbar sein sollen. Es weist die Suchmaschinen an, große Bildvorschauen in den Suchergebnissen anzuzeigen.

Die 'max-image-preview:large' Direktive in WordPress 5.7 — Die ‚max-image-preview:large‘ Direktive in WordPress 5.7

Entwickler können die max-image-preview:large Direktive mit folgendem Code entfernen:

remove_filter( 'wp_robots', 'wp_robots_max_image_preview_large' );

Die Anpassung der robots-Direktiven ist ziemlich einfach. Das folgende Beispiel aus der Dev Note zeigt, wie man eine eigene Direktive zum Meta-Tag hinzufügt:

add_filter( 
	'wp_robots', 
	function( $robots ) {
		$robots['follow'] = true;
		return $robots;
	}
);

Der obige Code würde die folgende Ausgabe produzieren:

<meta name="robots" content="max-image-preview:large, follow">

Es ist auch möglich, bestehende Direktiven zu entfernen, indem du einfach die Werte zurücksetzt. Der folgende Code deaktiviert die max-image-preview Direktive:

function my_wp_robots_directives( $robots ) {
	unset( $robots['max-image-preview'] );
	$robots['follow'] = true;
	return $robots;
}
add_filter( 'wp_robots', 'my_wp_robots_directives' );

Eine ausführliche Übersicht über das robots-Meta-Tag findest du im Ahrefs Blog und in der Google Search Referenz. In der Dev Note findest du zusätzliche Informationen über die neue WordPress Robots API und veraltete Funktionen.

Passwort zurücksetzen Links

Eine neue Funktion erlaubt es Seitenadministratoren nun, Links zum Zurücksetzen des Passworts per E-Mail an jeden registrierten Benutzer zu senden. Diese Funktion kann nützlich sein, wenn ein Benutzer aus irgendeinem Grund keinen Zugriff auf den Link zum Zurücksetzen des Passworts hat.

Seitenadministratoren können einen Link zum Zurücksetzen des Passworts per E-Mail von verschiedenen Bereichen aus versenden. Als erstes findest du einen neuen Bereich mit einem Link zum Zurücksetzen des Passworts im Profilbildschirm eines jeden Nutzers.

Sende den Reset Link in deinem Profil Bildschirm

Wenn alles gut geht, solltest du eine Admin-Benachrichtigung sehen, die bestätigt, dass der Link zum Zurücksetzen des Passworts an den Benutzer gemailt wurde.

Ein Admin Hinweis bestätigt, dass die E-Mail erfolgreich versendet wurde

Du kannst auch einen Link zum Zurücksetzen des Passworts über den Benutzerbildschirm senden.

Link zum Zurücksetzen des Passworts im Benutzerbildschirm senden

Du kannst sogar mehrere Benutzer auswählen und Passwort-Reset-Links in Massen versenden.

Passwort zurücksetzen Link in Bulk-Aktionen senden

Wie bereits erwähnt, erhalten die Nutzer eine E-Mail mit einem Link zum Zurücksetzen des Passworts. Das folgende Bild zeigt eine E-Mail zum Zurücksetzen des Passworts im DevKinsta Email Inbox Tool.

Entwickler können retrieve_password_title und retrieve_password_message Filter verwenden, um den Betreff und die Nachricht der E-Mail anzupassen.

Zusätzliche Erweiterungen für Entwickler

Neue Funktionen zur Übergabe von Attributen an Script-Tags

Mehrere neue Funktionen erlauben nun die Übergabe von Attributen an <script>-Tags (d.h. async oder nonce).

wp_get_script_tag()

wp_get_script_tag() lädt ein formatiertes script-Tag und injiziert automatisch das type-Attribut, wenn das Theme keinen Support für HTML5-script-Tags deklariert hat. Es akzeptiert ein Array von Schlüssel-Wert-Paaren, die die Attribute repräsentieren, die dem <script>-Tag hinzugefügt werden.

Diese Funktion paart sich mit dem neuen wp_script_attributes Filter, der verwendet werden kann, um Attribute zu filtern.

wp_print_script_tag()

wp_print_script_tag() gibt ein formatiertes script-Tag aus..

wp_get_inline_script_tag()

wp_get_inline_script_tag() wickelt Inline-JavaScript in ein script-Tag ein.

Diese Funktion hat einen entsprechenden wp_inline_script_attributes-Hook, der die Attribute filtert, die zu einem Script-Tag hinzugefügt werden sollen.

wp_print_inline_script_tag()

wp_print_inline_script_tag() gibt Inline-JavaScript in einem script-Tag aus.

wp_sanitize_script_attributes()

Die neue Funktion wp_sanitize_script_attributes() wird verwendet, um ein Array von Attributen in einen Attributstring zu sanitisieren. Diese können dann zu einem script-Tag hinzugefügt werden.

In der Dev Note findest du weitere Informationen und Anwendungsbeispiele.

Standardisierte WP-Admin Farben

Als Teil eines größeren Projekts, das darauf abzielt, das WP-Admin CSS aufzuräumen, verwendet WordPress nun eine neue standardisierte WP-Admin Farbpalette. Die neue Farbpalette umfasst jeweils 12 Schattierungen von Blau-, Grün-, Rot- und Gelbtönen. Außerdem fügt sie 13 Grautöne, Schwarz und Weiß hinzu. Außerdem erfüllt es die Mindestanforderungen der WCAG 2.0 an das Kontrastverhältnis.

WP-Admin Farbpalette (Bildquelle: ryelle)

Mit den Worten von Jean-Baptiste Audras:

Die Standardisierung auf diese Farbpalette wird den Entwicklern helfen, konsistente und zugängliche Designentscheidungen zu treffen. Entwickler von Themes und Plugins werden ermutigt, diese neue Farbpalette zu verwenden, um eine bessere Konsistenz zwischen ihren Produkten und WordPress-Core zu erreichen.

WP_MEMORY_LIMIT Konstante in Site Health

Die WP_MEMORY_LIMIT Konstante gibt die maximale Menge an Speicher an, die PHP verbrauchen kann.

Die Konstante WP_MEMORY_LIMIT, die in früheren WordPress-Versionen noch nicht enthalten war, wurde dem Info-Tab in Site Health hinzugefügt.

WP_MEMORY_LIMIT in der Registerkarte Site Health Info

WP_MEMORY_LIMIT in Site Health Info tabWeitere Änderungen für Entwickler findest du unter Verschiedene entwicklerorientierte Änderungen und REST API Änderungen in WordPress 5.7. Eine vollständige Liste der Entwicklungshinweise findest du im WordPress 5.7 Field Guide.

Zusammenfassung

Der Marktanteil von WordPress wächst weiterhin in einem stetigen Tempo:

WordPress wird von 64,4% aller Webseiten verwendet, deren Content Management System wir kennen. Das sind 40,3% aller Webseiten.

Es ist ein signifikanter Beweis für die Gesundheit des CMS, besonders für diejenigen, die ihr Geschäft auf WordPress aufbauen. Und das ist auch ein guter Grund, darauf zu achten, was im WordPress-Ökosystem vor sich geht.

WordPress 5.7 bringt tonnenweise neue Features und Verbesserungen für Nutzer und Entwickler, aber das ist nur ein Vorgeschmack auf das, was wir 2021 erwarten können.

Jetzt liegt es an dir. Haben wir etwas Wichtiges verpasst? Was sind deine Lieblingsänderungen und -funktionen von WordPress 5.7?

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.