Was gibt es Neues in WordPress 5.5 – Ein tiefgreifender Einblick in ein (epischen) Release

Jetzt, da WordPress 5.5 veröffentlicht wurde, und ist es für uns an der Zeit, die auffälligsten Änderungen und Funktionen vorzustellen, die mit der zweiten WordPress Version des Jahres hinzugefügt werden.

Heutzutage sind wir daran gewöhnt, bei jedem Release von WordPress viele Ergänzungen des Blockeditors zu sehen. WordPress 5.5 ist da keine Ausnahme!

Diese Version bringt auch eine Menge Änderungen mit sich, die nicht mit dem Editor zusammenhängen und die einen großen Einfluss auf die Art und Weise haben sollten, wie wir das CMS benutzen werden.

Während WordPress 5.5 viele Änderungen am WordPress Core mit sich bringt, wurden einige Funktionen, die mit 5.5 erwartet wurden, aufgrund verschiedener ungelöster Probleme verzögert und aus dieser Version entfernt. So sind die vollständige Bearbeitung der Webseite, der Navigationsblock, der Navigationsbildschirm und der Widgetbildschirm nicht Teil von WordPress 5.5.

Wenn du mehr über den Entwicklungszyklus von WordPress 5.5 lesen möchtest, schau dir die Links unten an:

• 7. Juli 2020: Beta 1
• 14. Juli 2020: Beta 2
• 21. Juli 2020: Beta 3
• 27. Juli 2020: Beta 4
• 28. Juli 2020: RC 1
• 4. August 2020: RC 2
• 10. August 2020: RC 3
• 10. August 2020: Probelauf für den Release von WordPress 5.5
• 11. August 2020: Finales Release von WordPress 5.5 „Eckstine„

Also, was gibt es Neues in WordPress 5.5?

Was ist neu im Block Editor

Mit der finalen Version von WordPress 5.5 werden zehn Versionen des Gutenberg-Plugins zum Core hinzugefügt, die eine große Anzahl von UI-Verbesserungen, Features, Erweiterungen und Bugfixes mit sich bringen, die jeden Aspekt des Editierens betreffen, von der Benutzerfreundlichkeit bis hin zu Funktionalität und Leistung.

Es wäre nahezu unmöglich, all diese Änderungen hier zu erwähnen, deshalb findet ihr in diesem Beitrag nur eine handverlesene Auswahl unserer beliebtesten neuen Features und Verbesserungen.

Eine umfassendere Auflistung der Verbesserungen und Funktionen, die mit WordPress 5.5 zum Blockeditor hinzugefügt wurden, findet ihr in den offiziellen Ankündigungen der Plugin-Veröffentlichungen: 7.5, 7.6, 7.7, 7.8, 7.9, 8.0, 8.1, 8.2, 8.3, 8.4, 8.5.

Davon abgesehen werden wir hier die folgenden Ergänzungen behandeln, die mit WordPress 5.5 in den Blockeditor gebracht wurden:

1. Neues UI-Design
2. Block Design Tools
3. Inline-Bildbearbeitung
4. Block-Kategorien und neues Block-Inserter-Panel
5. Das Block-Verzeichnis und Block-Plugins
6. Block-Muster

Neues UI-Design

Jede Version des Gutenberg-Plugins bringt kleine und nicht ganz so kleine Verbesserungen, die das gesamte Editier-Erlebnis im Stillen verändern. Eine Menge dieser Änderungen werden nun in den WordPress-Core eingearbeitet. Wenn ihr also zum ersten Mal den Blockeditor in WordPress 5.5 startet, sollte ein etwas anderes Interface eure Aufmerksamkeit erregen. Ihr werdet folgendes finden:

• Eine vereinfachte Block-Werkzeugleiste
• Stärkerer Farbkontrast
• Neue Icons
• Block-Mover
• Umgebende Elemente
• Geräte-Vorschauen
• Verbessertes Drag und Drop
• Verbesserte und vereinheitlichte Blockfokus-Stile über die gesamte UI
• Möglichkeit, mehrere Blöcke auf einmal zu formatieren
• Bessere Leistung

Mit Gutenberg 7.7 zum Blockeditor hinzugefügt, sind die oben genannten nur einige der vielen Änderungen, die das Editier-Erlebnis beeinflussen.

Zusätzliche Änderungen sind auch enthalten:

Subscript und Superscript Optionen

Die Formatierungsoptionen für Subscript und Superscript Text sind jetzt über die Rich Text Steuerung (Gutenberg 8.0) verfügbar.

Parent Block Selection

Eine brandneue Taste auf der Symbolleiste erscheint jetzt, wenn man mit der Maus über die linke Seite der Blocksymbolleiste fährt. Der neue Knopf erlaubt es, übergeordnete Blöcke in verschachtelten Kontexten auszuwählen (Gutenberg 8.3).

Block Design Tools

In den letzten Monaten wurden dem Gutenberg-Plugin mehrere Design-Tools hinzugefügt, die nun mit WordPress 5.5 in den Core aufgenommen werden.

Höhenkontrolle und Hintergrundgradienten

Ein erster Satz von Tools bietet die Kontrolle über Dimensionen und Hintergrundfarbe für mehrere Blöcke (Gutenberg 7.9).

Padding und Link-Farbkontrollen

Zwei zusätzliche Features landen im Core (Gutenberg 8.3), aber zum Zeitpunkt des Schreibens dieses Artikels sind sie noch als experimentell gekennzeichnet:

