Home Blog WordPress 7.1: bessere UX made by required

WordPress 7.1: bessere UX made by required

Avatar von Jeff Chi
Stilisierte Zahlen "7.1" in einem required-typischen Wellenhintergrund.

Am 19. August 2026 ist WordPress 7.1 erschienen. Die aktuelle Version bringt wie immer viele neue Features mit, von denen sowohl wir als Agentur profitieren können als auch unsere Kund:innen. Dieses Mal haben wir besonders genau hingeschaut, denn es ist auch eine UX-Verbesserung enthalten, die wir selbst in den letzten Monaten entwickelt haben.

Neben WordPress 7.1 gibt es noch mehr Erwähnenswertes aus dem WordPress-Ökosystem: zum Beispiel die gerade veröffentlichte offizielle Browser-Extension. Über die Neuerungen in und um WordPress herum bietet dieser Artikel einen Überblick.

Verbesserungen und Neues in WordPress 7.1

Unser Beitrag: keine Inhalte mehr versehentlich löschen

Über dieses Problem sind wir in der Vergangenheit nicht nur einmal gestolpert: Beim Löschen von Usern aus WordPress-Multisites konnte es schnell geschehen, dass auch deren Inhalte entfernt wurden. Nicht nur mussten wir diese dann aus Backups wiederherstellen – es wäre auch schlicht vermeidbar gewesen, wenn das Interface fürs Löschen besser aufgebaut gewesen wäre. Damals meldeten wir dieses UX-Problem als Core-Ticket.

Ein Screenshot des alten Screens für "User löschen" auf WordPress-Single- und Multisites.
Vorher: Der Radio-Button «Delete all content» ist für User auf Multisites vorausgewählt. Ein vorschneller Klick auf «Confirm Deletion» hat weitreichende Folgen.

Als wir letztes Jahr unsere monatlichen internen Contributor-Days ins Leben riefen, war unser Ticket immer noch ungelöst. So wurde es zum idealen Kandidaten, selbst die Ärmel hochzukrempeln und das Problem für alle WordPress-Nutzer:innen weltweit zu lösen.

Ein Screenshot des neuen Screens für "User löschen" ab WordPress 7.1. Standardmässig ist nichts vorausgewählt.
Nachher: Admins müssen aktive Entscheidungen treffen, was mit den Inhalten passieren soll. Vorher kann das Formular nicht abgeschickt werden.

Gute User Experience braucht Accessibility

Jedes neue WordPress-Feature wird einem Accessibility-Review unterzogen. So ist sichergestellt, dass alle Funktionen des CMS vollumfänglich barrierefrei sind. Das Feedback von zertifizierten Accessibility-Expert:innen aus der WordPress-Community hat uns einige Extra-Runden Arbeit beschert – doch die haben wir gerne auf uns genommen. Wenn eine Funktion, die so lange nicht aktualisiert wurde, neu aufgesetzt wird, dann gleich richtig. Das passt perfekt zu unserem eigenen Anspruch.

Responsive Styles

Diese Neuerung begeistert grosse Teile der WordPress-Community: Der Block Editor wird responsiv! Die vielfältigen Styles, die man in WordPress ganz ohne Coden einstellen kann, lassen sich jetzt auch Bildschirmbreiten zuordnen. Voreingestellt sind zwei Breakpoints, die sich per theme.json-Datei aber auch anpassen lassen:

TabletBreite < 480 px
Mobile480 px < Breite < 782 px

Damit wird es noch einfacher, sein Wunsch-Layout direkt im Editor aufzubauen.

Ein Screenshot des Dropdowns mit der neuen Option "Responsive styles".
Wenn die Option «Responsive styles» aktiviert ist, werden alle neu eingestellten Block Styles dem ausgewählten Viewport zugeordnet.
Ein Screenshot mit einem blauen Hinweis "Mobile" samt Info-Icon im Block Editor.
Ein Indikator zeigt an, dass die eingestellten Styles nur für einen bestimmten Viewport gelten – in diesem Beispiel «Mobile».

Mehr lesen: «Responsive block styles» auf wordpress.org

Style States für Buttons

Nicht nur Bildschirmbreiten lassen sich in WordPress 7.1 im Editor stylen, auch Zustände wie «Hover» oder «Focus» (hier genannt «Pseudo State») können eingestellt werden. Das schliesst eine weitere Lücke von Styles, die bisher nur per Code gepflegt werden konnten. Die neue Funktion ist für den Button Block und den Navigation Link Block verfügbar.

