WordPress 5.6 „Simone“ ist da und wir freuen uns darauf, mit dir in die interessantesten Features und Ergänzungen einzutauchen, die mit dem neuesten WordPress Release 2020 in den Core integriert wurden.
Wie frühere Versionen enthält auch WordPress 5.6 mehrere Versionen des Block-Editors, die das Bearbeitungserlebnis für WordPress-Benutzer verbessern, die das Gutenberg-Plugin noch nicht installiert und auf ihren Webseiten aktualisiert haben.
Aber nicht alles dreht sich um den Blockeditor. Dem WordPress-Core wurden mehrere Funktionen hinzugefügt, wie z.B. ein neues Standard Theme Twenty Twenty One, Auto-Updates für Hauptversionen, bessere Unterstützung für PHP 8.0, Anwendungskennwörter für die REST-API-Authentifizierung.
Und es gibt noch viel mehr in WordPress 5.6. Wir werden Verbesserungen der Zugänglichkeit, Verbesserungen der Benutzeroberfläche, Tonnen von Fehlerbehebungen und eine riesige Liste von Änderungen für Entwickler sehen.
Wenn du mehr über den Entwicklungszyklus von WordPress 5.6 lesen möchtest, klicke auf die untenstehenden Links:
- 20. Oktober 2020: Beta 1
- 27. Oktober 2020: Beta 2
- 2. November 2020: Beta 3
- 12. November 2020: Beta 4
- 17. November 2020: RK 1
- 1. Dezember 2020: RK 2
- 7. Dezember 2020: Probelauf für die Veröffentlichung von WordPress 5.6
- 8. Dezember 2020: Release von WordPress 5.6 „Simone“
Bereit zu starten? Lasst uns loslegen:
Was ist neu beim Blockeditor?
Mit WordPress 5.6 wurden mehrere Versionen des Gutenberg-Plugins im Core zusammengeführt, so dass WordPress-Benutzer und-Autoren einige Verbesserungen im Editor bemerken sollten. Wir werden verbesserte Blockmuster, Wortzählungen in der Infotafel, eine verbesserte Tastaturnavigation, eine verbesserte Drag & Drop-Oberfläche und vieles mehr sehen.
Eine umfassendere Liste aller Verbesserungen und Änderungen, die dem Blockeditor hinzugefügt wurden, findest du in den Ankündigungsbeiträgen zur Veröffentlichung: 8.6, 8.7, 8.8, 8.9, 9.0, 9.1 und 9.2. Fehlerbehebungen und Leistungsverbesserungen, die in Gutenberg 9.3 und 9.4 implementiert wurden, sind auch in WordPress 5.6 enthalten.
Lasst uns in die interessanteren Änderungen eintauchen, die wir im Blockeditor sehen werden.
- Blöcke, Muster und UI-Verbesserungen
- Block API V2
- Zusätzliche Funktionen und Verbesserungen für Blockentwickler
Blöcke, Muster und UI-Verbesserungen
Neue Blockfunktionen, Verbesserungen und Fehlerbehebungen werden das gesamte Bearbeitungserlebnis verbessern. Auch an der Zugänglichkeit wurde große Arbeit geleistet. Nachfolgend findest du unsere handverlesene Auswahl der interessantesten Funktionen, die du im Blockeditor sehen wirst, wenn du deine Webseite auf WordPress 5.6 aktualisierst.
Positionssteuerungen für Videos im Cover-Block
Die seit Gutenberg 8.6 zu den Cover-Blöcken hinzugefügten Positionssteuerungen für Videos ermöglichen es den Benutzern, den Fokuspunkt zu verschieben und eine benutzerdefinierte Position für Videos festzulegen. Diese Funktionalität war zuvor nur für Bildhintergründe verfügbar.
Die Positionswerte werden durch Klicken auf eine beliebige Stelle des Brennpunkt-Pickers und/oder mit den Pfeiltasten der Tastatur eingestellt. Du kannst Werte um 10 springen, indem du die Umschalttaste gedrückt hältst (siehe auch #22531).
Blockmuster-Aktualisierungen
WordPress 5.6 enthält auch einige Blockmuster-Verbesserungen, die mit Gutenberg 8.6 hinzugefügt wurden.
Das Layout, der Text und die Farbe der großen Kopfzeile und des Absatzes wurden aktualisiert (#23858)
Die Überschrift in Zwei Textspalten wurde aus dem Textblock herausgenommen und über den Spalten platziert (#23853)
Das Zitatmuster enthält jetzt oben ein Bild und unten ein Trennzeichen.
Ein neues Überschriften- und Absatzmuster wurde mit Gutenberg 8.7 (#24143) hinzugefügt.
Eine gute Verbesserung der Benutzerfreundlichkeit für den Block-Inserter ist die Dropdown-Liste „Blockmuster-Kategorie, mit der du Muster nach Kategorien filtern kannst. Dies ist äußerst nützlich, wenn du tonnenweise Muster zur Auswahl hast (#24954).
Unterstützung von Video-Untertiteln
Videoblöcke unterstützen jetzt Video-Untertitel.
Redakteure und Content-Ersteller sollten Video-Untertitel im WebVTT-Format (Web Video Text Tracks Format) zur Verfügung stellen, das „ein Format zur Anzeige von zeitgesteuerten Textspuren (wie Untertitel oder Bildunterschriften) unter Verwendung des Elements <track>“ ist (#25861).
Sobald du deine .vtt-Dateien geladen hast, können Webseiten-Betrachter Untertitel in ihrer bevorzugten Sprache aktivieren.
Mehrere Blöcke in einen Spaltenblock umwandeln
Eine interessante Verbesserung der Benutzerfreundlichkeit ist die Möglichkeit, mehrere ausgewählte Blöcke in einen Spaltenblock zu konvertieren.
Du musst nur die Blöcke auswählen, die du in Spalten anzeigen möchtest, und dann auf die Schaltfläche oben rechts in der Blocksymbolleiste klicken.
Jeder ausgewählte Block wird in eine Spalte eines Spaltenblocks konvertiert.
Hintergrundmuster im Umschlagblock
Deckblöcke können jetzt Hintergrundmuster anzeigen.
Um ein Hintergrundmuster hinzuzufügen, lade ein Musterbild hoch und schalte dann die Option Wiederholter Hintergrund ein (hier findest du alles, was du über die Medienbibliothek in WordPress wissen musst).
Wenn du damit fertig bist, stelle den Fokuspunkt-Picker nach deinen Bedürfnissen ein und probiere verschiedene Kombinationen mit festen Hintergründen aus.
Bildgrößenkontrolle zum Medien- und Textblock hinzugefügt
Mit Gutenberg 9.1 wurde eine neue Bildgrößenkontrolle für Bilder in Media & Text Block hinzugefügt.
Benutzer können nun aus allen verfügbaren Bildgrößen wählen (#24795).
Block API V2
Eine neue Block-API-Version ermöglicht es Blöcken, ihr Wrapper-Element zu rendern. Das Ziel der neuen API-Version ist es, das DOM des Editors zu erleichtern und es an den Inhalt der Titelseite anzupassen. Laut Ella van Durpe:
Der größte Vorteil davon ist, dass Themes und Plugins den Blockinhalt leichter stylen können, wenn das Markup im Editor gleich ist.
Die neue Version erfordert die Deklaration der apiVersion-Eigenschaft bei der Blocktyp-Registrierung:
registerBlockType( name, { apiVersion: 2 } );Die neue API erfordert auch den useBlockProps–Hook in der Blockbearbeitungsfunktion. Dieser Hook markiert das Wrapper-Element eines Blocks als Blockelement.
Jede an diesen Hook übergebene Eigenschaft wird zusammengeführt und an das Wrapper-Element zurückgegeben. Das folgende Beispiel aus den dev-Notes zeigt einen einfachen Anwendungsfall:
import { useBlockProps } from '@wordpress/block-editor';
function Edit( { attributes } ) {
const blockProps = useBlockProps( {
className: someClassName,
style: { color: 'blue' },
} );
return <p { ...blockProps }>{ attributes.content }</p>;
}Weitere Beispiele findest du unter Block API Version 2.
Zusätzliche Funktionen und Verbesserungen für Blockentwickler
Neben der Block API Version 2 findest du hier eine Liste von Ergänzungen, die Entwickler durcharbeiten müssen.
Block unterstützt API
Block Supports API ermöglicht Blockentwicklern, ihren Blöcken Funktionen hinzuzufügen. Farben, Hintergründe, Schriftgrößen sind nur einige der vielen Features, die über die Block Supports API zu Blöcken hinzugefügt werden können.
WordPress 5.6 führt auch mehrere neue Block-Unterstützungen ein, „um die Konsistenz zu erhöhen und die Einführung dieser Optionen in Blöcke zu erleichtern“.
Entwickler können die neuen Block-Unterstützungen verwenden, indem sie die entsprechenden Schlüssel in die Support-Eigenschaft der Datei block.json oder direkt in die Funktion registerBlockType einfügen.
Das folgende Beispiel aus Block Supports devnote zeigt, wie es funktioniert:
supports: {
color: {
background: true, // Enable background color UI control.
gradient: true, // Enable gradient color UI control.
text: true // Enable text color UI control.
},
fontSize: true, // Enable font size UI control.
lineHeight: true // Enable line height UI control.
}Der Stilwert wird automatisch an das Wrapper-Element angehängt, entweder über die has-<value>-<preset-category> ( für voreingestellte Werte) oder mit einem style Element(für benutzerdefinierte Werte).
Aus diesem Grund sind die Block-Unterstützungen für die Verwendung mit der neuen Block-API V2 vorgesehen.
Block Supports können auch mit dynamischenBlöcken verwendet werden.
createBlocksFromInnerBlocksTemplate-API
Entwickler können die InnerBlocks-Komponente verwenden, um benutzerdefinierte Blöcke zu erstellen, die andere Blöcke enthalten. Beispiele hierfür sind der Block Columns und der Block Social Links.
Die neue createBlocksFromInnerBlocksTemplate Block API ermöglicht es dir, Blöcke aus der InnerBlocks-Vorlage zu erstellen.
Siehe devnotes für eine detailliertere Ansicht und ein Beispiel für Code.
Symbolleisten-Komponenten
Einige Änderungen betreffen auch die Komponentender Symbolleiste:
1. ToolbarGroup-Komponente
Vor WordPress 5.6 erlaubte die Toolbar-Komponente Entwicklern, verwandte Optionen in einem gemeinsamen Container zu gruppieren. Jetzt sollte stattdessen eine neue ToolbarGroup-Komponente verwendet werden.
<BlockControls>
<ToolbarGroup>
<ToolbarButton />
</ToolbarGroup>
</BlockControls>2. ToolbarButton- und ToolbarItem-Komponenten
Die direkte Verwendung tabellierbarer Elemente als Symbolleistenelemente (d.h. <button> ) ist veraltet. Um die Zugänglichkeit zu verbessern, können Symbolleistenelemente mit Toolbar Button für Schaltflächen und Toolbar Item für andere Steuerelemente hinzugefügt werden. Das folgende Beispiel zeigt eine Schaltfläche und ein Dropdown-Menü:
<BlockControls>
<ToolbarItem as="button" />
<ToolbarButton />
<ToolbarItem>
{ ( itemProps ) => ( <DropdownMenu toggleProps={ itemProps } /> ) }
</ToolbarItem>
</BlockControls>Deaktivieren von Kernblockmustern
Kernmuster können jetzt mit dem Flag zur Unterstützung core-block-patterns deaktiviert werden (#24042)
Deaktivieren des Inline-Bildeditors
Gutenberg 8.4 fügte eine Inline-Bildbearbeitungsfunktion hinzu, mit der Benutzer Bilder direkt aus dem Blockeditor heraus bearbeiten können.
Entwickler können den Bildeditor jetzt mithilfe des Filters block_editor_settings (#23966) deaktivieren:
add_filter( 'block_editor_settings', function( $settings ) {
$settings['imageEditing'] = false;
return $settings;
} );
Wiederverwendbare Blöcke in ein separates Paket verschoben
Wiederverwendbare Blöcke, die zuvor Teil des Pakets @wordpress/editor waren, wurden in das Paket @wordpress/reusable-blocks verschoben, um sie in anderen Editoren verfügbar zu machen.
Ein neues Standardtheme: Twenty Twenty-One
WordPress 5.6 enthält ein brandneues Standardtheme. Twenty Twenty One ist ein hochgradig zugängliches, minimalistisches WordPress-Theme mit einem einspaltigen Layout und einer Fußzeilen-Seitenleiste.
Das neue Theme verwendet einen Systemschriftstapel und eine minimale Farbpalette, die auf pastellfarbenen Hintergrundfarben basiert.
Du kannst viel mehr über Twenty Twenty-One in unserem ausführlichen Blogbeitrag lesen: Twenty Twenty-One: Ein tiefes Eintauchen in das neue WordPress-Standardtheme.
Auto-Updates für Hauptversionen
Automatische Aktualisierungen sind eine Kernfunktion, die mit WordPress 3.7 eingeführt wurde, um die Sicherheit der Seite zu verbessern und es den Seiten-Administratoren zu erleichtern, ihre WordPress-Webseiten auf dem neuesten Stand zu halten.
Während in früheren Versionen automatische kleinere Kern-Updates implementiert wurden, können Seiten-Administratoren mit WordPress 5.6 nun auch für Hauptversionen manuell automatische Updates aktivieren (mehr dazu in einer Sekunde).
Leider kann diese wichtige Wartungsaufgabe für technisch nicht versierte Benutzer immer noch etwas verwirrend sein. Du kannst in unserem Blogbeitrag Eine ausführliche Anleitung über WordPress Updates mehr darüber lesen, wie automatische Updates funktionieren.
Daher führt WordPress 5.6 eine neue Schnittstelle ein, die es Seiten-Administratoren ermöglicht, automatische Aktualisierungen für wichtige Kernversionen zu aktivieren.
Der Umfang dieser Funktion hat sich während des Betazyklus von WordPress 5.6 geändert, und der ursprünglicheEntwicklerhinweis wurde ersetzt. Mit den Worten von JbAudras,
Der anfängliche Umfang der automatischen Core-Updates hat sich verschoben:
- Stelle einige Aktualisierungen des Designs der Benutzeroberfläche zur Verfügung.
- Bei bestehenden Installationen wird das Verhalten dasselbe bleiben wie heute: Standardmäßig wird für kleinere Updates optiert, aber ein Benutzer muss sich für größere Updates entscheiden (Konstanten und Filter, die bereits von Hosts oder Agenturen verwendet werden, haben weiterhin Vorrang).
- Bei Neuinstallationen ändert sich das Standardverhalten: standardmäßig für kleinere Aktualisierungen und standardmäßig für größere Aktualisierungen freigeschaltet.
Ab WordPress 5.6 kannst du automatische Aktualisierungen für wichtige Kernversionen im Bildschirm Aktualisierungen aktivieren, wo eine neue Benutzeroberfläche ein Kontrollkästchen bietet, mit dem du automatische Aktualisierungen für alle neuen Versionen von WordPress aktivieren kannst.
Wenn du die automatischen Core-Aktualisierungen für Hauptversionen aktiviert hast, kannst du diese nur für Wartung und Sicherheit auslösen, indem du auf Switch to automatic updates for maintenance and security releases only klickst.
Wichtige automatische Core-Updates für Entwickler
Erstens, wenn die automatischen Hauptaktualisierungen des Cores aktiviert sind, wird die Option auto_update_core_major mit aktiviertem option_value in der Datenbank gespeichert. Wenn get_site_option( 'auto_update_core_major' ) also true zurückgibt, ist das Kontrollkästchen für automatische Aktualisierungen aktiviert.
Dann prüft WordPress, ob wichtige automatische Core-Updates durch die Konstante WP_AUTO_UPDATE_CORE oder den Filter allow_major_auto_core_updates aktiviert sind, und setzt das Kontrollkästchen entsprechend.
Entwickler können auch größere Core-Auto-Updates deaktivieren, indem sie die Konstante WP_AUTO_UPDATE_CORE wie unten gezeigt auf false oder minor setzen (siehe auch Steuerung von Hintergrund-Updates durch wp-config.php):
# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );
# Enables minor updates:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );Beachten Sie, dass mögliche Werte für WP_AUTO_UPDATE_CORE true (alle), 'beta', 'rc', 'minor', false sind.
Eine weitere Möglichkeit, wichtige automatische Core-Auto-Updates standardmäßig zu deaktivieren, ist die Verwendung des neuen allow_major_auto_core_updates-Filters:
add_filter( 'allow_major_auto_core_updates', '_return_false' );Einige Anmerkungen zum Hinzufügen von Auto-Updates zum Core
Im Dezember 2018 teilte Matt Mullenweg die neun Prioritäten für das Jahr 2019 mit, wobei „Providing a way for users to opt-in to automatic updates of major Core releases“ die Nummer 7 war. Vielleicht etwas spät, aber wir sind auf dem besten Weg dahin.
Größere automatische Core-Updates sollten einen großen Einfluss auf die Sicherheit von WordPress und die Gesamterfahrung haben. Eines scheint klar zu sein: Aus technischer Sicht ist die Funktion der großen automatischen Kern-Updates eine komplexe Aufgabe, die mit der Veröffentlichung von WordPress 5.6 nicht zu 100% erfüllt ist.
Nach einer nachdenklichen Diskussion über Slack fasste Josepha Haden die Bedenken und Fragen der Hauptmitarbeiter zusammen.
Langfristiges Hauptziel ist es, auf den meisten WordPress-Webseiten automatische Aktualisierungen zur Verfügung zu stellen, um die Sicherheit im gesamten WordPress-Ökosystem (mehr als 30 % des Internets) zu verbessern.
Jedenfalls, so Helen Hou-Sandí, Core Lead Developer:
Meiner Meinung nach gibt es einige sehr schwierige technische Dinge, die es auszuführen gilt, und dazu bedarf es eines SEHR disziplinierten und zielgerichteten technischen Produkteigentums.
Wir sollten also im Laufe der Zeit weitere Änderungen und Verbesserungen der wichtigsten automatischen Core-Update-UI sehen. Dies ist das, was wir von jetzt an erwarten dürfen:
WordPress 5.6:
- Bei bestehenden Installationen müssen größere Updates vom Benutzer aktiviert werden. Alle bereits benutzten Konstanten und Filter haben Vorrang. Kleinere Aktualisierungen sind standardmäßig aktiviert.
- Bei Neuinstallationen sind sowohl kleinere als auch größere Updates standardmäßig aktiviert.
WordPress 5.6.1:
- Aufgrund des Feedbacks sollten wir einige Änderungen an der Core-UI für automatische Aktualisierungen sehen.
WordPress 5.7:
- Für alle, die sich gegen größere Auto-Updates entschieden haben, sollte auf dem Bildschirm Site Health ein Tipp hinzugefügt werden.
- In WordPress 5.7 sollte dem Installationsprozess ein Opt-in für automatische Aktualisierungen hinzugefügt werden.
Eine große Sorge bei automatischen Core-Auto-Updates ist das Vertrauen der Benutzer. Laut Helen:
Ich glaube, dass wir noch viel Arbeit leisten können, um proaktiv um das Vertrauen der Benutzer zu werben, insbesondere derjenigen, die bereits schlechte Erfahrungen mit WordPress und/oder Updates gemacht haben.
Jede WordPress-Webseite ist jedoch eine Mischung aus Core, Plugins und Theme. Mit den Worten von Helen:
Core-Updates sind im Großen und Ganzen ziemlich sicher, und es sind einige Schutzvorrichtungen eingebaut, aber da Seiten jeden Code aus jeder Quelle ausführen können, gibt es so etwas wie „100%“ für „jede Art von WordPress-Webseite“ nicht.
Benutzer mit aktivierten automatischen Core-Auto-Updates sollten regelmäßig Backups ihrer Webseiten erstellen oder einen Web-Host wählen, der automatische Backups in ihren Plänen bereitstellt.
Core-Auto-Updates werden sich auch auf die gesamte Update-Erfahrung auswirken, einschließlich automatischer Plugin- und Theme-Updates. bemerkte Joost de Valk in einem Kommentar:
Wenn wir die automatischen WordPress-Core-Auto-Updates standardmäßig aktivieren, sollten wir dasselbe für Plugins tun. Andernfalls können Plugins und Themes nicht für Dinge aktualisiert werden, die sie aufgrund von Core-Updates korrigieren müssen. Ich denke, die Benutzer würden auch dies erwarten: Wenn WordPress-Auto-Updates automatisch durchgeführt werden, sollten auch Plugins und Themes automatisch aktualisiert werden.
Site Health Änderungen in WordPress 5.6
Neben all den hier besprochenen Funktionen bringt WordPress 5.6 auch eine verbesserte Version des Site Health-Tools mit, das sich nun im Hintergrund anders verhält.
Site Health Check Datenvalidierung
Ein Validator überprüft nun die Antworten auf die Fragen für Site Health-Tests. Der Validator verwirft jede ungültige Antwort, wodurch verhindert wird, dass das Site Health-Tool fatale Fehler verursacht, und alle weiteren Kontrollen gestoppt werden.
Von nun an haben ungültige Antworten keinen Einfluss mehr auf den Site Health Indikator (#50145).
Asynchrone Prüfungen über REST-Endpunkt
Das Site-Health-Tool ist ein leistungsstarkes Sicherheitstool, mit dem Webseiten-Eigentümer über den Gesundheitszustand ihrer Webseiten informiert werden können.
Dieses Tool führt eine Reihe von Sicherheitstests durch, die einen Überblick über den Gesundheitszustand Ihrer Webseite geben.
Diese Tests lassen sich in zwei Kategorien einteilen: direkte Tests, die beim Laden einer Seite ausgeführt werden, und asynchrone Tests, deren Ausführung einige Zeit in Anspruch nehmen kann und die später über JavaScript-Aufrufe ausgeführt werden.
Zuvor wurden diese Tests mit einem Aufruf von admin-ajax.php ausgeführt. Mit WordPress 5.6 bewegen sich die Dinge weg von admin-ajax.php, und stattdessen wird ein neuer REST-API-Endpunkt verwendet. Ab WordPress 5.6 können asynchrone Tests unter dem Namensraum /wp-json/wp-site-health/v1 gefunden werden.
Dank der neuen REST-API-Erweiterung können Plugins und Themes auch REST-Endpunkte nutzen und sind bei ihren Site Health Test nicht auf Ajax-Aktionen beschränkt.
Jeder asynchrone Test kann jetzt das has_rest-Argument deklarieren, das standardmäßig auf false gesetzt ist.
Der untenstehende Code aus wp-admin/includes/class-wp-site-health.php zeigt die Anordnung der asynchronen Tests in WordPress 5.6:
'async' => array(
'dotorg_communication' => array(
'label' => __( 'Communication with WordPress.org' ),
'test' => rest_url( 'wp-site-health/v1/tests/dotorg-communication' ),
'has_rest' => true,
'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_dotorg_communication' ),
),
'background_updates' => array(
'label' => __( 'Background updates' ),
'test' => rest_url( 'wp-site-health/v1/tests/background-updates' ),
'has_rest' => true,
'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_background_updates' ),
),
'loopback_requests' => array(
'label' => __( 'Loopback request' ),
'test' => rest_url( 'wp-site-health/v1/tests/loopback-requests' ),
'has_rest' => true,
'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_loopback_requests' ),
),
'authorization_header' => array(
'label' => __( 'Authorization header' ),
'test' => rest_url( 'wp-site-health/v1/tests/authorization-header' ),
'has_rest' => true,
'headers' => array( 'Authorization' => 'Basic ' . base64_encode( 'user:pwd' ) ),
'skip_cron' => true,
),
),Geplante Site Health Checks:
Während asynchrone Tests implementiert wurden, um langsame Seiten lasten und Timeouts zu verhindern, gibt es solche Bedenken bei geplanten Tests nicht.
Vor diesem Hintergrund können Test-Arrays zusätzlich zu dem oben erwähnten has_rest-Argument auch das async_direct_test-Argument deklarieren (unter Verwendung des obigen Codes), das eine aufrufbare Instanz eines Tests sein sollte.
Wenn ein Test während eines geplanten Ereignisses ausgeführt wird, verwendet der Test nicht den REST-API-Endpunkt, sondern wird direkt ausgeführt.
Anwendungskennwörter für REST API-Authentifizierung
Application Passwords ist ein neues System für authentifizierte Anfragen an verschiedene WordPress-APIs.
Passwörter sind 24 Zeichen lang und bestehen aus Groß- und Kleinbuchstaben sowie numerischen Zeichen, die entweder manuell oder über die REST-API generiert werden können.
Um manuell ein neues Bewerbungspasswort zu generieren, gehe zu deinem Profil-Bildschirm und scrolle die Seite nach unten.
Wähle einen Namen für dein Anwendungskennwort und bestätige es. WordPress wird dein neues Passwort anzeigen.
Anwendungskennwörter werden in 4-stelligen, durch Leerzeichen getrennten Abschnitten angezeigt, wie unten dargestellt:
gsUc UhkU 0ScI gdRd TGoU vrW5Passwörter können jedoch mit oder ohne Leerzeichen verwendet werden:
Die Anwendungskennwörter, die durch den Autorisierungsfluss zurückgegeben werden, enthalten keine Leerzeichen. Sie sind ausschließlich dazu da, es jemandem, der auf eine lange Zeichenfolge starrt, zu erleichtern, seinen Platz zu behalten, wenn er sie manuell eingibt.
Du kannst in Stücken, ohne Leerzeichen oder wenn du willst, könntest du wahrscheinlich nach jedem Zeichen ein Leerzeichen hinzufügen.
Auf dem Bildschirm Benutzerprofil kannst du Anwendungskennwörter anzeigen, erstellen und widerrufen. In den Spalten Zuletzt verwendet und Letzte IP kannst du leicht herausfinden, welche Passwörter nicht mehr verwendet werden und widerrufen werden sollten.
Zum Zeitpunkt der Erstellung dieses Dokuments können Anwendungskennwörter mit REST API-authentifizierten Anfragen und mit der XML-RPC-API verwendet werden. In Zukunft sollten jedoch Anwendungskennwörter mit zusätzlichen APIs verwendet werden. erklärt George Stephanis:
Das Authentifizierungsschema für Anwendungskennwörter kann auch auf zukünftige APIs für WordPress angewandt werden, sobald diese verfügbar sind. Wenn z.B. GraphQL oder andere Systeme in WordPress aktiviert sind, werden die Anwendungskennwörter ihnen eine solide, etablierte Authentifizierungsinfrastruktur bieten, die sie sofort nach dem Auspacken aufbauen können.
Die Verwendung von Anwendungskennwörtern auf wp-login.php ist nicht möglich.
Für einen genaueren Blick auf diese Funktion und weitere technische Einblicke solltest du dir die folgenden Ressourcen ansehen:
- Vorschlag: REST API-Authentifizierung / Anwendungskennwörter
- Anwendungs-Passwörter: Leitfaden zur Integration
- Anwendungskennwörter-Feature-Plugin
Bessere Unterstützung für PHP 8
PHP 8.0 bringt tonnenweise neue Funktionen und Optimierungen mit sich, die es zu einem echten Meilenstein in der Entwicklung der Sprache machen. Die neuere Version von PHP führt viele Aktualisierungen ein, die die Abwärtskompatibilität brechen, und viele veraltete Funktionen sind jetzt offiziell entfernt worden. Das Hinzufügen der Unterstützung für PHP 8 in WordPress ist also eine große Herausforderung.
Tatsächlich sollten wir nicht erwarten, dass jedes mögliche Problem entdeckt wird, selbst wenn die Mitwirkenden des WordPress Core große Anstrengungen unternehmen, um WordPress 5.6 mit PHP 8 kompatibel zu machen. Das Ziel hier ist es, einen Punkt zu erreichen, an dem das gesamte WordPress-Ökosystem mit PHP 8 kompatibel ist, was im Moment wirklich eine harte Nuss zu sein scheint.
Darüber hinaus enthält eine WordPress-Webseite mindestens ein Theme und eine variable Anzahl von Plugins. Was wir also erwarten können, ist eine gute Unterstützung für PHP 8 im WordPress-Core, aber es ist schwer zu glauben, dass Plugins und Themes schnell Unterstützung für PHP 8 hinzufügen werden.
Wir stimmen Jonathan Desrosiers zu, wenn er sagt:
Es ist unmöglich, den Stand der Unterstützung von PHP 8 innerhalb des breiteren Ökosystems (Plugins, Themes usw.) zu kennen. Aus diesem Grund sollte WordPress 5.6 als „beta-kompatibel“ mit PHP 8 betrachtet werden.
„Beta-kompatibel mit PHP 8“ scheint ein guter Ausdruck zu sein, um einen laufenden Prozess darzustellen, der noch viel Arbeit erfordert, aber gleichzeitig die bisher geleistete großartige Arbeit anerkennt.
Wie auch immer,
Alle Plugin- und Themeentwickler sowie die Hosting-Communities sind aufgerufen, ihren Code mit PHP 8 kompatibel zu machen. Auf diese Weise kann WordPress schneller wirklich „volle Kompatibilität“ erreichen, ohne dass die Endbenutzer die Last tragen müssen.
Einige PHP 8-Änderungen zur Kenntnisnahme
Wie wir bereits erwähnt haben, ist die vollständige Kompatibilität von WordPress mit PHP 8 noch in Arbeit. Jonathan Desrosiers stellt eine Liste von PHP 8-Funktionen und Änderungen vor, die WordPress-Entwickler beachten sollten.
Benannte Parameter
Mit PHP ist es nun möglich, benannte Argumente an eine Funktion zu übergeben, die auf dem Parameternamen und nicht auf der Parameterposition basiert. Dies erlaubt es, Code zu schreiben, der selbstdokumentierend ist, Argumente sind ordnungsunabhängig, und Standardwerte können beliebig übersprungen werden.
Leider können die derzeit benannten Parameter in WordPress Probleme mit der Abwärtskompatibilität verursachen. Der Hauptgrund dafür ist, dass Parameternamen bis zum Abschluss des aktuellen Audits ohne Vorankündigung geändert werden können. Zum Zeitpunkt des Verfassens dieses Artikels waren also:
Die Verwendung benannter Parameter beim Aufruf von WordPress-Funktionen und Klassenmethoden wird explizit nicht unterstützt und bis zum Abschluss dieser Prüfung dringend davon abgeraten, da die Parameternamen während der Prüfung ohne vorherige Ankündigung geändert werden können. Wenn diese Prüfung abgeschlossen ist, wird dies in einer zukünftigen Entwicklernotiz bekannt gegeben.
Strenge Typ-/Wert-Validierungen für interne Funktionen
Bei der Übergabe eines Parameters eines unzulässigen Typs verhalten sich interne und benutzerdefinierte Funktionen unterschiedlich. Benutzerdefinierte Funktionen werfen einen TypeError, aber interne Funktionen verhalten sich in Abhängigkeit von mehreren Bedingungen auf unterschiedliche Weise.
Um diese Inkonsistenzen zu beseitigen, erzeugen in PHP 8 die internen APIs zum Parsen von Parametern immer einen ThrowError, wenn der Parametertyp nicht übereinstimmt.
Strenge Typdeklaration wird in WordPress Core nicht verwendet. Die Core-Mitarbeiter arbeiten jedoch daran zu verhindern, daß ungültige Typen an Core-Funktionen übergeben werden. Bis diese Arbeit abgeschlossen ist, kann diese PHP 8-Änderung zu TypeErrors führen, „insbesondere wenn der Typ eines Wertes fälschlicherweise durch Code geändert wird, der mit einem Filter verbunden ist“.
Strengere Typprüfungen für arithmetische und bitweise Operatoren
In früheren Versionen von PHP war die Verwendung von arithmetischen und bitweisen Operatoren für ein Array, eine Ressource oder ein nicht überladenes Objekt erlaubt, aber das Verhalten war inkonsistent und manchmal sogar unvernünftig:
var_dump([] % [42]);
// int(0)Mit PHP 8 ist das Verhalten immer dasselbe, und alle arithmetischen und bitweisen Operatoren werfen eine TypeError-Ausnahme, wenn der Operand ein Array, eine Ressource oder ein nicht überladenes Objekt ist (siehe RFC).
Dies ist eine weitere Änderung, die einige zusätzliche Arbeit von den Hauptbeitragszahlern erfordert, wie z.B. die vielen Fehler, Warn- und Hinweisänderungen.
Auch hier wird aufgrund der verschiedenen noch ungelösten Probleme dringend empfohlen, Kompatibilitätstests in einer Staging-oder Entwicklungsumgebung durchzuführen, bevor du die Umstellung auf PHP 8 auf deiner Live-Webseite vornimmst. Lies mehr über WordPress und PHP 8.0.
Zusätzliche Änderungen für Entwickler
WordPress 5.6 führt Tonnen von Änderungen für Entwickler ein, und wir konnten nicht alle in unsere Liste aufnehmen. Aber hier sind die Top 3, die wir für sehenswert halten:
1. wp_after_insert_post Action Hook
Vor WordPress 5.6 konnte man save_posts oder ähnliche Aktionen verwenden, um benutzerdefinierten Code auszuführen, nachdem ein Beitrag veröffentlicht wurde. Jetzt führt WordPress 5.6 den neuen wp_after_insert_post Action Hook ein, der erst nach dem Speichern von Begriffen und Metadaten ausgelöst wird.
Darüber hinaus wurden mehrere Funktionen aktualisiert, um zu verhindern, dass diese Hooks abgefeuert werden. Der neue Parameter $fire_after_hooks wurde zu den Funktionen wp_insert_post(), wp_update_post() und wp_insert_attachment() hinzugefügt. Wenn er auf false gesetzt wird, verhindert er, dass die After-Insert-Hooks abgefeuert werden.
Schaue dir die devnote für einen tieferen Überblick an.
2. Typisierung
Die Typecasting-Funktionen intval(), strval(), floatval() und boolval() wurden zugunsten des direkten Typecasting aus dem Core entfernt:
intval()→(int)strval()→(string)floatval()→(float)
Diese Änderung hat direkte Auswirkungen auf die Leistung, da das direkte Typecasting ~6x schneller ist als Typecasting-Funktionen.
3. WP_Fehlerobjekte
Die Klasse WP_Error wurde erweitert, um das Zusammenführen mehrerer WP_Error-Instanzen zu einer einzigen zu ermöglichen. Zuvor konnte man dies nur manuell tun. Jetzt führt WordPress 5.6 drei neue Methoden ein, die bei der Handhabung mehrerer WP_Error-Instanzen helfen. Der folgende Code ist ein Beispiel aus dem Entwicklerhinweis:
<?php
$error_1 = new WP_Error(
'code1',
'This is my first error message.',
'Error_Data'
);
$error_2 = new WP_Error(
'code2',
'This is my second error message.',
'Error_Data2'
);
// Merge from another WP_Error.
$error_1->merge_from( $error_2 );
// Retrieve all error data, optionally for a specific error code.
$error_1->get_all_error_data( 'code2' );
// Export to another WP_Error
$error_1->export_to( $error_2 );Weitere Lektüre für Entwickler
Es ist unmöglich, alle Änderungen zu erwähnen, die mit WordPress 5.6 eingeführt wurden, aber man kann mit Hilfe der folgenden Ressourcen mehr darüber lesen:
- Aktualisierung der mit WordPress ausgelieferten jQuery-Version
- Aktualisierung von core jQuery auf Version 3 – Teil 2
- WordPress und PHP 8.0
- REST-API-Batch-Framework in WordPress 5.6
- Diverse entwicklerorientierte Änderungen in WordPress 5.6
Zusammenfassung
WordPress 5.6 ist eine Hauptversion mit zahlreichen Funktionen und Änderungen sowohl für Benutzer als auch für Entwickler. Wir sind immer gespannt, wie sich die Entwicklung der Webtechnologien direkt auf die Sicherheit, Leistung, Benutzerfreundlichkeit und Zugänglichkeit von WordPress auswirkt.
Aber die Entwicklung hört nie auf, und wir können schon jetzt einen Blick auf zukünftige mögliche Veröffentlichungstermine werfen.
Jetzt bist du dran: Was gefällt dir am besten an WordPress 5.6? Und welche Funktionen würdest du gerne in WordPress 5.7 hinzufügen?
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