• Paddingsteuerung für Cover Block.
• Link-Farbkontrolle für Absatz, Überschrift, Gruppe, Spalten und Medien- und Textblöcke.

Die Padding-Steuerung und die Steuerung der Linkfarbe sind standardmäßig ausgeschaltet und die Entwickler müssen explizit Support für sie angeben, wie im Block Editor Handbuch erklärt wird.

Wenn ihr die Padding-Steuerung für den Cover-Block zu euren Themes hinzufügen wollt, fügt einfach die folgende Zeile in die functions.php eures Themes ein:

add_theme_support( 'experimental-custom-spacing' );

Wenn du die Steuerung der Linkfarben für Absatz, Überschrift, Gruppe, Spalten und Medien- und Textblöcke aktivieren möchtest, füge einfach die folgende Zeile in die Funktionsdatei deines Themes ein:

add_theme_support( 'experimental-link-color' );

Benutzerdefinierte Einheiten und benutzerdefinierte Linienhöhen

Diese neue Funktion erlaubt es euch, px, em, rem, vw und vh Höhenwerte für den Cover-Block einzustellen (Gutenberg 7.9). % wird ebenfalls unterstützt, aber es wird wegen der unvorhersehbaren Darstellung der prozentualen Höhenwerte weggelassen.

Mit der erweiterten Höhenkontrolle kannst du Werte um 10 springen lassen, indem du die Umschalttaste gedrückt hältst, während du nach oben oder unten drückst.

Entwickler können Support für Custom-Units hinzufügen, indem sie die Custom-Units Support Flagge definieren:

add_theme_support( 'custom-units' );

Du kannst auch bestimmte benutzerdefinierte Einheiten einstellen:

add_theme_support( 'custom-units', 'rem', 'em' );

Entwickler können auch benutzerdefinierte Zeilenhöhen für Überschriften und Absätze hinzufügen, indem sie die Support-Flagge für benutzerdefinierte Zeilenhöhen definieren:

add_theme_support( 'custom-line-height' );

Inline Image Editing

Mit Gutenberg 8.4 wurde dem Blockeditor eine neue Bearbeitungsfunktion hinzugefügt, die es den Benutzern ermöglicht, Bilder direkt aus dem Bildblock heraus zu bearbeiten.

Jetzt wurde es zum Kern hinzugefügt und ab WordPress 5.5 kann man Bilder zuschneiden, drehen, zoomen und die Bildpositionen anpassen, ohne die Medienbibliothek starten zu müssen, was zu einem schnelleren Bearbeitungserlebnis führt.

Wenn du früher tonnenweise Fotos veröffentlicht hast, wirst du dieses Feature zweifellos genießen.

Klicke einfach auf die Schaltfläche Zuschneiden in der Bildsymbolleiste und du hast Zugang zu den neuen Bearbeitungsfunktionen. Wenn du mit deinen Anpassungen zufrieden bist, wende deine Änderungen an und du bist fertig.

WordPress speichert ein neues Bild als Anhang in der Medienbibliothek und kopiert die Details des Originalbildes (Titel, Beschreibung, Bildunterschrift, Alt-Text und EXIF-Daten). Dadurch hast du die volle Kontrolle über neue Bildversionen.

Block-Kategorien und neues Block-Inserter-Panel

Ein neu gestaltetes Block-Inserter-Panel zeigt Blöcke und Muster nach Kategorien an, was das Editieren erheblich verbessert und Blöcke und Muster leichter auffindbar macht (Gutenberg 8.3).

Das Block-Verzeichnis und Block-Plugins

Mit der Implementierung des Block-Verzeichnisses kannst du Blöcke von Drittanbietern direkt vom Block-Inserter aus finden, installieren und hinzufügen.

Wenn du nach einem Block suchst, wirst du, falls du es noch nicht installiert hast, eine Liste der im Plugin-Verzeichnis verfügbaren Plugins angezeigt bekommen. Diese Plugins werden „Block-Plugins“ genannt und du kannst sie mit einem einzigen Klick zu deinem Editor hinzufügen.

Dank dieser neuen tollen Funktion kannst du jetzt deine eigenen Blöcke bauen und sie im Plugin-Verzeichnis veröffentlichen, wodurch deine Kreationen der gesamten WordPress-Community zur Verfügung stehen.

Die gute Nachricht ist, dass du, um deine eigenen Blöcke zu erstellen, kein PHP-Guru sein musst. Du brauchst nur ein paar Grundkenntnisse in JavaScript.

Du bist dir nicht sicher, wie du anfangen sollst, deine eigenen Blöcke zu entwickeln? Die großartige WordPress-Community hat dir eine einfache Schritt-für-Schritt-Anleitung gegeben.

Die erste Version des Block-Tutorials ist bereits im offiziellen Block-Editor-Handbuch verfügbar, damit du die Grundlagen der Blockentwicklung lernen kannst. Mehr über das Block-Verzeichnis und die Entwicklung von Block-Plugins kannst du auf dem Blog Make WordPress Plugins lesen.

Block-Muster

Im März 2020 wurden mit Gutenberg 7.7 und Gutenberg 7.8 Blockmuster und die Blockmuster-API für Themes und Plugins eingeführt.

Blockmuster sind vordefinierte Blocklayouts, mit denen Benutzer schnell komplexe Strukturen verschachtelter Blöcke zu ihren Seiten hinzufügen können. Ihre Absicht ist es, Content-Autoren und Seitenadministratoren dabei zu helfen, das „Leerseitensyndrom“ zu überwinden und mit Leichtigkeit professionelle Layouts und erweiterte Ansichten zu erstellen.

