Home Blog WordPress 7.1: better UX made by required

WordPress 7.1: better UX made by required

Jeff Chi Avatar
Stylised numbers ‘7.1’ against a wavy background typical of the ‘required’ style.

WordPress 7.1 was released on 19 August 2026. As always, the latest version brings a host of new features that benefit both us as an agency and our clients. This time, we have taken a particularly close look, as it also includes a UX improvement that we developed ourselves over the last few months.

In addition to WordPress 7.1, there are other exciting developments in the WordPress ecosystem: for example, the official browser extension that has just been released. This article provides an overview of the latest updates in and around WordPress.

Improvements and new features in WordPress 7.1

Our contribution: no more accidental deletion of content

This is a problem we have come up against more than once: when removing users from WordPress multisites, it could easily happen that you also ended up deleting their content. Not only did we then have to restore it from backups – this could simply have been avoided if the deletion interface had been better designed. Back then, we reported this UX issue with a core ticket.

A screenshot of the old ‘Delete User’ screen on WordPress single and multisite installations.
Before: the ‘Delete all content’ radio button is preselected for users on multisite installations. A mistaken click on ‘Confirm Deletion’ has far-reaching consequences.

When we launched our monthly internal Contributor Days last year, our ticket was still unresolved. This made it the ideal opportunity to tackle the issue ourselves and resolve the problem for all WordPress users worldwide.

A screenshot of the new ‘Delete user’ screen from WordPress 7.1 onwards. By default, nothing is pre-selected.
Afterwards: admins must make an active decision about what should happen to the content. The form cannot be submitted until this has been done.

No good User Experience without Accessibility

Every new WordPress feature needs to undergo an accessibility review. This ensures that all functions of the CMS are fully accessible. Feedback given by certified accessibility experts within the WordPress community led to some extra work for us – but we were happy to take it on. When a feature that has not been updated for a long time is being rebuilt, you want to do it properly. This fits perfectly with our own philosophy.

Responsive Styles

This new feature excites large parts of the WordPress community: the Block Editor is going responsive! The wide range of styles customisable in WordPress without any coding can now also be assigned to specific screen widths. Two breakpoints are preset by default, but these can be adjusted via the theme.json file:

Tabletwidth < 480px
Mobile480px < width < 782px

This makes it even easier to bring your layout ideas directly to the editor.

A screenshot of the drop-down menu showing the new ‘Responsive styles’ option.
If the ‘Responsive styles’ option is enabled, all newly set block styles will be assigned to the selected viewport.
A screenshot showing a blue ‘Mobile’ label with an info icon in the Block Editor.
An indicator shows that the current styles only apply to a specific viewport – in this example, ‘Mobile’.

Read more: ‘Responsive block styles’ on wordpress.org

Style States for Buttons

In WordPress 7.1, not only screen widths can be styled in the editor; states such as ‘Hover’ or ‘Focus’ (referred to here as ‘pseudo states’) can also be configured. This closes another gap in styling options that previously could only be managed via code. The new feature is available for the Button Block and the Navigation Link Block.

A screenshot of the new list of stylisable pseudo-states: Default, Hover, Focus, Focus-visible and Active.
The new list includes the states ‘Hover’, ‘Focus’, ‘Focus-visible’ and ‘Active’.
A screenshot showing a blue ‘Hover’ label with an info icon in the Block Editor. Above it is a toggle button for ‘Show state on canvas’.
As with responsive styles, an indicator shows that settings for a particular state are currently being defined. “Show state on canvas” simulates the state in the editor. (Otherwise, “Hover”, for example, would only be visible on mouseover.)
Two buttons side by side. The right-hand one is hovered over, causing its text to turn yellow.
The new state is displayed directly in the editor with the styles that have been set.

These states match exactly those that an element can receive in CSS. As there is sometimes confusion about them, here is a brief overview:

HoverVisible when you hover over the element with the mouse.
FocusVisible when the element receives focus, e.g. via keyboard navigation using the Tab key, clicking on interactive elements, JavaScript.
Focus-visibleVisible when the element receives keyboard focus, but not when clicked normally. Exception: form fields.
ActiveVisible only in the moment of interaction, e.g. while the left mouse button is held down on a button.

Read more: ‘Pseudo style states’ on wordpress.org

More from the world of WordPress

WordPress tools in the browser

The WordPress team not only makes regular improvements to the CMS itself, but is also constantly working on new tools to complement it. One new idea that has now been released is the WordPress browser extension.

Once installed, it automatically detects an open WordPress page. The extension then offers a number of handy features: for example, a direct login on the current page, without having to manually visit /wp-admin.

A screenshot of the features in the WordPress browser extension: ‘Log In’, ‘Log In, Return to Page’, ‘Highlight Blocks’, ‘Mobile Preview’, ‘Bypass Page Cache’ and ‘Clear Site Data (Keep Login)’.
Apart from the option to log in, there are developer tools available to bypass the page cache.

Another interesting feature is ‘Highlight Blocks’. If you work a lot with the Block Editor, this allows you to check the layout structure directly in the front end. You could also use it to get inspiration from other WordPress pages.

A screenshot of required.com with blocks highlighted by the WordPress browser extension.
The block structure becomes visible on mouseover.

The extension is available for Chrome and Safari. A release for Firefox is planned as one of the next steps.

WordPress browser extension links:

What happened to WYSIWYG revisions?

In our last announcement post about WordPress 6.9 and 7.0, we previewed the new visual revisions in the Block Editor. These are intended to replace the old code view with a more readable block view. As many websites have now been updated to WordPress 7.0 and 7.1, some users may be wondering why the new revisions are not yet available to them.

A screenshot of the new revisions view in WordPress 7.
This is what the new revisions are supposed to look like from WordPress 6.9 onwards …
A screenshot of the old view for revisions in the WordPress Block Editor, prior to WordPress 7.
… but many users are still seeing this view.

On many websites, the culprit might be the popular plugin Yoast SEO – one of the three most widely installed WordPress plugins. Yoast SEO still uses a so-called classic ‘metabox’ in the Block Editor, which, for technical reasons, is incompatible with the new WYSIWYG revisions. (Of course, the problem could also be caused by another plugin still relying on an old metabox.)

At the time of publication of this article, the issue has not yet been resolved in the latest version of Yoast SEO (28.3). The current status is tracked in a GitHub issue: https://github.com/Yoast/wordpress-seo/issues/23241