WordPress 6.1 „Misha“ ist am 1. November 2022 veröffentlicht worden. Es ist das dritte große Release des Jahres nach WordPress 6.0 Arturo, das am 24. Mai veröffentlicht wurde, und WordPress 5.9 Josephine, das am 25. Januar erschien.
Wie immer bringen neue WordPress-Versionen neue Funktionen, Verbesserungen und Fehlerbehebungen aus den neuesten Versionen des Gutenberg-Plugins in den Kern. WordPress 6.1 ist da keine Ausnahme, denn 11 Versionen des Gutenberg-Plugins wurden in den Core integriert, von 13.1 bis 14.1.
In diesem Beitrag werfen wir einen Blick hinter die Kulissen und stellen die neuen spannenden Funktionen vor, die mit der neuen Hauptversion von WordPress kommen.
Matias Ventura gab uns einige Einblicke in die Roadmap zu 6.1, in der er sagte, dass das Ziel von 6.1 darin besteht, die mit 5.9 und 6.0 eingeführten Erfahrungen zu verfeinern und einige Dinge zu beheben, während wir uns Phase 3 der Gutenberg-Roadmap nähern.
1. Verbesserungen im Vorlageneditor: Eine der wichtigsten neuen Funktionen ist der Vorlageneditor. WordPress 6.1 soll die Möglichkeit bieten, die Struktur der Website zu durchsuchen, zu visualisieren und zu bearbeiten.
2. Vorlagen-Muster: Ziel ist es, den Blockmustern eine zentrale Rolle bei der Vorlagen- und Seitenerstellung zu geben, sie an benutzerdefinierte Beitragstypen und Blocktypen anzupassen, die Sperrfunktion zu verbessern, die Verwaltung gespeicherter Muster zu verbessern usw.
3. Globale Stile und Blöcke & Design Tools: WordPress 6.1 wird es ermöglichen, Webfonts zu verwalten, responsive Typografie zu implementieren und das Toolset für Blöcke zu erweitern.
Schauen wir uns also einige der wichtigsten Funktionen von WordPress 6.1 genauer an:
Fluid Typography und Abstände
WordPress 6.1 bietet Unterstützung für Fluid Typography über calc/clamp CSS-Funktionen.
Der Ausdruck Fluid Typography beschreibt die Fähigkeit von Text, sich an die Breite des Viewports anzupassen, indem er von einer minimalen zu einer maximalen Breite skaliert.
Das ist etwas anderes als das, was du mit Media-Queries erreichen kannst, denn Media-Queries ermöglichen es Themes, die Größe von Text in Abhängigkeit von bestimmten Viewport-Größen zu ändern, tun aber nichts zwischen verschiedenen Werten.
Einige Themes unterstützen bereits fluide Typografie. Twenty Twenty-Two zum Beispiel nutzt die CSS-Funktion clamp() für verschiedene Schriftgrößen. Ein Beispiel:
"settings": {
...
"custom": {
"spacing": {
"small": "max(1.25rem, 5vw)",
"medium": "clamp(2rem, 8vw, calc(4 * var(--wp--style--block-gap)))",
"large": "clamp(4rem, 10vw, 8rem)",
"outer": "var(--wp--custom--spacing--small, 1.25rem)"
},
"typography": {
"font-size": {
"huge": "clamp(2.25rem, 4vw, 2.75rem)",
"gigantic": "clamp(2.75rem, 6vw, 3.25rem)",
"colossal": "clamp(3.25rem, 8vw, 6.25rem)"
}
}
}
}Wie du im obigen Code sehen kannst, werden für jede einzelne Schriftgröße fließende Schriftgrößenwerte verwendet.
Ab WordPress 6.1 können Themes jetzt automatisch fluide Schriftgrößen erzeugen, indem sie die neue Eigenschaft typography.fluid wie folgt deklarieren:
"settings": {
....
"typography": {
"fluid": true,
"fontSizes": [
{
"size": "2rem",
"fluid": {
"min": "2rem",
"max": "2.5rem"
},
"slug": "medium",
"name": "Medium"
}
]
}Mit Hilfe von typography.fluid und typography.fontSizes[].fluid wird der Wert jeder Schriftgröße automatisch nach der folgenden Formel berechnet:
--wp--preset--font-size--{slug}: clamp({fluid.min}, {fluid.min} + ((1vw - 0.48rem) * 1.592), {fluid.max});Zum Beispiel:
--wp--preset--font-size--large: clamp(2rem, 2rem + ((1vw - 0.48rem) * 1.592), {2.5rem});Beachte, dass Fluid Typography zum Zeitpunkt der Erstellung dieses Artikels eine experimentelle Funktion ist. Du kannst die technischen Details in Block supports: add fluid typography nachlesen.
Fluid typography is a significant improvement for building modern #WordPress websites. We just updated @frostwp to include this feature. Here’s a great read from @richard_tabor into what it is and why it matters. https://t.co/Bq5YuHX3wi
— Brian Gardner (@bgardner) August 8, 2022
Siehe auch How to add Fluid Typography to WordPress Block Themes von Rich Tabor und Fluid typography with Gutenberg von Carolina Nymark.
Ähnlich wie die Fluide Typografie führt WordPress 6.1 auch die Unterstützung für Fluid Spacing ein.
Vor WordPress 6.1 war es nur möglich, benutzerdefinierte Abstandswerte im Editor festzulegen, und Theme-Autoren durften keine festen Werte für Padding, Margin und Gap angeben. Daher war es nicht möglich, die Einstellungen für die Abstände von einem Theme auf ein anderes zu übertragen oder die Abstände beim Kopieren und Einfügen von Inhalten zwischen verschiedenen Websites beizubehalten.
Jetzt können Theme-Entwickler die Unterstützung von Fluid Spacing über die Einstellungen spacing.spacingScale und spacing.spacingSizes[] deklarieren (siehe auch Theme.json: Voreinstellungen für die Abstandsgröße hinzufügen und theme.json erweitern, um Voreinstellungen für die Abstandsgröße bereitzustellen).
"settings": {
"spacing": {
"spacingScale":
{
"steps": 0
},
"spacingSizes": [
{
"size": "clamp(1.5rem, 5vw, 2rem)",
"slug": "30",
"name": "1"
},
{
"size": "clamp(1.8rem, 1.8rem + ((1vw - 0.48rem) * 2.885), 3rem)",
"slug": "40",
"name": "2"
},
{
"size": "clamp(2.5rem, 8vw, 6.5rem)",
"slug": "50",
"name": "3"
},
{
"size": "clamp(3.75rem, 10vw, 7rem)",
"slug": "60",
"name": "4"
},
{
"size": "clamp(5rem, 5.25rem + ((1vw - 0.48rem) * 9.096), 8rem)",
"slug": "70",
"name": "5"
},
{
"size": "clamp(7rem, 14vw, 11rem)",
"slug": "80",
"name": "6"
}
],
...
}
}Du findest die Eigenschaften von Fluid Typography und Spacing in den Globalen Einstellungen & Stilvorgaben und in living reference to theme.json API V2.
Bearbeitung von Blöcken nur für den Inhalt
WordPress 6.1 führt die reine Inhaltsbearbeitung für Blöcke, Muster und Vorlagen ein. Wenn die reine Inhaltsbearbeitung aktiviert ist, können die Nutzer/innen nur den Inhalt eines Blocks oder Musters ändern, damit sie nicht versehentlich das Layout zerstören oder die Stile ändern.
Derzeit ist es nicht möglich, die reine Inhaltsbearbeitung über die Oberfläche des visuellen Editors zu aktivieren. Um diese Funktion zu aktivieren, muss das Attribut templateLock auf contentOnly gesetzt werden und du kannst dafür den Code-Editor verwenden.
Das folgende Bild zeigt ein einfaches Beispiel.
Wenn die reine Inhaltsbearbeitung für einen Block oder ein Muster aktiviert ist, ändert sich die Einstellungs-Seitenleiste. Du siehst dann nicht mehr die üblichen Einstellungselemente, sondern eine Liste der Blöcke, die in der Gruppe enthalten sind. Du kannst jeden dieser Blöcke auswählen, indem du auf den Block im Editor-Canvas oder auf das entsprechende Listenelement in der Seitenleiste klickst.
Du kannst die reine Inhaltsbearbeitung deaktivieren, indem du auf die Schaltfläche Ändern in der Gruppensymbolleiste klickst.
Wenn du mit deinen Bearbeitungen fertig bist, kannst du die reine Inhaltsbearbeitung wieder aktivieren, indem du auf die Schaltfläche „Fertig“ klickst.
Außerdem werden Blöcke, die keinen Inhalt haben, aus der Listenansicht ausgeblendet und erhalten keinen Fokus in der Blockliste.
Mehr über das reine Bearbeiten von Inhalten erfährst du in der Entwicklungsnotiz und in diesem Blogbeitrag von Rich Tabor.
Verbesserte Blocktypen
Da so viele Gutenberg-Versionen in den Kern integriert wurden, wird WordPress 6.1 viele Änderungen und Verbesserungen an bestehenden Blocktypen mit sich bringen.
Randunterstützung für den Columns-Block hinzugefügt
Der Columns-Block nutzt jetzt die neue BorderBoxControl-Komponente, mit der WordPress-Nutzer/innen benutzerdefinierte Ränder für Spalten festlegen und für jeden Rand einen anderen Stil einstellen können (siehe auch Column: Add border support to column blocks pull request).
Einzelne Ränder können auch in der Datei theme.json wie folgt eingestellt werden:
"core/column": {
"border": {
"top": {
"color": "#CA2315",
"style": "dashed",
"width": "6px"
},
"right": {
"color": "#FCB900",
"style": "solid",
"width": "6px"
}
}
}Entwickler/innen können mehr über das neue Steuerelement in der Komponentenreferenz – BorderBoxControl lesen.
Border Controls für Bildblöcke
Gutenberg 13.8 hat die Unterstützung für alle Rahmensteuerungen für den Bildblock eingeführt. Diese Änderung wird mit WordPress 6.1 in den Kern von WordPress übernommen und eröffnet neue und großartige Möglichkeiten für Webkreative.
Verbesserungen am Kommentarblock
WordPress 6.1 bringt uns auch einen verbesserten Kommentarblock.Ab der nächsten Version von WordPress können Nutzer/innen erweiterte Bearbeitungsfunktionen für den Kommentarbereich nutzen.
In der Abbildung unten siehst du die Seitenleiste mit den Einstellungen für den Kommentarblock und die Änderungen am Kommentartitel.
Variationen des Post Terms Blocks für benutzerdefinierte Taxonomiebegriffe
Der Post Terms-Block wurde um eine neue benutzerdefinierte Taxonomie-Variante erweitert. Du kannst jetzt eine neue benutzerdefinierte Taxonomie registrieren, z. B. den Beitragstyp „Schauspieler in einem Film“, und du kannst dem aktuellen Beitrag oder dem benutzerdefinierten Beitragstyp eine Liste von Taxonomiebegriffen hinzufügen.
Das Bild unten zeigt eine Liste von Schauspielern in einem Film-Beitragstyp.
Ein neuer Parents-Filter für den Abfrageblock
Für den Abfrageblock gibt es jetzt einen neuen Parents-Filter, der hierarchische Beiträge und Seiten mit demselben Elternteil anzeigt.
Schriftfamiliensteuerung im Überschriftenblock
Der Überschriftenblock unterstützt jetzt Schriftfamilien-Steuerelemente.
Horizontale und vertikale Abstände im Galerie-Block
Seit WordPress 6.1 gibt es ein neues Steuerelement für den Achsenabstand, mit dem du unterschiedliche horizontale und vertikale Abstände für Bilder im Galerie-Block festlegen kannst.
Diese Änderung sorgt für mehr Flexibilität bei der Gestaltung von Bildergalerien.
Hervorgehobene Bilder im Titelblock
Featured Images bekommen nach wie vor viel Aufmerksamkeit, und in WordPress 6.1 wird der Umfang ihrer Verwendung noch erweitert. Ab 6.1 kann das Featured Image direkt aus dem Platzhalter des Cover-Blocks ausgewählt werden, wie die folgenden Bilder zeigen.
Diese Änderung soll zu einem einheitlicheren Nutzererlebnis beitragen und den Nutzern klarer machen, was sie gerade anpassen.
Außerdem wurde ein Featured Image Toggle zum Medienaustauschfluss hinzugefügt.
Erscheinungsbild-Tools für Post-Navigationslinks
Mit der Einstellungseigenschaft appearanceTools kannst du verschiedene Einstellungen vornehmen, die standardmäßig deaktiviert sind.
Seit WordPress 6.1 kannst du bei Themes, die die Einstellungseigenschaft appearanceTools unterstützen, die Linkfarbe und die Schriftart im Post Navigation Link anpassen.
Du kannst mehr über die Eigenschaft appearanceTools in unserer Einführung in das Twenty Twenty-Two-Theme lesen.
Sperre innerhalb des Container-Blocks mit einem Klick
Ein neuer Schalter ermöglicht es jetzt, Blöcke in einem Container mit einem einzigen Klick zu sperren. Dies gilt für Gruppen-, Cover– und Spaltenblöcke.
Verbesserter Listenblock
Der Listenblock wurde verbessert und nutzt jetzt auch innere Blöcke. Diese Änderung macht es einfacher, Listenelemente zu sortieren und einzurücken und führt definitiv zu einer verbesserten Benutzererfahrung.
Unterstützung von Pseudo-Elementen in Blockthemen
Blockthemen können jetzt das Aussehen von Elementen und Blöcken abhängig von ihrem Zustand (aktiv/fokussiert/schwebend) anpassen.
Dies ist ein Beispiel für die Verwendung von Pseudo-Selektoren mit Links, wie sie in der theme.json von Twenty Twenty-Three definiert sind:
"styles": {
...
"elements": {
"link": {
"color": {
"text": "var(--wp--preset--color--contrast)"
},
":hover": {
"typography": {
"textDecoration": "none"
}
},
":focus": {
"typography": {
"textDecoration": "underline dashed"
}
},
":active": {
"color": {
"text": "var(--wp--preset--color--secondary)"
},
"typography": {
"textDecoration": "none"
}
},
"typography": {
"textDecoration": "underline"
}
}
}
}Der folgende Code Button-Stile:
"styles": {
...
"elements": {
"button": {
"border": {
"radius": "0"
},
"color": {
"background": "var(--wp--preset--color--primary)",
"text": "var(--wp--preset--color--contrast)"
},
":hover": {
"color": {
"background": "var(--wp--preset--color--contrast)",
"text": "var(--wp--preset--color--base)"
}
},
":focus": {
"color": {
"background": "var(--wp--preset--color--contrast)",
"text": "var(--wp--preset--color--base)"
}
},
":active": {
"color": {
"background": "var(--wp--preset--color--secondary)",
"text": "var(--wp--preset--color--base)"
}
}
}
}
}Du kannst das Ergebnis in den folgenden Bildern sehen.
Du kannst aber auch Elemente auf Blockebene stylen. Der einzige Unterschied ist, dass du die Stile innerhalb eines Blocks definieren musst. Der folgende Code aus der theme.json von Twenty Twenty-Three wendet zum Beispiel Stile auf Links im Hauptblock Navigation an:
"styles": {
"blocks": {
"core/navigation": {
"elements": {
"link": {
":hover": {
"typography": {
"textDecoration": "underline"
}
},
":focus": {
"typography": {
"textDecoration": "underline dashed"
}
},
":active": {
"typography": {
"textDecoration": "none"
}
},
"typography": {
"textDecoration": "none"
}
}
},
"typography": {
"fontSize": "var(--wp--preset--font-size--small)"
}
}
}
}Zusätzliche Funktionen und Verbesserungen im Block-Editor
Obwohl es sich um eine Konsolidierungsversion handelt, bringt WordPress 6.1 so viele Änderungen und Verbesserungen mit sich, dass es unmöglich wäre, sie alle in einem Artikel aufzulisten (aber in diesem Artikel von Anne McCarty findest du eine umfassende Liste der Design-Tools für einzelne Blöcke).
Hier werden wir auf die folgenden Änderungen eingehen:
Schablonenteile-Variationen im Block-Inserter
Im Block-Inserter sind jetzt Variationen von Vorlagenteilen verfügbar, die das Hinzufügen von Vorlagenteilen zu deiner Website erleichtern.
Diese Änderung macht den Bearbeitungsprozess einfacher und schneller und ermöglicht es den Nutzern, mit nur wenigen Klicks alle Variationen eines Vorlagenteils auf einmal zu sehen.
Ränder und Abstände visualisieren
Eine kleine, aber nützliche Verbesserung ist die Hervorhebung der Ränder und Auffüllungen, während der Nutzer sie anpasst. Dadurch wird es viel deutlicher, wie viel Platz innerhalb oder außerhalb der Elemente hinzugefügt wird.
Verbesserungen an der Einstellungs-Seitenleiste
WordPress 6.1 bringt auch einige Verbesserungen an der Einstellungen-Seitenleiste mit sich.
Die Seitenleiste für die Beitragseinstellungen wurde leicht umgestaltet. Die Felder für das Beitragsformat, den Slug, die Vorlage und die Autoren sind jetzt aneinander angeglichen und haben die gleiche Breite. Außerdem wurde der Beitragsplaner vereinfacht, um das Erlebnis verständlicher zu machen. Auch der Bereich für die Vorlagen wurde in ein Popover verschoben, um Platz zu sparen und die Benutzeroberfläche aufzuräumen.
Außerdem wurde das Vorlagen-Panel durch einen Vorlagen-Link ersetzt. Wenn du auf den Vorlagen-Link klickst, wird die Standardvorlage in einem Popover angezeigt.
Design-Updates für das Veröffentlichungs-Popover
Die Datumsauswahl im Veröffentlichen-Popover wurde neu gestaltet und verwendet jetzt „bestehende WordPress-Komponenten und Emotion-Styling.“
Mehr technische Einblicke gibt es in den Design-Updates für das Veröffentlichungs-Popover (DateTimePicker).
Zeit zum Lesen im Info-Panel
Das Informationsfeld in der oberen Symbolleiste wurde verbessert und zeigt jetzt zusätzlich zu Wörtern, Zeichen, Überschriften, Absätzen und Blöcken auch die Lesezeit an.
Die geschätzte Lesezeit wird auf der Grundlage von durchschnittlich 189 Wörtern pro Minute berechnet. Lies mehr in @wordpress/editor: Füge die geschätzte Lesezeit zum Inhaltsverzeichnis im Editor hinzu.
Blockabstandskontrolle zur Formatvorlagen-Benutzeroberfläche hinzugefügt
Ab sofort können Nutzer/innen den vertikalen und horizontalen Abstand von Blöcken, die diese Funktion unterstützen, in der Formatvorlagen-Benutzeroberfläche anpassen.
Neue und verbesserte Bauwerkzeuge
WordPress 6.1 wird auch die Funktionalität des Site Builders erweitern. Blockmuster werden an mehr Stellen verfügbar sein und eine größere Auswahl an Vorlagentypen wird die Bearbeitung im Vorlageneditor verbessern.
Erstellungsmuster für Beitragstypen
Mit WordPress 6.0 wurden Seitenerstellungsmuster eingeführt, mit denen jedes Mal, wenn ein Nutzer eine neue Seite erstellt, eine Auswahl an Mustern bereitgestellt wird. Auf diese Weise musst du die Seite nicht mehr von Grund auf neu erstellen, sondern kannst ein Muster aus einem Modal auswählen, den Inhalt eingeben und schon bist du startklar.
Um diese Funktion zu aktivieren, sollte mindestens ein Blockmuster die Unterstützung für die core/post-content Blocktypen deklarieren.
Ab WordPress 6.1 wird diese Funktion auf alle Beitragstypen ausgeweitet. Alles, was du tun musst, ist, core/post-content in dein Muster blockTypes einzubinden und die entsprechende postTypes zu setzen.
Jetzt wollen wir anhand eines praktischen Beispiels herausfinden, wie du die Vorteile dieser neuen Funktion nutzen kannst. Angenommen, du hast einen Beitragstyp Film.
Zuerst musst du ein Blockmuster registrieren, wie hier beschrieben.
Du kannst auch den einfachen Weg gehen und die implizite Musterregistrierung verwenden (der Einfachheit halber werden wir in diesem Beispiel die implizite Musterregistrierung verwenden).
Erstelle eine PHP-Datei für dein Blockmuster im Verzeichnis /patterns im Ordner deines Themes (für dieses Beispiel haben wir Twenty Twenty-Two verwendet). Füge dann die folgende Überschrift hinzu:
<?php
/**
* Title: Pattern with columns
* Slug: twentytwentytwo/pattern-with-columns
* Block Types: core/post-content
* Post Types: movie
* Categories: text
*/
?>
<!-- wp:heading -->
<h2>Hello there!</h2>
<!-- /wp:heading -->Und das war’s. Jetzt erscheint jedes Mal, wenn du einen neuen Movie Post Type erstellst, ein Muster auswählen-Modal auf dem Bildschirm.
Wenn du möchtest, dass das Modal bei mehreren Beitragstypen angezeigt wird, füge einfach die entsprechenden Slugs durch Kommas getrennt hinzu:
<?php
/**
* Title: Pattern with columns
* Slug: twentytwentytwo/pattern-with-columns
* Block Types: core/post-content
* Post Types: movie, book
* Categories: text
*/
?>
<!-- wp:heading -->
<h2>Hello there!</h2>
<!-- /wp:heading -->Weitere Informationen zu Erstellungsmustern findest du unter Möglichkeit, Erstellungsmuster für andere Beitragstypen als Seite zu verwenden.
Mehr Vorlagentypen im Seiteneditor
Mit WordPress 6.0 kann nur eine begrenzte Anzahl von Vorlagen im Seiteneditor erstellt werden:
Ab WordPress 6.1 wird es möglich sein, für jeden einzelnen Beitragstyp eine eigene Vorlage zu erstellen.
Außerdem kannst du Vorlagen für Core- und Custom-Taxonomien hinzufügen und bearbeiten, sogar für einzelne Kategorien oder Tags.
Wenn du benutzerdefinierte Beitragstypen oder eine benutzerdefinierte Taxonomie registrierst, werden sie automatisch in der Vorlagenauswahlbox des Site Editors aufgeführt.
Aber nicht nur das. Nach der Auswahl des Vorlage-Post-Typs wird der Nutzer in einem Modal gefragt, ob er eine Vorlage für alle Posts dieses Typs oder eine neue Vorlage für einen bestimmten Post des ausgewählten Post-Typs erstellen möchte.
Dann erscheint ein neues Modal mit einer Liste der Beiträge, die für diesen Beitragstyp verfügbar sind.
Twenty Twenty-Three und andere Theme-Verbesserungen
WordPress 6.1 liefert auch ein brandneues Standard-Theme: Twenty Twenty-Three. Es ist ein minimalistisches Theme ohne Bilder oder zusätzliche Funktionen.
Das neue Standard-Theme versammelt alle aktuellen Funktionen zur Website-Bearbeitung an einem Ort und ist ein perfekter Sandkasten zum Testen von Vorlagen und Vorlagenteilen, Stilvariationen, flexibler Typografie und Abständen sowie allen Funktionen, die mit den neuesten Versionen von WordPress eingeführt wurden.
Und deshalb ist es auch ein großartiges Werkzeug, um die Entwicklung von Themes, Vorlagen und Blockmustern anhand von Arbeitsbeispielen zu lernen.
In unserer ausführlichen Übersicht kannst du tiefer in das neue WordPress Standard-Theme eintauchen.
Neben dem neuen Standard-Theme führt WordPress 6.1 auch einige Theme-Verbesserungen ein.
URI-Kopfzeile in Themes aktualisieren
Wenn vor WordPress 6.1 ein Theme denselben Namen hatte wie ein Theme, das im WordPress-Themes-Verzeichnis verfügbar war, wurde dem Benutzer eine Meldung über die verfügbare Aktualisierung angezeigt.
Mit WordPress 6.1 verhindert ein neuer Update URI Header das versehentliche Überschreiben von Theme-Dateien von Drittanbietern. Diese Funktion ist besonders nützlich, wenn du ein selbst entwickeltes Theme mit demselben Namen wie ein Theme im WordPress-Theme-Verzeichnis hast, es aber nicht mit der Community teilen möchtest.
Wenn der Wert des Theme-Headers Update URI nicht mit https://wordpress.org/themes/{$slug}/ oder w.org/theme/{$slug} übereinstimmt, wird WordPress nicht versuchen, das Theme zu aktualisieren.
Wenn Update URI gesetzt ist, sollte es sich um eine URI mit einem eindeutigen Hostnamen handeln, z. B. https://wordpress.org/themes/my-theme/ oder https://example.com/my-theme/.
Theme-Entwickler finden eine ausführlichere Übersicht über den neuen Update URI Theme-Header in der offiziellen Dev Note.
Filter für blockierte Themen unter „Themen hinzufügen“
Ein neuer Shortcut ermöglicht es jetzt, beim Hinzufügen eines neuen Themes zu deiner WordPress-Installation nach blockierten Themes zu filtern.
Außerdem wurde im gleichen Bildschirm ein neuer Hilfe-Tab für Block-Themes hinzugefügt.
Änderungen für Entwickler
WordPress 6.1 bringt auch eine neue API und viele Funktionen und Änderungen für Entwickler/innen.
Neue API für die Persistenz von Präferenzen
WordPress 6.1 führt eine brandneue API für die Persistenz von Präferenzen ein, die die Einstellungen des Redakteurs in der WordPress-Datenbank speichert, anstatt sie lokal zu speichern.
Auf diese Weise können die Benutzereinstellungen in allen Browsern und auf allen Geräten gespeichert werden.
Zu diesem Zweck wurde das bisherige Persistenzsystem im Paket @wordpress/data veraltet und ein neues Paket preferences-persistence eingeführt. Das neue Paket speichert Daten über die Rest-API in der Benutzer-Meta. Die Daten werden auch im lokalen Speicher als Fallback gespeichert, falls der Nutzer offline geht oder eine Anfrage unterbrochen wird (siehe auch Pull #39795).
Unterstützung für Button Styles in theme.json
Mit WordPress 6.1 könnt ihr euren Themes mithilfe von theme.json Button-Stile hinzufügen. Dies ermöglicht es Theme-Entwicklern, Buttons in verschiedenen Blöcken einheitlich zu gestalten. Ein Beispiel ist der Suchblock, aber auch Blöcke von Drittanbietern werden von dieser Änderung profitieren.
Um dies zu ermöglichen, wird eine neue wp-element-button Klasse zu den Button-Elementen hinzugefügt, damit sie denselben Stil haben.
Du kannst diese Änderung testen, indem du den folgenden Code in deiner theme.json in einer Entwicklungsumgebung hinzufügst:
{
"styles": {
"elements": {
"button": {
"color": {
"background": "blue"
}
}
}
}
}Suchblock-Variationen unterstützen jetzt Query Vars
WordPress 6.1 unterstützt Suchblockvariationen, die auf Query Vars basieren. Das bedeutet, dass du deinen Nutzern Suchfelder zur Verfügung stellen kannst, mit denen sie nach jeder Art von Inhalt suchen können.
Im folgenden Beispiel registrieren wir eine Blockvariation für einen movies Beitragstyp. Das Beispiel basiert auf dem Tutorial von Carolina Nymar über Blockvariationen.
Füge in der Funktionsdatei deines (Child-)Themes den folgenden Code ein:
function movies_editor_assets() {
wp_enqueue_script(
'movies-block-variations',
get_template_directory_uri() . '/assets/block-variations.js',
array( 'wp-blocks' )
);
}
add_action( 'enqueue_block_editor_assets', 'movies_editor_assets' );Erstelle die folgende Datei block-variations.js im Ordner assets deines (Child-)Themes:
wp.blocks.registerBlockVariation(
'core/search',
{
name: 'movie-search',
title: 'Movie Search Block',
attributes: {
query: {
post_type: 'movies'
}
}
}
);Lade nun dein WordPress-Dashboard neu und suche im Block-Inserter nach einer Movie Search Block Variation.
Du kannst mehr über Blockvariationen in der offiziellen Dokumentation lesen.
Ein neues Buttons-Element in den Globalen Stilen
Mit WordPress 5.9 wurde eine Schnittstelle für globale Stile eingeführt, mit der Nutzer/innen Stilvorgaben für ihre Websites anpassen können, entweder global oder auf Blockebene.
Bei der ersten Implementierung konntest du die Farben für Hintergrund, Text und Links anpassen. Mit WordPress 6.1 wurde das Farben-Panel um ein neues Element Buttons erweitert, mit dem du das Aussehen von Buttons auf deiner gesamten Website steuern kannst.
Dies wirkt sich auf den Stil der Schaltflächen auf der gesamten Website aus, vom Schaltflächenblock über den Suchblock bis hin zu Blöcken von Drittanbietern, die Schaltflächen verwenden.
Appearance Tools für jedes Theme verfügbar
Vor WordPress 6.1 waren Appearance Tools nur in Block-Themes verfügbar. Mit 6.1 kann jedes Theme diese Funktion einbinden, indem es die Unterstützung einfach in seine Funktionsdatei einfügt:
add_theme_support( 'appearance-tools' );Dadurch werden alle folgenden Einstellungen auf einmal aktiviert:
- rand: Farbe, Radius, Stil, Breite
- farbe: link
- abstand: blockGap, margin, padding
- typography: lineHeight
Neue is_login_screen() Funktion
Mit der neuen Funktion is_login_screen() kannst du jetzt feststellen, ob die aktuelle Seite der Anmeldebildschirm ist. Es werden auch benutzerdefinierte Login-Seiten unterstützt.
Du kannst den neuen bedingten Tag wie folgt verwenden:
function add_text_to_login() {
if ( is_login_screen() ) {
echo( "<h1>Welcome to Kinsta!</h1>" );
}
}
add_action( 'init', 'add_text_to_login' );Das Ergebnis auf dem Bildschirm würde wie folgt aussehen:
Neue Site Health Checks für Persistent Object Cache und Full Page Cache
WordPress 6.1 führt zwei Site Health Checks für Persistent Object Cache und Page Cache ein. Beide Prüfungen laufen nur in Produktionsumgebungen.
Du kannst die Ergebnisse dieser neuen Tests auf der Registerkarte „Status“ im Bildschirm „Site Health“ sehen.
Der Test für den persistenten Objekt-Cache stellt fest, ob die Website einen persistenten Objekt-Cache verwendet, und wenn nicht, empfiehlt er dessen Verwendung, wenn dies für die Website sinnvoll ist.
Zusätzlich zu dem neuen Test führt WordPress 6.1 mehrere neue Filter ein, die Hosting-Provider in ihren jeweiligen Umgebungen nutzen können.
Mit site_status_persistent_object_cache_url können Hosts den Standard-Link „Learn more“ für Persistent Object Cache durch einen benutzerdefinierten Link ersetzen. Zum Beispiel:
add_filter( 'site_status_persistent_object_cache_url', function() {
return 'https://example.com/persistent-object-cache';
} );Mit site_status_persistent_object_cache_notes können Gastgeber die Standardhinweise ersetzen, um ihre bevorzugte Objekt-Caching-Lösung zu empfehlen. Hier ist ein Beispiel für die Verwendung:
add_filter( 'site_status_persistent_object_cache_notes', function( $notes ) {
$notes = __( 'Custom notes.', 'text-domain' );
return $notes;
} );site_status_persistent_object_cache_thresholds filtert die Schwellenwerte, die verwendet werden, um zu bestimmen, ob die Verwendung eines persistenten Objekt-Caches vorgeschlagen wird. Die Standardwerte sind:
$thresholds = apply_filters(
'site_status_persistent_object_cache_thresholds',
array(
'alloptions_count' => 500,
'alloptions_bytes' => 100000,
'comments_count' => 1000,
'options_count' => 1000,
'posts_count' => 1000,
'terms_count' => 1000,
'users_count' => 1000,
)
);Du kannst den Filter wie folgt verwenden:
add_filter( 'site_status_persistent_object_cache_thresholds', function( $thresholds ) {
$thresholds = array(
'alloptions_count' => 700,
'alloptions_bytes' => 150000,
'comments_count' => 1500,
'options_count' => 1500,
'posts_count' => 2000,
'terms_count' => 1000,
'users_count' => 2000,
);
return $thresholds;
} );site_status_should_suggest_persistent_object_cache ist ein Kurzschlussfilter, der filtert, ob die Verwendung eines persistenten Objekt-Caches vorgeschlagen und die Standard-Schwellenwertprüfungen umgangen werden sollen. Du kannst ihn wie folgt verwenden:
add_filter( 'site_status_should_suggest_persistent_object_cache', '__return_true' );Der Full Page Cache Test prüft, ob die Website einen Full Page Cache verwendet und ob die Antwortzeit in Ordnung ist:
Mit zwei neuen Filtern können Hosts außerdem die Antwortschwelle anpassen und benutzerdefinierte Cache-Header hinzufügen, die erkannt werden sollen.
Der site_status_good_response_time_threshold filtert den Schwellenwert, unterhalb dessen eine Antwortzeit als gut angesehen wird. Der Standardwert ist 600 ms (siehe auch Langsame Server-Antwortzeiten beeinträchtigen die Leistung).
site_status_page_cache_supported_cache_headers ermöglicht es Hosting-Providern, benutzerdefinierte Cache-Header und die entsprechenden Überprüfungs-Callbacks hinzuzufügen. In der Dev Note findest du das folgende Beispiel für die Verwendung:
add_filter( 'site_status_page_cache_supported_cache_headers', function( $cache_headers ) {
// Add new header to the existing list.
$cache_headers['cf-cache-status'] = static function ( $header_value ) {
return false !== strpos( strtolower( $header_value ), 'hit' );
};
return $cache_headers;
});Entwickler können in die neuen Site Health Checks tiefer eintauchen:
- Vorschlag: Persistent Object Cache und Full Page Cache Site Health Checks
- Neue Cache Site Health Checks in WordPress 6.1
- Portierung von Audit Full Page Cache vom Performance Plugin zum Core
- class-wp-site-health.php
Create-block Scaffolding Tool Updates
WordPress 6.1 führt auch neue Funktionen und Aktualisierungen für das @wordpress/create-block-Paket ein, das Entwicklern zur Verfügung steht, um neue Blöcke zu erstellen.
Ein Blockgerüst ist die unterstützende Verzeichnisstruktur, die es WordPress ermöglicht, einen Block zu erkennen.
Mit WordPress 6.1 werden einige neue Funktionen und einige Verbesserungen eingeführt.
Ein neues –variant Flag ermöglicht es Blockentwicklern, eine Blockvariante zu wählen, die eingerüstet werden soll. Die internen Vorlagen, die das create-block-Tool bereitstellt, unterstützen die Varianten dynamic und static, d.h. du kannst einen dynamischen bzw. statischen Block einrüsten. Die Voreinstellung ist static.
Du kannst das neue Flag wie folgt verwenden:
npx @wordpress/create-block my-first-block -variant=dynamicEntwickler können benutzerdefinierte Varianten definieren, indem sie ein variants Objekt zur Vorlagendefinition hinzufügen.
Eine zusätzliche Funktion ermöglicht es Entwicklern von Blöcken jetzt, neue Blöcke zu einem bestehenden Plugin hinzuzufügen, dank des --no-plugin Flags.
npx @wordpress/create-block custom-block --no-pluginWenn du den obigen Befehl ausführst, wird ein neuer Satz von Blockdateien in einem Unterverzeichnis des aktuellen Verzeichnisses erstellt. Beachte, dass das Skript nicht weiß, wo es sich befindet:
Wenn du
npx @wordpress/create-block block-name --no-pluginaufrufst, wird ein neuer Block in dem VerzeichnisfolderNamedirectoryerstellt, in dem er aufgerufen wird
Du kannst mehr über create-block scaffolding tool updates lesen.
Caching von Abfrageergebnissen in WP_Query
WordPress 6.1 ändert die Art und Weise, wie Datenbankabfragen in der Klasse WP_Query ausgeführt werden. Ab 6.1 werden Abfragen zwischengespeichert, was zur Folge hat, dass bei mehrmaliger Ausführung einer Abfrage die Ergebnisse aus dem Cache geladen werden.
Sowohl Websites, die das Caching von persistenten Objekten verwenden, als auch Websites, die das In-Memory-Caching nutzen, profitieren von dieser Änderung, auch wenn die Vorteile für letztere geringer sind.
Standardmäßig werden alle Aufrufe von WP_Query gecacht, aber Entwickler können das Caching von Abfragen mit dem Parameter cache_results deaktivieren:
$args = array(
'posts_per_page' => 20,
'cache_results' => false
);
$query = new WP_Query( $args );Du kannst die Zwischenspeicherung von Abfragen auch global mit dem disable_caching Hook deaktivieren, obwohl dies nicht empfohlen wird.
Es sei darauf hingewiesen, dass einige Abfrageparameter für das Caching von Abfragen nicht berücksichtigt werden. Der am häufigsten verwendete dieser Parameter ist der Parameter fields. Der Grund dafür ist, dass die Berücksichtigung von fields zu mehreren Zwischenspeichern für mehrere Teilmengen derselben Daten und damit zu einer Leistungsverschlechterung geführt hätte.
Einen genaueren Überblick über das WP_Query Caching findest du in der WP_Query Performance Improvements in 6.1 dev note.
Template-Teile in klassischen Themes
Ab WordPress 6.1 unterstützen klassische Themes blockbasierte Vorlagenteile. Um diese Funktion hinzuzufügen, müssen Themes die Unterstützung für block-template-parts hinzufügen, wie unten gezeigt:
function add_block_template_part_support() {
add_theme_support( 'block-template-parts' );
}
add_action( 'after_setup_theme', 'add_block_template_part_support' );Klassische Themes können mit der Funktion block_template_part Vorlagenteile in PHP-Vorlagen einfügen. Mehr über diese Funktion erfährst du in der Dev-Note zu blockbasierten „Template Parts“ in klassischen Themes.
Ein Hinweis zur JPEG-zu-WebP-Bildkonvertierung
Ursprünglich sah es so aus, als ob WordPress 6.1 auch die automatische Umwandlung von JPEG- in WebP-Bilder unterstützen würde.
Allerdings meldeten viele Mitwirkende mehrere Probleme. Insbesondere wurde folgendes festgestellt:
Die Ressourcen für die Bilderzeugung beim Hochladen eines Bildes steigen drastisch an, aber die Ressourcen für die Bereitstellung eines Bildes werden gesenkt. Da das Hochladen von Bildern im Vergleich zur Bereitstellung von Bildern sehr selten ist, sollte sich der zusätzliche Aufwand für das Komprimieren und Speichern von Bildern lohnen.
Und:
Der dramatische Anstieg des Ressourcenverbrauchs beim Hochladen eines Bildes ist ein sehr schlechter Nebeneffekt. Das bedeutet, dass viele Uploads fehlschlagen und die Nutzer/innen im Stich lassen werden. Außerdem werden dadurch die Supportanfragen sowohl bei WordPress als auch bei den Hosting-Unternehmen drastisch ansteigen. Das ist nicht akzeptabel. Selbst wenn die Unterstützung von Multimime-Bildern in WordPress notwendig ist, scheint der aktuelle Ansatz keine gute Lösung zu sein.
Schließlich wurde nach einem Beitrag von Matt Mullenweg auf WordPress.org die automatische Umwandlung von JPEG in WEBP aus WordPress 6.1 entfernt.
Ich bin daran interessiert, neue Formate zu unterstützen und die Leistung zu verbessern, aber ich denke, dass diese Änderung, die den Nutzern beim Upgrade auf 6.1 standardmäßig auferlegt wird, zum jetzigen Zeitpunkt zu viel ist, auch im Hinblick auf einige der klobigen Interaktionen, die Betriebssysteme immer noch mit webp (und HEIC!) Dateien haben. Ich bin froh, dass die Unterstützung für Webp- und HEIC-Dateien im Kernprogramm verbleibt, denn wir sollten liberal sein, was wir akzeptieren und womit wir arbeiten, aber nicht mit der Änderung, alles in Webp zu konvertieren, wenn JPEGs hochgeladen werden. Das ist ein hervorragendes Terrain für ein kanonisches Plugin, ein Konzept, das meiner Meinung nach jedes Make-Team viel mehr erforschen sollte, um zu experimentieren und die Funktionalität zu verbessern…
WordPress-Nutzer und -Entwickler können die automatische Umwandlung von JPEG– in WebP-Bilder testen, indem sie das Performance Lab Plugin der WordPress Performance Group installieren.
Zusätzliche Änderungen für Entwickler
Zusätzlich zu den Funktionen und Verbesserungen, die wir oben besprochen haben, führt WordPress 6.1 einige weitere Änderungen für Entwickler ein. Du solltest dir diese Änderungen in den Entwicklerhinweisen genauer ansehen:
- Verbesserte PHP-Leistung für die Registrierung von Core-Blöcken
- Fallback-Verhalten von Navigationsblöcken in WP 6.1
- Voreinstellungen für Abstandsgrößen in theme.json
- Escaping von Tabellen- und Feldnamen mit wpdb::prepare() in WordPress 6.1
- WP_List_Table::get_views_links() in WordPress 6.1
- Funktionen und Hooks für erforderliche Felder in WordPress 6.1
- Verschiebung der send_headers-Aktion auf einen späteren Zeitpunkt während des Ladevorgangs
- Leistungsverbesserungen an der REST-API
- Aktualisierungen der Editor-Komponenten in WordPress 6.1
- Multisite-Verbesserungen in WordPress 6.1
- Verschiedene Core-Änderungen für WordPress 6.1
- Leitfaden zur Leistungssteigerung für WordPress 6.1
- Verschiedene REST-API-Verbesserungen in WordPress 6.1
- Änderungen an der Block-API in WordPress 6.1
- Verschiedene Änderungen am Editor für WordPress 6.1
- Aktualisierte Editor-Layout-Unterstützung in 6.1 nach dem Refactor
- Änderungen an den Blockeditor-Einstellungen in WordPress 6.1
- Erzeugung von Blockstilen (Style Engine)
- Referenzwerte für Styles in theme.json
Zusammenfassung
Mit WordPress 6.1 werden die Möglichkeiten zur Bearbeitung von WordPress-Websites konsolidiert. Wir befinden uns noch in Phase zwei der langfristigen Gutenberg-Roadmap, aber die Tools und Funktionen, die uns zur Verfügung stehen, werden mit der Zeit immer zuverlässiger und robuster. WordPress 6.1 bringt Fluid Typography, neue Tools für die Website-Bearbeitung und jede Menge Verbesserungen für bestehende Blöcke.
Aber das ist noch nicht alles. WordPress 6.1 bringt auch erhebliche Verbesserungen bei der Leistung des CMS mit sich. Zwei neue Site Health Checks erkennen die Verwendung von Full Page Cache und Persistent Object Cache, das Query Caching verbessert die Leistung von WP_Query und es gibt auch Verbesserungen der PHP-Leistung bei der Registrierung von Core-Blöcken.
Kurz gesagt, 6.1 ist eine Version, die WordPress-Nutzer/innen und -Designer/innen lieben werden, ebenso wie Entwickler/innen, die von vielen Verbesserungen in verschiedenen Bereichen des CMS profitieren werden.
Jetzt liegt es an dir. Was gefällt dir am meisten an WordPress 6.1? Hast du die neue Version bereits in deiner Entwicklungsumgebung getestet? Teile uns deine Meinung zu WordPress 6.1 in den Kommentaren unten mit.
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.
Schreibe einen Kommentar