Wir sollten Blockmuster am besten bei der Bearbeitung ganzer Webseiten sehen.

Eine klare Erklärung, wofür Blockmuster gedacht sind, kommt von Mathias Ventura, dem leitenden Architekten des Gutenberg-Projekts:

Eine Klarstellung – bei der „Blockmuster“-Aufstellung geht es weniger um Template-Teile (die strukturell sinnvoll sind) als vielmehr um allgemeine Designelemente, die aus kleineren Blöcken bestehen. Einmal eingefügt, werden sie nicht separat gespeichert. Zum Beispiel ein „Cover“-Bild, das ein paar Blöcke kombiniert, um einen bestimmten Look zu erzielen, für den die Benutzer sonst etwas Arbeit benötigen würden. Betrachte es eher als eine Sammlung von Designs, die überall hinzugefügt werden können, ohne notwendigerweise einen wiederverwendbaren Teil eines Theme Templates darzustellen.

Anders als Templates sind Blockmuster Designelemente, die den Seitenadministratoren und Content-Erstellern helfen sollen, das Editieren zu beschleunigen und zu verbessern.

Gestartet mit Gutenberg 7.7, erschienen Blockmuster zunächst in einem Sidebar Plugin. Später, mit der Veröffentlichung von Gutenberg 8.0, wechselten sie in einen überarbeiteten Block-Inserter, der jetzt als ein Panel auf der linken Seite des Editors erscheint, wie im Bild unten gezeigt:

In ihrem Anfangsstadium kommen Blockmuster mit einer sehr begrenzten Anzahl von Mustern. Wie auch immer, sie werden eine enorme Verbesserung des Editierens bringen, und hoffentlich werden in naher Zukunft noch mehr hinzugefügt.

Wie normale Blöcke sind die Muster durchsuchbar und in den folgenden Kategorien organisiert:

• Text
• Held
• Kolumnen
• Schaltflächen
• Galerie
• Eigenschaften
• Empfehlungsschreiben
• Nicht kategorisiert

Zusätzlich zu den eingebauten Blockmustern können WordPress-Entwickler ihre Themes und Plugins mit benutzerdefinierten Mustern versehen, indem sie die Vorteile einer brandneuen API nutzen.

Du kannst deine eigenen Muster mit den Funktionen register_block_pattern und register_block_pattern_category für Kategorien registrieren.

register_block_pattern benötigt zwei Argumente:

1. Der Name des Musters.
2. Eine Reihe von Mustereigenschaften.

Zu den Eigenschaften gehören die folgenden:

• title
• content
• description
• categories
• keywords
• viewportWidth

register_block_pattern_category benötigt ebenfalls zwei Argumente:

1. Der Name der Musterkategorie.
2. Eine Reihe von Eigenschaften.

Die API bietet auch zwei Funktionen zum Aufheben der Registrierung von Mustern und Kategorien: unregister_block_pattern und unregister_block_pattern_category.

Die Art und Weise, wie du deine eigenen Blockmuster erstellen kannst, ist ziemlich unkompliziert. Kopiere zum Beispiel den folgenden Code und füge ihn in ein benutzerdefiniertes Plugin oder in die Funktionsdatei eines Child Themes ein und ändere dann den Namen des Musters entsprechend deinen Vorlieben

add_action( 'init', function(){

	register_block_pattern_category( 
		'kinsta', 
		array( 'label' => __( 'Kinsta stuff', 'kinsta-pattern' ) ) );

	register_block_pattern(
	'kinsta-pattern/my-custom-pattern',
	array(
		'title'			=> __( 'Two Kinsta buttons', 'kinsta-pattern' ),
		'description'	=> _x( 'Two nice buttons.', 'Kinsta Buttons', 'kinsta-pattern' ),
		'content'		=> "<!-- wp:buttons {\"align\":\"center\"} -->\n<div class=\"wp-block-buttons aligncenter\"><!-- wp:button {\"backgroundColor\":\"very-dark-gray\",\"borderRadius\":0} -->\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link has-background has-very-dark-gray-background-color no-border-radius\">" . esc_html__( 'Button One', 'kinsta-pattern' ) . "</a></div>\n<!-- /wp:button -->\n\n<!-- wp:button {\"textColor\":\"very-dark-gray\",\"borderRadius\":0,\"className\":\"is-style-outline\"} -->\n<div class=\"wp-block-button is-style-outline\"><a class=\"wp-block-button__link has-text-color has-very-dark-gray-color no-border-radius\">" . esc_html__( 'Button Two', 'kinsta-pattern' ) . "</a></div>\n<!-- /wp:button --></div>\n<!-- /wp:buttons -->",
		'categories'	=> array( 'kinsta' ),
	)
	);
});

Der obige Code ist eine einfache Anpassung des Original-Snippets aus der Block-API-Referenz

Siehe auch Blockmuster in WordPress 5.5.

Natives Image-Lazy-Loading im WordPress-Kern

Lazy Loading ist eine Optimierungstechnik, die das Laden von unkritischen Ressourcen aufschiebt. Das bedeutet, dass der Browser angewiesen wird, sichtbare Inhalte beim Laden der Seite zu laden und das Herunterladen und Rendern von Bildern, die sich Below the Fold befinden, so lange aufzuschieben, bis sie tatsächlich benötigt werden.