Ein Screenshot der neuen Liste von stylebaren Pseudo-States: Default, Hover, Focus, Focus-visible und Active.
In der neuen Liste stehen die States «Hover», «Focus», «Focus-visible» und «Active» zur Verfügung.
Ein Screenshot mit einem blauen Hinweis "Hover" samt Info-Icon im Block Editor. Darüber ein Toggle-Button für "Show state on canvas".
Wie bei den responsiven Styles auch, zeigt ein Indikator an, dass gerade Einstellungen für einen besimmten State hinterlegt werden. «Show state on canvas» simuliert den State im Editor. («Hover» z. B. wäre sonst ja nur beim Überfahren mit der Maus sichtbar.)
Zwei Buttons nebeneinander. Der Rechte wird hovered und bekommt dadurch eine gelbe Schriftfarbe.
Der neue State wird direkt im Editor mit den eingestellten Styles angezeigt.

Die Zustände entsprechen genau denen, die ein Element auch in CSS erhalten kann. Weil über diese manchmal Unklarheit besteht, hier eine kurze Übersicht:

HoverBeim Überfahren mit der Maus sichtbar.
FocusSichtbar, wenn das Element Fokus erhält, z. B. durch: Tastaturnavigation per Tab-Taste, Klick auf interaktive Elemente, JavaScript.
Focus-visibleSichtbar, wenn das Element Tastaturfokus erhält, nicht aber bei normalen Klicks. Ausnahme: Formularfelder.
ActiveNur im Moment der Interaktion sichtbar, z. B. solange die linke Maustaste auf einem Button gehalten wird.

Mehr lesen: «Pseudo style states» auf wordpress.org

Weiteres aus der Welt von WordPress

WordPress-Tools im Browser

Das WordPress-Team nimmt nicht nur regelmässig Verbesserungen am CMS selbst vor, auch drumherum wird immer wieder an neuen Tools gearbeitet. Eine neue Idee, die jetzt veröffentlicht wurde, ist die WordPress-Browser-Extension.

Einmal installiert, erkennt sie automatisch, wenn eine WordPress-Seite geöffnet ist. Dann stellt die Erweiterung einige praktische Funktionen zur Verfügung: zum Beispiel einen direkten Login auf der aktuellen Seite, ohne dass /wp-admin manuell aufgerufen werden muss.

Ein Screenshot der Funktionen in der WordPress-Browser-Extension: "Log In", "Log In, Return to Page", "Highlight Blocks", "Mobile Preview", "Bypass Page Cache" und "Clear Site Data (Keep Login)".
Neben der Möglichkeit zum Login gibt es Developer Tools, um den Cache von Seiten zu umgehen.

Besonders interessant ist noch das Feature «Highlight Blocks». Wer viel mit dem Block Editor arbeitet, kann so direkt im Frontend die Struktur von Inhalten überprüfen – oder sich Inspiration auf anderen WordPress-Seiten holen.

Ein Screenshot von required.com mit hervorgehobenen Blöcken durch die WordPress-Browser-Extension.
Die Struktur der Blöcke wird beim Überfahren mit der Maus sichtbar.

Die Extension steht für Chrome und Safari zur Verfügung. Ein Release für Firefox ist in einem der nächsten Schritte geplant.

Links zur WordPress-Browser-Extension:

Wo sind die WYSIWYG-Revisionen?

In unserem letzten Ankündigungs-Post zu WordPress 6.9 und 7.0 haben wir die neuen visuellen Revisionen im Block Editor vorgestellt. Sie sollen die alte Code-Ansicht gegen eine besser lesbare Block-Ansicht austauschen. Da mittlerweile viele Websites auf WordPress 7.0 und 7.1 aktualisiert wurden, mögen sich einige Nutzer:innen fragen, wieso die neuen Revisionen für sie noch nicht zur Verfügung stehen.

Ein Screenshot der neuen Revisions-Ansicht in WordPress 7.
So sollen die neuen Revisionen ab WordPress 6.9 aussehen …
Ein Screenshot der alten Ansicht für Revisionen im WordPress-Block-Editor, vor WordPress 7.
… aber viele User:innen sehen immer noch diese Ansicht.

Es kann gut sein, dass in diesem Fall das beliebte Plugin Yoast SEO verantwortlich ist, das zu den drei meistinstallierten WordPress-Plugins überhaupt gehört. Yoast SEO verwendet für seine Funktionen im Block Editor immer noch eine sogenannte klassische «Metabox», welche aus technischen Gründen inkompatibel mit den neuen WYSIWYG-Revisionen ist. (Natürlich könnte es auch an einem anderen Plugin liegen, das noch auf eine alte Metabox setzt.)

Zum Zeitpunkt der Veröffentlichung dieses Artikels ist das Problem in der neuesten Version 28.3 von Yoast SEO noch nicht behoben. Der aktuelle Stand kann in einem GitHub-Issue verfolgt werden: https://github.com/Yoast/wordpress-seo/issues/23241