Vor dem systemeigenen Lazy Loading konnten Webentwickler Assets per JavaScript, über die IntersectionObserver API oder mit Hilfe von Scroll-, Größen– und Orientierungsänderungs–Eventhandlern Lazy Laden.

Aber seit Lazy Loading ein Standard geworden ist, brauchen wir keinen eigenen Code mehr zu schreiben oder JavaScript-Bibliotheken zu verwenden und Lazy Loading-Bilder können mit dem neuen Loading-Attribut in img– und iframe-Tags implementiert werden.

Das Ladeattribut legt fest, ob der Browser eine Ressource sofort laden oder warten soll, bis einige Bedingungen erfüllt sind. Derzeit unterstützt es die folgenden Werte:

• Lazy: warte, bis einige Bedingungen erfüllt sind
• Eifrig: lade die Ressource sofort

Zum Zeitpunkt der Erstellung dieses Artikels wird Lazy Loading von Microsoft Edge, Firefox, Google Chrome, Opera Browser, Android Browser und Chrome für Android unterstützt.

Vor WordPress 5.5 war Lazy Loading in WordPress nur mit einem Optimierungs-Plugin wie Autoptimize, BJ Lazy Load, oder anderen möglich. Jetzt ist es Teil des WordPress-Kerns und es müssen keine zusätzlichen Plugins installiert werden!

Natives Lazy Loading in WordPress

Wie Felix Arntz in einem alten Blog-Post auf dem Make WordPress Core Blog berichtete, wurde vor ein paar Jahren ursprünglich eine JavaScript-Implementierung von Lazy Loading in WordPress vorgeschlagen, aber es wurde nie Teil des Core. Die neue Implementierung des nativen Lazy Loading von Bildern beseitigt jegliche Kompatibilitätsprobleme und jetzt kann die neue Funktion mit WordPress 5.5 sicher in den Core eingebunden werden.

Laut Felix würde sich das native Lazy Loading von WordPress-Bildern bei einer großen Anzahl von WordPress-Seiten, die keine Lazy Loading-Plugins verwenden, positiv auf die Leistung der Webseite und das Benutzererlebnis auswirken:

… ohne technisches Wissen oder gar ein Bewusstsein für Lazy Loading als Konzept zu benötigen. Die Übernahme des neuen Ladeattributs ist eine große Chance für WordPress, den Weg für ein insgesamt schnelleres Web zu ebnen.

Um Layoutverschiebungen zu verhindern, wird loading="lazy" automatisch zu img-Tags mit width– und height-Attributen hinzugefügt und das ist nur möglich, wenn das Bild für WordPress als Anhang verfügbar ist und eine wp-image-$id-Klasse enthält.

Lazy Loading ist eine Must-Have-Optimierung für jede WordPress-Installation und Webseiten mit einer beträchtlichen Menge an Bildern. Anmerkungen von Felix:

Dadurch wird sowohl auf den Servern als auch bei den User Agents drastisch Bandbreite eingespart, und zwar sowohl auf den Servern als auch bei den User Agents von Webseiten, auf denen Bilder weiter unten auf der Seite sofort geladen werden, selbst für den Fall, dass der User nie zu ihnen scrollen sollte.

Natives Lazy Loading in WordPress funktioniert mit den folgenden Bildern:

• Bilder in post content (the_content).
• Bilder in post excerpts (the_excerpt).
• Bilder in text widgets (widget_text_content).
• Avatar-Bilder, die mit get_avatar() gerendert wurden.
• Template-Bilder mittels wp_get_attachment_image

Mit der ersten Implementierung unterstützt Lazy Loading nur Bilder, aber wir können eine zukünftige Verbesserung von Lazy Loading für iframe-Tags erwarten.

Lazy Loading für WordPress-Entwickler

Entwickler können das Standardverhalten durch verschiedene neue Filter außer Kraft setzen. Unter diesen Filtern sind wp_lazy_loading_enabled und wp_img_tag_add_loading_attr die nützlichsten für Entwickler:

• wp_lazy_loading_enabled schaltet das Attribut loading ein und aus. Dieser Filter kann global oder pro Tag angewendet werden.
• wp_img_tag_add_loading_attr filtert den Wert des Ladeattributs und bietet eine Möglichkeit, Lazy Loading pro Bild zu kontrollieren.

Das folgende Beispiel zeigt, wie man Lazy Loading global deaktivieren kann:

add_filter( 'wp_lazy_loading_enabled', '__return_false' );

Wir können auch Lazy Loading für einen bestimmten Tag deaktivieren. Im untenstehenden Beispiel wird Lazy Loading für Bilder im Kontext_Inhalt deaktiviert (mehr dazu unter WordPress Core erstellen):

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

• $Standard: Der boolesche Standardwert (true).
• $tag_name: Der Tag-Name der Elemente, die mit Lazy Loading geladen werden sollen.
• $Kontext: Ein optionaler Parameter, der den Kontext des Bildes angibt (siehe Liste oben).

Beachte, dass zum Zeitpunkt des Schreibens dieses Artikels der Parameter $tag_name nur den img-Tag unterstützt. Jedenfalls sollten, wie oben erwähnt, weitere Tags in zukünftigen Implementierungen hinzugefügt werden.

Wenn ihr mehr granulare Kontrolle über Image Lazy Loading in WordPress haben wollt, könnt ihr je nach Kontext zwei verschiedene Ansätze verfolgen.

Wenn du an den Inhalten arbeitest (d.h. the_content, the_excerpt, widget_text_content), könntest du den wp_img_tag_add_loading_attr Filter verwenden. Das folgende Beispiel zeigt, wie man Lazy Loading für ein bestimmtes Bild ausschalten kann:

add_filter(
	'wp_img_tag_add_loading_attr',
	function( $value, $image, $context ){
		if ( 'the_content' === $context ){
			$image_url = wp_get_attachment_image_url( 67, 'medium' );
			if ( false !== strpos( $image, ' src="' . $image_url . '"' ) ) {
				return false;
			}
		}
		return $value;
	},
	10,
	3
);

Theme-Entwickler können Bilder auch über wp_get_attachment_image kontrollieren. In diesem Szenario kannst du einfach den Wert des Ladeattributs des Bildes auf false setzen:

echo wp_get_attachment_image(
	67,
	'medium',
	false,
	array( 'loading' => false ),
);

Wenn du Image Lazy Loading vor der endgültigen Veröffentlichung von WordPress 5.5 ausprobieren möchtest, kannst du das offizielle Lazy Loading Feature Plugin installieren, oder den Quellcode auf Github überprüfen.

Native lazy-loading images is coming to #WordPress 5.5, for faster sites and less waste of network resources! And it's accompanied by further image improvements which reduce those annoying layout shifts that make you accidentally click on the wrong things. https://t.co/e7g2s9uSPk

— Felix Arntz (@felixarntz) July 14, 2020

Weitere Infos zum Thema Lazy Loading von Bildern in WordPress 5.5 findest du auf dem Blog Make WordPress Core.

Auto-Updates für Plugins und Themes

Eines der größten Anliegen der Betreiber von Webseiten ist die Sicherheit der Webseite. Deine Software auf dem neuesten Stand zu halten, ist eine allgemeine Empfehlung, die jeder Webseitenbetreiber in Betracht ziehen sollte.

WordPress Automatische Updates sind seit WordPress 3.7 als Feature verfügbar. Nun, das Problem hier ist, dass während automatische Updates für die Wartung und Sicherheitsversionen standardmäßig aktiviert sind, nutzten vor WordPress 5.5 viele Webseitenbetreiber die automatischen Updates für Plugins und Themes nicht.

Der Grund dafür ist, dass diese Funktion grundlegende Kenntnisse der WordPress-Entwicklung voraussetzte. Tatsächlich konnten die Entwickler ihre Update-Einstellungen feinabstimmen, indem sie eine oder mehrere Konstanten in der wp-config.php definierten oder einen Filter in einem Plugin verwendeten.

Mit WordPress 5.5 können Seitenadministratoren jetzt Plugin- und Theme-Auto-Updates mit einem einzigen Klick direkt in ihrem WordPress-Dashboard ein- und ausschalten.

Plugin-Auto-Updates können aktiviert und deaktiviert werden, indem man auf den Link klickt, der in der Spalte „Automatische Updates“ erscheint, die jetzt auf dem Plugin-Bildschirm verfügbar ist.

Wenn du automatische Updates für dein Theme aktivieren möchtest, gehe zu Appearance > Themes, fahre dann mit der Maus über dein Theme und klicke auf Theme Details. Klicke dann auf den neuen Link Automatische Updates aktivieren und du bist fertig.

Die neue Auto-Update-UI für Plugins und Themes kommt zusammen mit verschiedenen Funktionen und Hooks, die den Entwicklern zur Verfügung stehen, um die Auto-Update-Erfahrung anzupassen.

Auto-Update-Funktionen und Filter für Plugin- und Theme-Entwickler

Eine neue Funktion und mehrere Filter ermöglichen es den WordPress-Entwicklern, viele Aspekte der automatischen Plugin- und Theme-Aktualisierungen anzupassen.

Automatische Update-UI prüfen

Die neue WordPress-Funktion wp_is_auto_update_enabled_for_type() prüft, ob die Auto-Update-UI für einen bestimmten Typ aktiviert ist. Die neue Funktion behält ein einziges Argument ($type), das den Typ des zu prüfenden Updates bestimmt ('theme' oder 'plugin') und entsprechend true oder false zurückgibt.

Die neue Auto-Update-UI kann dank zweier neuer Filter für Plugins oder Themes deaktiviert werden: plugins_auto_update_enabled und themes_auto_update_enabled. Siehe das Beispiel unten:

// Disable plugins auto-update UI elements.
add_filter( 'plugins_auto_update_enabled', '__return_false' );

// Disable themes auto-update UI elements.
add_filter( 'themes_auto_update_enabled', '__return_false' );

Die obigen Filter sind in wp-admin/includes/update.php dokumentiert.

Auto-Update-Links anpassen

Plugin- und Theme-Entwickler können die HTML-Ausgabe von Auto-Update-Links anpassen.

Der plugin_auto_update_setting_html Filter erlaubt es, Toggle-Links und den Zeitablauf zwischen zwei Update-Versuchen anzupassen.

Die Callback-Funktion behält drei Argumente:

• $html: Der HTML-Code der Spalteninhalte des Plugins für die automatische Aktualisierung, einschließlich der Aktionslinks für die automatische Aktualisierung und der Zeit bis zum nächsten Update.
• $plugin_Datei: Der Pfad zur Plugin-Datei relativ zum Plugins-Verzeichnis.
• $plugin_data: Pfad zur Plugin-Datei: Eine Reihe von Plugin-Daten.

Nun, wenn du die Beschriftung des Auto-Update-Link-Textes anpassen möchtest, kannst du den Filter wie im folgenden Snippet gezeigt benutzen.

add_filter( 'plugin_auto_update_setting_html', function( $html, $plugin_file, $plugin_data ){
	if ( 'kinsta-plugin/kinsta-plugin.php' === $plugin_file ) {
		$html = __( 'Custom HTML', 'kinsta-plugin' );
	}
	return $html;	
	}, 
	10, 
	3 
);

Das Bild unten zeigt das Ergebnis auf dem Bildschirm.

Dieser Filter ist in wp-admin/includes/class-wp-plugins-list-table.php dokumentiert.

Auf einzelnen Webseiten kannst du das JS-Template des Auto-Update-Links über den Filter theme_auto_update_setting_template anpassen. Der Blogeintrag zur Einführung der Plugin- und Theme-Auto-Updates liefert das folgende Beispiel für diesen Filter:

function myplugin_auto_update_setting_template( $template ) {
    $text = __( 'Auto-updates are not available for this theme.', 'my-plugin' );
 
    return "<# if ( [ 'my-theme', 'twentytwenty' ].includes( data.id ) ) { #>
        <p>$text</p>
        <# } else { #>
        $template
        <# } #>";
}
add_filter( 'theme_auto_update_setting_template', 'myplugin_auto_update_setting_template' );

Es wird empfohlen, das Ziel-Theme mit dem data.id Parameter zu überprüfen.

Wenn du an einer Multisite-Installation von WordPress arbeitest, dann brauchst du den Filter theme_auto_update_setting_html, mit dem du die Links für automatische Updates des Themes-Bildschirms auf die gleiche Weise anpassen kannst wie den Plugins-Bildschirm.

Schließlich kontrollieren zwei zusätzliche Filter alle automatischen Updates für jedes Theme und Plugin, einschließlich Themes und Plugins, die in Zukunft installiert werden sollen.

Diese Filter, die seit WordPress 3.7 verfügbar sind, überschreiben alle Auto-Update-Einstellungen in deinem WordPress-Dashboard. Du kannst mehr darüber in unseren Deep Dive Into WordPress Automatic Updates lesen. Für einen tieferen Einblick in die automatischen Updates für Plugins und Themes, lest mehr in diesem Blogbeitrag.

Automatische E-Mail-Benachrichtigungen und Informationen zur Funktionsfähigkeit deiner Webseite

Seit WordPress 5.5 wird nach jedem Auto-Update-Versuch eine E-Mail-Benachrichtigung verschickt.

Der auto_plugin_theme_update_email filtert die E-Mails, die nach einem automatischen Hintergrundupdate gesendet werden. Siehe den Blog-Eintrag dev-notes für ein Anwendungsbeispiel.

Auto-Update-E-Mail-Benachrichtigungen können auch mit zwei neuen Filtern deaktiviert werden:

// Disable auto-update email notifications for plugins.
add_filter( 'auto_plugin_update_send_email', '__return_false' );

// Disable auto-update email notifications for themes.
add_filter( 'auto_theme_update_send_email', '__return_false' );

Plugin and theme auto-update information is also displayed in the Site Health Info tab.

Entwickler können den Text, der auf diesem Bildschirm erscheint, mit den Filtern plugin_auto_update_debug_string und theme_auto_update_debug_string anpassen. Mehr Infos und einige Beispiele gibt es hier.

Erweiterbare Core-Sitemaps

 

Eine Sitemap ist einfach eine Liste von URLs, die es Suchmaschinen ermöglicht, deine Webseite schnell zu durchforsten.

Sitemaps sind der robots.txt recht ähnlich, mit dem Unterschied, dass eine robots.txt-Datei Inhalte von der Indizierung ausschließt, während eine Sitemap eine Liste von URLs enthält, die von Suchmaschinen indexiert werden können.

Vor WordPress 5.5 konnten Sitemaps nur mit einem Plugin oder anderen Tools zu WordPress Webseiten hinzugefügt werden.

Jetzt bringt WordPress 5.5 eine brandneue XML-Sitemap-Funktion in den WordPress Core.

Das neue Feature fügt grundlegende Funktionen hinzu, aber es kommt mit einer guten Anzahl von Hooks und Filtern, die es Plugin-Entwicklern erlauben, die eingebauten Funktionalitäten weiter auszubauen.

XML-Sitemaps sind standardmäßig aktiviert (es sei denn, du rätst Suchmaschinen davon ab, deine Webseite zu indexieren) und bieten die folgenden Objekttypen:

• Startseite
• Posts-Seite
• Hauptposttypen (Pages und Posts)
• Benutzerdefinierte Posttypen
• Kern-Taxonomien (Stichwörter und Kategorien)
• Zolltaxonomien
• Autoren-Archiv

Der indexierte Sitemap-Index ist unter /wp-sitemap.xml verfügbar, der maximal 2.000 URLs enthält. Wenn die maximale Anzahl erreicht ist, wird eine neue Sitemap-Datei hinzugefügt.

Wie bereits erwähnt, können Plugin-Entwickler ihre Sitemaps mit einer oder mehreren der vielen verfügbaren Aktionen und Filter anpassen. Eine umfassende Liste der Sitemap-bezogenen Hooks findet ihr in der Dokumentation des Plugins und im einführenden Blog-Eintrag.

Als Beispiel kannst du die Core-Sitemaps programmatisch deaktivieren, indem du den Filter wp_sitemaps_enabled verwendest, der filtert, ob XML-Sitemaps aktiviert sind oder nicht:

add_filter( 'wp_sitemaps_enabled', '__return_false' );

Die Core-Sitemaps sollten nicht mit den Sitemap-Plugins in Konflikt geraten, die du eventuell auf deiner Webseite installiert hast. Laut Pascal Birchler auf Make WordPress Core:

Das Kern-Sitemaps-Feature wurde in einer robusten und leicht erweiterbaren Weise gebaut. Wenn aus irgendeinem Grund zwei Sitemaps auf einer Webseite angezeigt werden (eine durch den Kern, eine durch ein Plugin), hat dies keine negativen Folgen für die Auffindbarkeit der Webseite.

Als Teil der XML-Sitemaps-Funktion gibt es eine neue Funktion esc_xml(), die Strings für XML-Blöcke umgeht. Die Funktion und der entsprechende Filter sind in wp-includes/formatting.php dokumentiert.

Zum Zeitpunkt des Schreibens dieses Artikels unterstützt das neue Sitemap-Feature keine Bild/Video/News-Sitemaps und dies wird sich in Zukunft wahrscheinlich auch nicht ändern. Wie auch immer, neue Filter und Hooks, die es den Entwicklern erlauben, dieses Feature hinzuzufügen, könnten in zukünftigen Versionen hinzukommen.

Weitere Informationen über erweiterbare Sitemaps findest du in der Einführung der Entwickler zu Sitemaps, in der neue Klassen, Funktionen, Hooks und Filter behandelt werden.

Argumente an Template-Dateien weitergeben

Vor WordPress 5.5 war die Übergabe von Daten an Template-Dateien nur über globale Variablen, Abfragevariablen und ein paar andere nicht optimale Optionen möglich. Jetzt, beginnend mit WordPress 5.5, wurde ein $args-Parameter zu den Funktionen zum Laden von Templates hinzugefügt (die entsprechenden Hooks wurden entsprechend aktualisiert):

• get_header()
• get_footer()
• get_sidebar()
• get_template_part()
• locate_template()
• load_template()

Theme-Entwickler können nun eine Variable in einer Template-Datei setzen und es in jedem enthaltenen Template-Teil zugänglich machen, indem sie einfach eine Reihe von Argumenten übergeben.

Während dieses Feature den Theme-Entwicklern neue Möglichkeiten eröffnet, stellt Justin Tadlock in der WP-Taverne eine gute Frage:

Eine Frage bleibt: Ist die Ankunft dieses Features zu spät? Da WordPress auf dem besten Weg ist, das gesamte Theme-System zu überarbeiten, um es in die kommende Vollversion der Webseite zu integrieren, wird dieses Feature nur für die nächsten paar Monate nützlich sein?

Ein guter Punkt kommt von John Blackbourne:

Sogar in einer Zukunft, in der die gesamte Webseite bearbeitet wird, gibt es immer noch einen großen Bedarf an Template Teilen. Dynamisch gerenderte Blocktypen können zum Beispiel strukturierte Template-Teile gut gebrauchen und tun es auch. Sie schließen sich nicht gegenseitig aus, und es wird immer eigenwillige Themes geben, die nicht ausgiebig auf Blöcke für das Layout zurückgreifen.

Schließlich erreichten wir Enrico Sorcinelli, WP Core Contributor, der seine Gedanken mit uns teilte:

Wenn du mich fragst, ob wir zu spät gekommen sind, aus meiner Sicht ist es nie zu spät!

Ich glaube, dass in Zukunft Theme-Entwickler von dieser Möglichkeit profitieren können, was nicht ausschließt, dass es in Symbiose mit dem aufkommenden Full-Site-Editing-Ansatz (z.B. für Blöcke mit dynamischem Rendering) verwendet werden kann.

Vielleicht ist es einfach noch zu früh, um zu sagen, wie genau dieses Feature mit dem Full-Site-Editing zusammenpasst, aber eines scheint sicher zu sein: Die zukünftige Entwicklung wird großartige Möglichkeiten bringen, bessere Webseiten sowohl für Benutzer als auch für Entwickler zu erstellen.

Plugins und Themes aus einer .zip-Datei aktualisieren

Ich weiß, was du denkst: es mag ziemlich „unerwartet“ erscheinen, wenn dieses Feature in Verbindung mit automatischen Updates erscheint. Nichtsdestotrotz macht es Sinn.

Vor WordPress 5.5, als es noch keine Ein-Klick-Update-Funktion gab, konnten Seitenadministratoren Plugin-/Theme-Updates nur per FTP/SFTP oder Dateimanager hochladen (lernen Sie den Unterschied zwischen FTP und SFTP). Das war vor allem bei benutzerdefinierten Plugins/Themes oder bei Erweiterungen, die auf Marktplätzen von Drittanbietern gehostet wurden, der Fall.

Beginnend mit WordPress 5.5 kannst du Plugins und Themes aktualisieren, indem du ein .zip-Paket von deinem Computer in deinem WordPress-Dashboard hochlädst.

Wenn du ein Plugin aktualisieren möchtest, gehe zu Plugins > Neuen Bildschirm hinzufügen und klicke auf die Schaltfläche Plugin hochladen. Wenn du das Plugin auf deiner Webseite installiert hast, erscheint ein neuer Bildschirm mit der Meldung „Dieses Plugin ist bereits installiert“ und zeigt die aktuelle Version und die Details der hochgeladenen Version an.

Der Prozess ist bei Theme Updates ziemlich ähnlich.

Gehe zum Bildschirm Appearance > Themes und klicke dann auf Add New und dann auf Upload Theme. Wenn du das Theme bereits auf deiner WordPress-Webseite installiert hast, erscheint ein neuer Bildschirm mit dem Hinweis „Dieses Theme ist bereits installiert“ und zeigt die aktuelle Version und die Details der hochgeladenen Version an.

Zusätzliche Verbesserungen für Entwickler, die mit WordPress 5.5 kommen

Zusätzlich zu dem, was wir bisher behandelt haben, verdienen ein paar Ergänzungen die Aufmerksamkeit eines Entwicklers.

Neue wp_get_environment_type() Funktion

Eine neue wp_get_environment_type()-Funktion erlaubt es dir, den aktuellen Umgebungstyp einer Webseite zu erkennen, wodurch die Entwickler Plugin- und Theme-Funktionalitäten an die aktuelle Umgebung anpassen können.

Standardmäßig gibt wp_get_environment_type() die Produktion zurück. Andere unterstützte Werte sind Entwicklung und Staging. Jedenfalls ist es den Entwicklern erlaubt, bei Bedarf zusätzliche Umgebungstypen zu definieren.

Es gibt drei Methoden, um einen Webseiten-Staging-Umgebung festzulegen. Von einer Prioritätsreihenfolge, die du verwenden kannst:

• WP_ENVIRONMENT_TYPE PHP-Umgebungsvariable.
• WP_ENVIRONMENT_TYPE Konstante.
• wp_get_umgebungs_type filter.

Als Beispiel, wenn du deine Umgebung auf Staging setzen möchtest, kannst du die Konstante WP_ENVIRONMENT_TYPE in deiner wp-config.php Datei wie unten gezeigt definieren:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

Wenn der Umgebungstyp Entwicklung ist, wird WP_DEBUG automatisch auf true gesetzt, auch wenn du es nicht explizit definiert hast.

REST API Änderungen in WordPress 5.5

WordPress 5.5 bringt auch viele Änderungen an der REST API mit sich. Wir werden einige neue Endpunkte, neue Parameter und JSON-Schema-Änderungen, neue Funktionen und weitere Verbesserungen sehen.

Hier ist eine kurze Liste der neuen Endpunkte:

Block-Typen

Ein neuer Endpunkt erlaubt es, alle registrierten Blocktypen zu erhalten:

• GET /wp/v2/block-types wird alle registrierten Blocktypen zurückgeben.
• GET /wp/v2/block-types/core gibt alle Blöcke innerhalb des Core-Namensraums zurück.
• GET /wp/v2/block-types/core/quote gibt die Core-Anführungszeichen-Blockdefinition zurück.

Plugins

Ein neuer Endpunkt erlaubt es, Plugins zu verwalten:

• GET /wp/v2/plugins gibt eine Liste aller installierten Plugins zurück.
• GET /wp/v2/plugins/plugin-name/plugin-name gibt Informationen über das angegebene Plugin zurück.
• POST /wp/v2/plugins { slug: "plugin-name" } installiert das angegebene Plugin aus dem Plugin-Verzeichnis
• PUT /wp/v2/plugins/plugin-name/plugin-name { status: "aktiv" } aktiviert das angegebene Plugin
• DELETE /wp/v2/plugins/plugin-name/plugin-name löscht ein inaktives Plugin.

Block Directoy

Ein neuer Endpunkt erlaubt es, das Blockverzeichnis zu durchsuchen:

• GET /wp/v2/block-directory/search?term=block-name durchsucht das Block-Verzeichnis nach block-name

Bildbearbeitung

In Verbindung mit der neuen Inline-Bildbearbeitungsfunktion ermöglicht ein neuer Endpunkt das Bearbeiten von Bildanhängen in der Medienbibliothek:

POST /wp/v2/v2/media/5/edit bearbeitet das Bild mit der ID 5

Siehe WordPress Core dev notes für einen genaueren Blick auf alle Änderungen an der REST API, die mit WordPress 5.5 kommen.

Zusammenfassung

Wir sind begeistert von all diesen neuen Funktionen und Verbesserungen, die WordPress 5.5 in einem einzigen Release mit sich bringt.

Es zeigt die riesige Menge an Arbeit, die hinter den Kulissen passiert, und wir schätzen die Anstrengungen und das Engagement von jedem einzelnen Mitwirkenden sehr.

Wenn euch die oben aufgeführten Änderungen nicht ausreichen, hier sind noch mehr, dann solltet ihr nach weiteren Verbesserungen in WordPress 5.5 Ausschau halten:

• 65 neue Icons zur Dashicons Icon-Schriftart in WordPress Core hinzugefügt
• Verbesserungen der Zugänglichkeit – Linklisten in Widgets
• Neue CSS-Stile für deaktivierte Buttons
• Opcode-Cache-Invalidierung
• Bessere Kontrolle über redirect_guess_404_permalink()
• PHP-bezogene Verbesserungen
• Codebase-Änderungen
• Änderungen an benutzerdefinierten Logofunktionen und Filtern
• API-Aktualisierungen blockieren
• Archiv Seitenüberschriften Filter
• Icons hinzufügen in Twenty Twenty
• Und viele mehr

Nimm an unserem kostenlosen Webinar teil, das ganz WordPress 5.5 gewidmet ist!

Jetzt bist du dran. Was sind die Funktionen und/oder Verbesserungen, die dir an WordPress 5.5 am besten gefallen? Und welche Features würdest du gerne zu WordPress 5.6 hinzufügen? Teilt eure Gedanken im Kommentarbereich unten mit!