Title: core – Make WordPress Test
---
# Tag Archives: core
[ ](https://profiles.wordpress.org/huzaifaalmesbah/) [Huzaifa Al Mesbah](https://profiles.wordpress.org/huzaifaalmesbah/)
9:42 am _on_ July 15, 2026
Tags: [7-1 ( 4 )](https://make.wordpress.org/test/tag/7-1/),
[call for testing ( 25 )](https://make.wordpress.org/test/tag/call-for-testing/),
core, [core-test ( 231 )](https://make.wordpress.org/test/tag/core-test/), [release-field-guide ( 14 )](https://make.wordpress.org/test/tag/release-field-guide/)
# [Help Test WordPress 7.1](https://make.wordpress.org/test/2026/07/15/help-test-wordpress-7-1/)
WordPress 7.1 — the second major releaseMajor Release A set of releases or versions
having the same major version number may be collectively referred to as “X.Y” --
for example version 5.2.x to refer to versions 5.2, 5.2.1, and all other versions
in the 5.2. (five dot two dot) branch of that software. Major Releases often are
the introduction of new major features and functionality. of 2026 — is coming fast.
The official release will launch **August 19, 2026**.
With 7.1 BetaBeta A pre-release of software that is given out to a large group of
users to trial under real conditions. Beta versions have gone through alpha testing
in-house and are generally fairly close in look, feel and function to the final
product; however, design changes often occur as part of the process. 1 slated for
release on the July 15th, your help testing is vital to ensuring a stable and reliable
release that continues to benefit WordPress users across the globe.
**Early testing is critical.**
Early testing helps identify bugs, usability issues, and compatibility concerns
while there’s still time to address them.
Then at launch, you’ll find your testing might have led to an improvement you can
see and feel.
Got a few minutes? A few hours? Every bit of testing makes a big difference — possibly,
the difference between a new feature landing in 7.1 or not.
**Stay informed!**
The **WordPress 7.1** [release schedule](https://make.wordpress.org/core/7-1/) **
page has everything** you need to know about the latest pre-release builds and milestones.
For real-time updates, you can follow discussions and find collaboration opportunities
in the [**#core-test**](https://wordpress.slack.com/messages/core-test/) and [**#core**](https://wordpress.slack.com/archives/C02RQBWTW)
channels in the Making WordPress SlackSlack Slack is a Collaborative Group Chat
Platform [https://slack.com/](https://slack.com/). The WordPress community has its
own Slack Channel at [https://make.wordpress.org/chat/](https://make.wordpress.org/chat/).
You might want to join both channels!
Also, you are more than welcome at every upcoming [**release party**](https://make.wordpress.org/core/2026/07/03/wordpress-7-1-release-party-schedule/)**,
testing session, and** [**test scrub**](https://make.wordpress.org/test/2026/07/06/test-scrub-schedule-for-wordpress-7-1/)
throughout the release cycle and beyond.
**Thank you!**
Did you know you’re already a hero? Anything you do — even just reading this post—
helps shape WordPress 7.1 into the strongest, most polished release ever.
And with the new features coming in 7.1, you’ll help make it a blockbuster release
for the entire community.
* [🧪 Testing Tips](https://make.wordpress.org/test/tag/core/?output_format=md#testing-tips)
* [How to test WordPress Beta Versions ](https://make.wordpress.org/test/tag/core/?output_format=md#how-to-test-wordpress-beta-versions)
- [WP-Playground](https://make.wordpress.org/test/tag/core/?output_format=md#wp-playground)
- [A Local Site on your computer](https://make.wordpress.org/test/tag/core/?output_format=md#a-local-site-on-your-computer)
- [WP-CLI](https://make.wordpress.org/test/tag/core/?output_format=md#wp-cli)
- [Testing tickets in the browser ](https://make.wordpress.org/test/tag/core/?output_format=md#testing-tickets-in-the-browser)
* [General Testing Checklist](https://make.wordpress.org/test/tag/core/?output_format=md#general-testing-checklist)
* [Key Features to Test](https://make.wordpress.org/test/tag/core/?output_format=md#key-features-to-test)
* [Collaboration](https://make.wordpress.org/test/tag/core/?output_format=md#collaboration)
- [New Notes features](https://make.wordpress.org/test/tag/core/?output_format=md#new-notes-features)
* [Design & Interface](https://make.wordpress.org/test/tag/core/?output_format=md#design-interface)
- [Responsive styling](https://make.wordpress.org/test/tag/core/?output_format=md#responsive-styling)
- [Interactive states styling](https://make.wordpress.org/test/tag/core/?output_format=md#interactive-states-styling)
- [Persistent Toolbar](https://make.wordpress.org/test/tag/core/?output_format=md#persistent-toolbar)
- [Dedicated Identity section](https://make.wordpress.org/test/tag/core/?output_format=md#dedicated-identity-section)
- [Admin color scheme reflected in the Site Editor](https://make.wordpress.org/test/tag/core/?output_format=md#admin-color-scheme-reflected-in-the-site-editor)
- [Command palette sections and Recently used](https://make.wordpress.org/test/tag/core/?output_format=md#command-palette-sections-and-recently-used)
- [Choose which block styles to apply globally](https://make.wordpress.org/test/tag/core/?output_format=md#choose-which-block-styles-to-apply-globally)
* [Media](https://make.wordpress.org/test/tag/core/?output_format=md#media)
- [Client-side media processing](https://make.wordpress.org/test/tag/core/?output_format=md#client-side-media-processing)
- [Media Editor Modal](https://make.wordpress.org/test/tag/core/?output_format=md#media-editor-modal)
- [Smarter galleries](https://make.wordpress.org/test/tag/core/?output_format=md#smarter-galleries)
* [Dashboard](https://make.wordpress.org/test/tag/core/?output_format=md#dashboard)
- [Visual Revisions improvements](https://make.wordpress.org/test/tag/core/?output_format=md#visual-revisions-improvements)
- [Untitled posts show an excerpt in the Posts list](https://make.wordpress.org/test/tag/core/?output_format=md#untitled-posts-show-an-excerpt-in-the-posts-list)
- [Re-parent a comment from the Edit Comment screen](https://make.wordpress.org/test/tag/core/?output_format=md#re-parent-a-comment-from-the-edit-comment-screen)
* [Blocks](https://make.wordpress.org/test/tag/core/?output_format=md#blocks)
- [Playlist block](https://make.wordpress.org/test/tag/core/?output_format=md#playlist-block)
- [Tabs block](https://make.wordpress.org/test/tag/core/?output_format=md#tabs-block)
- [Background gradients now work alongside background images](https://make.wordpress.org/test/tag/core/?output_format=md#background-gradients-now-work-alongside-background-images)
- [Image block — "Mark as decorative" toggle](https://make.wordpress.org/test/tag/core/?output_format=md#image-block-mark-as-decorative-toggle)
- [Editable blocks inside the Custom HTML block](https://make.wordpress.org/test/tag/core/?output_format=md#editable-blocks-inside-the-custom-html-block)
- [Embed block — embed shortcode transform](https://make.wordpress.org/test/tag/core/?output_format=md#embed-block-embed-shortcode-transform)
- [Shortcode block — block-specific transforms](https://make.wordpress.org/test/tag/core/?output_format=md#shortcode-block-block-specific-transforms)
* [What to Notice](https://make.wordpress.org/test/tag/core/?output_format=md#what-to-notice)
* [Where to Report Feedback](https://make.wordpress.org/test/tag/core/?output_format=md#where-to-report-feedback)
* [Changelog](https://make.wordpress.org/test/tag/core/?output_format=md#changelog)
## **🧪 Testing Tips**
You don’t need to be a certified software tester or QA professional, or any kind
of expert, to help test WordPress.
Simply using WordPress as you would every day (on a test installation, of course!)
can help identify any bottlenecks and bugs that a WordPress user may encounter.
through processes that mimic your daily projects, workflows, and experiments and
report any findings.
Or if you feel compelled, push WordPress to its limits. Try to break things. Have
five editors in wp-admin at once, have someone relentlessly reload the home page,
step outside standard practices and use WordPress in unexpected ways.
Notice something unexpected? Run into a bug? Is a feature not behaving the way you
thought it would? Please consider reporting it to the [Alpha/Beta area](https://wordpress.org/support/forum/alphabeta/)
of the support forums, or directly to [WordPress Trac](https://core.trac.wordpress.org/newticket)
if you are comfortable writing a reproducible bug report.
Not sure what the expected behavior should be? No problem! Join the conversation
in the **[#core-test](https://make.wordpress.org/test/tag/core-test/) channel on
the Making WordPress Slack**, where contributors and developers are always happy
to help. New tester? You have the global WordPress community at your service. Everyone
in it is happy to welcome and support you. 🌍 You’re also welcome and encouraged
to join the [#core-test](https://wordpress.slack.com/archives/C03B0H5J0) Slack channel
and ask questions about testing!
Again — every report, question, or observation you submit makes a difference, and
helps improve WordPress for hundreds of millions of users. Testing is a valuable
way to contribute to the WordPress project, and testers are included in release
credits on the final release.
**Recommendations for Testing WordPress Beta/RCRelease Candidate A beta version
of software with the potential to be a final product, which is ready to release
unless significant bugs emerge. Versions:**
* **Test the CoreCore Core is the set of software required to run WordPress. The
Core Development Team builds WordPress. Features that Matter to You:** Use your
site the way you usually do. For instance, if you’re a blogger, running a social
platform, or managing an e-commerce store, run your tests through those specific
scenarios.
* Set up a **staging site** (ask your hosting provider if this is new to you). **
Do not test or update your live site with a beta version** for testing; your
users might see any issues that come up.
* Update WordPress in the staging environmentStaging Environment A staging environment
is a non-production copy of your site. This is a private place to build the site--
design, copy, and code -- until your client approves it for production or live.
Sometimes used in addition to, or as a Development Environment.. Keep using your
site as normal.
* Take note of anything you experience after the update. Log any errors, alerts
or strange behavior during your testing process, and the steps you took when
you encountered the issue.
* Use the General Checklist below to verify everything works as you’d expect.
## **How to test WordPress Beta Versions **
You can test WordPress Beta versions in several ways. Some are fast and easy; some
let you run sophisticated tests on the latest backend features.
All of them keep your live websites **safe from the effects of any issues you find:**
### **WP-Playground**
Playground is a fast and easy way to spin up a test site — without setting up a
full environment. Get started testing right away on [WordPress Playground](https://playground.wordpress.net/?mode=seamless#%7B%22preferredVersions%22:%7B%22php%22:%228.0%22,%22wp%22:%22beta%22%7D,%22features%22:%7B%22networking%22:true%7D,%22steps%22:%5B%7B%22step%22:%22login%22,%22username%22:%22admin%22,%22password%22:%22password%22%7D,%7B%22step%22:%22importWxr%22,%22file%22:%7B%22resource%22:%22url%22,%22url%22:%22https://raw.githubusercontent.com/wpaccessibility/a11y-theme-unit-test/master/a11y-theme-unit-test-data.xml%22%7D%7D,%7B%22step%22:%22importWxr%22,%22file%22:%7B%22resource%22:%22url%22,%22url%22:%22https://raw.githubusercontent.com/WordPress/theme-test-data/master/themeunittestdata.wordpress.xml%22%7D%7D,%7B%22step%22:%22installPlugin%22,%22pluginZipFile%22:%7B%22resource%22:%22wordpress.org/plugins%22,%22slug%22:%22query-monitor%22%7D,%22options%22:%7B%22activate%22:false%7D,%22progress%22:%7B%22weight%22:2%7D%7D,%7B%22step%22:%22installPlugin%22,%22pluginZipFile%22:%7B%22resource%22:%22wordpress.org/plugins%22,%22slug%22:%22create-block-theme%22%7D,%22progress%22:%7B%22weight%22:2%7D%7D,%7B%22step%22:%22installPlugin%22,%22pluginZipFile%22:%7B%22resource%22:%22wordpress.org/plugins%22,%22slug%22:%22debug-bar%22%7D,%22progress%22:%7B%22weight%22:2%7D%7D,%7B%22step%22:%22installPlugin%22,%22pluginZipFile%22:%7B%22resource%22:%22wordpress.org/plugins%22,%22slug%22:%22health-check%22%7D,%22progress%22:%7B%22weight%22:2%7D%7D,%7B%22step%22:%22installPlugin%22,%22pluginZipFile%22:%7B%22resource%22:%22wordpress.org/plugins%22,%22slug%22:%22test-reports%22%7D,%22progress%22:%7B%22weight%22:2%7D%7D,%7B%22step%22:%22installPlugin%22,%22pluginZipFile%22:%7B%22resource%22:%22wordpress.org/plugins%22,%22slug%22:%22user-switching%22%7D,%22progress%22:%7B%22weight%22:2%7D%7D%5D%7D).
### **A Local Site on your computer**
Software like [Local](https://localwp.com/) or [wp-env](https://developer.wordpress.org/block-editor/getting-started/devenv/get-started-with-wp-env/)
lets you build a full WordPress site on your computer — no internet required.
**
How to set up your site:**
1. Download and install [Local](https://localwp.com/).
2. Create a new WordPress site.
3. Once your site is up and running, install and activate the **WordPress Beta Tester**
pluginPlugin A plugin is a piece of software containing a group of functions that
can be added to a WordPress website. They can extend functionality or add new
features to your WordPress websites. WordPress plugins are written in the PHP
programming language and integrate seamlessly with WordPress. These can be free
in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/)
or can be cost-based plugin from a third-party.. This plugin lets you install
pre-release versions of WordPress.
4. Navigate to **Tools → Beta Testing**.
5. Choose one of the following options:
6. * **Bleeding Edge → Beta/RC Only** to test the latest Beta or Release CandidateRelease
Candidate A beta version of software with the potential to be a final product,
which is ready to release unless significant bugs emerge..
* **Bleeding Edge → Nightlies** (or **Point ReleaseMinor Release A set of releases
or versions having the same minor version number may be collectively referred
to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3,
and all other versions in the 5.2 (five dot two) branch of that software. Minor
Releases often make improvements to existing features and functionality. Nightlies**,
if applicable) to test the latest development build with the newest code changes.
7. Click **Save Changes**.
8. Go to **Dashboard → Updates**.
9. Confirm that an update is available (for example, **Update to WordPress 7.1 Beta**,**
Release Candidate**, or **Nightly**, depending on the option you selected).
10. Click **Update to WordPress 7.1 Beta/RC/Nightly** and wait for the update to complete.
11. Verify that your site is now running the selected pre-release version of WordPress.
_Follow this_ [_guide_](https://make.wordpress.org/core/handbook/testing/beta-testing/)
_for more detailed instructions._
### **WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is [http://wp-cli.org/](http://wp-cli.org/) [https://make.wordpress.org/cli/](https://make.wordpress.org/cli/)**
Are you most at home in the command line? [WP-CLI](https://developer.wordpress.org/cli/commands/core/update/)
lets you install a WordPress beta version in record time.
**Steps:**
* Create a local WordPress site however you like to do it. Wait for the notification
that your site is ready.
* Open your terminal and navigate to the root directory of your WordPress installation.
Run the following command to update to the latest beta version:
```wp-block-code
wp core update --version=7.1-beta1
```
Or
```wp-block-code
wp core update --version=7.1-RC1
```
_(Replace the version number as needed, such as `--version=7.1-beta2`.)_
With WP-CLI, you can install several different versions and switch between them
easily. That makes it much easier to test specific builds and compare them.
**A Staging Site on your host**
You can build a [staging site](https://woocommerce.com/posts/what-is-staging-site-wordpress-how-to-set-one-up/)
for your production/live site and test it with the WordPress beta/RC version — **
without affecting your live site.**
That way, you’ll be sure everything works the way it should — long before WordPress
7.1 lands in your production/live environment.
**Testing Patches**
A patch is a quick and smaller update that fixes security or other bugs. Maybe you
don’t need to test an entire version of WordPress, but you do want to test one or
more patches to see if a bug is fixed.
In that case, you’ll need a specific local WordPress development environment.
[Follow these instructions](https://make.wordpress.org/test/handbook/get-setup-for-testing/)
to set it up.
### **Testing tickets in the browser **
Do you have a particular PR in the [wordpress-develop](https://github.com/WordPress/wordpress-develop)
or [gutenberg](https://github.com/WordPress/gutenberg) repo that you’d like to test
in the browser?
You can use Playground for that, and [test any core tickets](https://make.wordpress.org/test/handbook/get-setup-for-testing/test-core-tickets-with-playground/)
you like — without installing any software on your system. Just use these links:
* [https://playground.wordpress.net/wordpress.html](https://playground.wordpress.net/wordpress.html)
* [https://playground.wordpress.net/gutenberg.html](https://playground.wordpress.net/gutenberg.html)
## **General Testing Checklist**
Want to see how well your site runs on the very latest version of WordPress? Here’s
a checklist that should give you an idea — and won’t take all day.
Use one of the methods above to set up your testing site, and update to the latest
Beta/RC version.
Enable [debugging](https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/#example-wp-config-php-for-debugging)
in wp-config.php, and update your theme and plugins.
* Did any plugins or themes deactivate automatically after the update?
* Check the WordPress **Site Health** tool. Did you find any new warnings or issues?
* Check templates and patterns, and then actual posts and pages, for layout problems.
Are all the elements lined up properly? Is spacing correct?
* Test links and permalinks to ensure there are no 404 or other errors.
* Do design elements, images, and media look the way they should? Do media files
load and play properly? How does the audio sound?
* How are the sitemap and robots.txt files working?
* Can users at every permission level get to the admin dashboard without errors?
Does each level show the right tools, and do they work?
* Does your site have custom blocks? Add content to a new blockBlock Block is the
abstract term used to describe units of markup that, composed together, form
the content or layout of a webpage using the WordPress editor. The idea combines
concepts of what in the past may have achieved with shortcodes, custom HTML,
and embed discovery into a single consistent API and user experience.. Edit it.
Now edit a block that already has content.
* Create a new post:
- Add content.
- Copy some text and paste it.
- Add a few different kinds of media files.
- Save the post and watch the console for any issues.
* Create a new page.
- Add content.
- Open it in several different browsers. Does it look and feel right in each?
Does the page function properly in each?
* Open the browser’s developer tools. Check each tab, plus the console, for errors,
warnings, or notices. Check any visible CSSCSS CSS is an acronym for cascading
style sheets. This is what controls the design or look and feel of a site. or
JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming
language commonly used to create interactive effects within web browsers. WordPress
makes extensive use of JS for a better user experience. While PHP is executed
on the server, JS executes within a user’s browser. [https://www.javascript.com](https://www.javascript.com/)
for unexpected changes.
* Check the error log file for notices, warnings, and errors — especially fatal
errors.
* Have you set up scheduled posts or automated tasks (like backups)? Can you find
them in the admin? Do they run on schedule? Do they work?
* Check integrated services like payment gateways or analytics. Do they still connect?
Do they execute?
* Open your site in different browsers and make sure all functionalities work as
expected — beyond the ones you checked on pages earlier.
* Check site performance: page loading, APIAPI An API or Application Programming
Interface is a software intermediary that allows programs to interact with each
other and share data in limited, clearly defined ways. calls, database requests.
You might want to check this on a few devices in real life.
* Also, every browser has tools that let you simulate a variety of network conditions.
How does your updated site handle low bandwidth?
* Test accessibilityAccessibility Accessibility (commonly shortened to a11y) refers
to the design of products, devices, services, or environments for people with
disabilities. The concept of accessible design ensures both “direct access” (
i.e. unassisted) and “indirect access” meaning compatibility with a person’s
assistive technology (for example, computer screen readers). (https://en.wikipedia.
org/wiki/Accessibility) basics: keyboard navigation, contrast, screen-reader
behavior — whatever assistive technologyAssistive technology **Assistive technology**
is an [umbrella term](https://en.wikipedia.org/wiki/Umbrella_term) that includes
assistive, adaptive, and rehabilitative devices for [people with disabilities](https://en.wikipedia.org/wiki/Disability)
and also includes the process used in selecting, locating, and using them. Assistive
technology promotes greater independence by enabling people to perform tasks
that they were formerly unable to accomplish, or had great difficulty accomplishing,
by providing enhancements to, or changing methods of interacting with, the [technology](https://en.wikipedia.org/wiki/Technology)
needed to accomplish such tasks. [https://en.wikipedia.org/wiki/Assistive_technology](https://en.wikipedia.org/wiki/Assistive_technology)
you have on hand.
* Check your forms — contact forms, checkout forms, login forms, and more. Can
you fill all the fields? Submit and clear? Does the data end up in the right
place?
* Can you upload media? Edit images? Does gallery functionality work properly?
* Check your theme. Does the basic theme look right? Did theme customizations —
in the Site Editor, or the CustomizerCustomizer Tool built into WordPress core
that hooks into most modern themes. You can use it to preview and modify many
of your site’s appearance settings. in Classic themes — change in the upgrade?
Or did they sail through perfectly?
## **Key Features to Test**
## **Collaboration**
### **New Notes features**
Notes let people leave feedback directly in the editor. WordPress 7.1 makes them
much richer: notes on specific words or across multiple blocks, **rich text **inside
notes, **@mentions**, **multiple note threads on the same block**, a **show more/
less** toggle for long notes, and a toolbar button that puts starting a note within
easy reach.
**Testing Steps**
1. Create a new post and add a few paragraphs of content.
2. **Select some text** inside a paragraph.
3. Open the **block toolbar** (or the **⋮ options** menu) and choose **Add note**(
look for a note/comment icon).
4. Type a note and **save** it. Confirm the note appears anchored to the text you
selected.
5. **Reply** to your own note and confirm the reply shows in the thread.
6. Add formatting using keyboard shortcuts — there’s no visible toolbar. Select text
and press ⌘/Ctrl + B (bold), ⌘/Ctrl + I (italic), or ⌘/Ctrl + K (link). To get
code formatting, type text wrapped in backticks (`like this`). Confirm the formatting
is kept after saving. (Formatting is intentionally limited to bold, italic, link,
and code.)
7. Start a **second, separate thread** on the same block and confirm both threads
are tracked independently.
8. Add a note that spans **more than one block** and confirm it’s tracked correctly.
9. Add a long note and confirm the **show more/less** toggle collapses and expands
it.
10. **@mention** another user in a note and confirm the mention is inserted correctly.
**Expected:**
Notes attach to the right content; replies, mentions with notifications, multiple
threads per block, keyboard formatting, and the show more/less toggle all work as
described.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Follow [#76316](https://github.com/WordPress/gutenberg/issues/76316)
for more details.
## **Design & Interface**
### **Responsive styling**
Style a block differently for **tablet** and **mobile** directly in the editor —
without custom CSS. Turn on **Responsive editing** from the device-preview dropdown,
switch to Tablet or Mobile, and the change is saved only for that breakpoint.
**📣 Dedicated Call for Testing post:** [Call for Testing: Responsive Styling](https://make.wordpress.org/test/2026/07/03/call-for-testing-responsive-styling/)—
follow it for the full set of scenarios (resize handles + device view syncing, per-
viewport styles, the viewport badge, hidden-on-device blocks, front-end checks,
and notes for plugin/theme developers).
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Reference [PR #75121](https://github.com/WordPress/gutenberg/pull/75121)
for more details.
### **Interactive states styling**
You can now style a Button’s **interactive states** — hover, focus, and active —**
without writing a single line of CSS**. For example, a button that changes color
the moment you hover over it.
**There are two layers to this:**
* **Global Styles:** set hover, focus, and active styles once and they apply to**
every** Button across the whole site.
* **Individual block instance:** A single Button can have its own hover, focus,
and active styles that leave every other button untouched. Note that per-instance
pseudo states are currently supported by the **Button block only**; other blocks
don’t expose them yet.
**Testing Steps**
**Global Styles first (applies to all buttons)**
1. Open the **Site Editor** and go to **Styles → Blocks → Button**.
2. Use the **States selector** to switch to the **Hover** state.
3. With **Hover** active, set a different **Background** and **Text** color (and any
other styles you like).
4. Repeat for the **Focus** and **Active** states, giving each its own look.
5. **Save** the styles.
6. On the frontend, hover, focus, and click a button and confirm the correct styles
appear for **every** button on the site.
**Then an individual Button instance (applies to one button only)**
1. Add **two or more** **Button** blocks to a post or page.
2. Select **one** of them and open its **Styles** settings.
3. Open the **state selector** in the block card headerHeader The header of your site
is typically the first thing people will experience. The masthead or header art
located across the top of your page is part of the look and feel of your website.
It can influence a visitor’s opinion about your content and you/ your organization’s
brand. It may also look different on different screen sizes. (a small three-dot
menu) and switch to **Hover**.
4. Change a style for example the **Background** color. The canvas should update **
immediately**; toggle **Show state on canvas** off and on to confirm it’s previewing
the hover look live.
5. **Save** and view the post on the frontend. Hovering **that one** button should
use the styles you set, while the **other** buttons stay unchanged.
6. Switch to **Focus** and **Active** and repeat, giving that single button its own
states.
7. Reset the hover styles for that instance and confirm the other states and the global
styles are unaffected.
**Expected**:
Global hover, focus, and active styles apply to **all** buttons site-wide, while
per-instance styles apply to **only the selected button**. The two layers combine
sensibly, resetting one layer doesn’t disturb the others, and **Show state on canvas**
previews the state in the editor without you having to actually hover.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Follow [issue #38277](https://github.com/WordPress/gutenberg/issues/38277)(
per-instance support landed in [PR #76491](https://github.com/WordPress/gutenberg/pull/76491))
for more details.
### **Persistent Toolbar**
The admin toolbar now appears **inside the Post Editor and the Site Editor** too—
previously it disappeared in the Site Editor — along with a few visual refreshes:
the home icon becomes your **site icon** (when set), your profile **avatarAvatar
An avatar is an image or illustration that specifically refers to a character that
represents an online user. It’s usually a square box that appears next to the user’s
name. is circular**, and the **command palette icon is removed from the editor toolbar**.
**Testing Steps**
1. Set a **Site Icon** (Site Editor → Design → Identity, or Settings) if you haven’t
already.
2. Open the **Post Editor** (edit any post) and confirm the **admin bar is visible
at the top**.
3. Open the **Site Editor** (Appearance → Editor) and confirm the **admin bar is visible
there too** (it used to disappear).
4. Confirm the admin bar’s home item shows your **site icon**, not the old dashicon(
with no site icon set, it falls back to the default icon).
5. Confirm your profile **avatar is a circle**, not a square.
6. Confirm there is **no command palette icon** in the editor toolbar anymore, and
that the palette still opens with **Cmd/Ctrl + K**.
7. Switch your **Admin Color Scheme** (Users → Profile) and confirm the admin bar
in both editors follows the scheme.
8. Resize to a narrow / mobile width and confirm the admin bar still looks correct
in the editors.
**Expected:**
The admin bar is visible in both the Post and Site Editor, shows the site icon (
when set) and a circular avatar, no longer carries the command-palette icon in the
editor toolbar, and follows the chosen admin color scheme.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Follow [issue #79036](https://github.com/WordPress/gutenberg/issues/79036)
for more details.
### **Dedicated Identity section**
The **Design → Identity** panel now lets you edit your **Site Title** and **Site
Tagline** right alongside the existing **Site Logo** and **Site Icon** no need to
jump over to Settings. Changes update the matching **Site Title** and **Site Tagline**
blocks live in the editor preview.
**Testing Steps**
1. Open the **WordPress Dashboard** and go to **Appearance → Editor**.
2. In the **Site Editor**, go to **Design → Identity**.
3. Confirm four fields appear in order: **Site Title**, **Site Tagline**, **Site Logo**,**
Site Icon**.
4. Confirm the description text below each field is the **same size and style**.
5. Edit the **Site Title** and watch the Site Title block update in the preview.
6. Edit the **Site Tagline** and watch the Site Tagline block update in the preview.
7. Click **Save** and confirm all edited fields appear in the save panel.
8. Reload the editor and confirm your changes **persisted**.
**Expected:**
Site Title and Site Tagline can be edited from the Identity panel, the preview updates
as you type, and changes save and persist correctly.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Follow [#76261](https://github.com/WordPress/gutenberg/issues/76261)
for more details.
### **Admin color scheme reflected in the Site Editor**
The Site Editor now follows your chosen WordPress admin color scheme instead of
always showing a fixed dark interface. The sidebarSidebar A sidebar in WordPress
is referred to a widget-ready area used by WordPress themes to display information
that is not a part of the main content. It is not always a vertical column on the
side. It can be a horizontal rectangle below or above the content area, footer,
header, or any where in the theme. and surrounding chrome pick up your scheme’s
colours, while the editing canvas stays white for readability.
**Testing Steps**
1. Go to **Users → Profile** and pick an **Admin Color Scheme** (e.g. Modern, Blue,
Coffee, Ectoplasm, Midnight, Ocean, Sunrise).
2. Open the **Site Editor** (Appearance → Editor).
3. Confirm the sidebar and interface chrome reflect the chosen colour scheme, not
a fixed dark background.
4. Confirm the editing canvas / content area stays white and readable.
5. Switch to a different admin colour scheme and confirm the **Site Editor** updates
to match.
6. Resize the browser to a narrow / mobile width and confirm the themed sidebar and
white content still look correct.
**Expected**:
The Site Editor chrome matches your admin colour scheme across all schemes and at
mobile widths, while the content canvas stays white.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Follow [#78397](https://github.com/WordPress/gutenberg/issues/78397)
for more details.
### **Command palette sections and Recently used**
The command palette (Cmd/Ctrl + K) is easier to navigate: commands are now grouped
into sections: **Suggestions**, **Recent**, and **Results**. The commands you use
are remembered under Recent, saved to your user preferences. The palette is also
a bit wider for easier scanning.
**Testing Steps**
1. In the editor, press **Cmd/Ctrl + K** to open the command palette.
2. Run a few different commands and close the palette.
3. Reopen it and confirm a **Recently used** section shows the commands you just ran.
4. Start typing and confirm results are grouped into recent, suggested, and matching
sections.
5. Reload the page (or start a new session) and confirm recently used commands persist.
6. Check the layout is readable and easy to scan.
**Expected**:
Commands are grouped into clear sections, recently used commands persist under **
Recent** and the palette is easier to scan.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Follow [#75616](https://github.com/WordPress/gutenberg/issues/75616)
for more details.
### **Choose which block styles to apply globally**
The block inspector’s **Apply globally** action used to be all-or-nothing: one click
pushed **every** style you’d changed on the block into Global Styles, with no way
to see what was about to change or to leave part of it behind.
WordPress 7.1 adds a review step. **Apply globally** now opens a modal that lists
each changed style on its own row, showing the **current** value next to the **new**
value, with a checkbox for each. Every row is selected by default, so you can deselect
the ones you don’t want and apply only the styles you meant to. Anything you deselect
stays as a local override on the block and isn’t pushed or cleared.
**Testing Steps**
1. Add a Paragraph block to a post and select it.
2. In the block inspector (right sidebar), change a few different styles on the block—
for example make the text uppercase, set a text colour, add some padding, and
set a border colour.
3. Open the Advanced panel in the block inspector and click Apply globally.
4. Confirm a modal opens (it no longer applies everything immediately), and that
it lists one row per changed style, each showing the current value → the new value,
with all rows checked by default.
5. Deselect one row, then click Apply.
6. Confirm only the checked styles were pushed to Global Styles, and that a snackbar
appears. Click Undo in the snackbar and confirm the previous state is restored.
7. Confirm the style you deselected is still set on the block as a local override—
it should not have been pushed, and it should not have been cleared either.
8. Open Apply globally again and confirm the modal now lists only the style you didn’t
push.
9. Deselect every row and confirm the Apply button is disabled.
10. Reopen the modal and dismiss it with Cancel, the close (×) button, and the Escape
key. Each time, confirm nothing changes on the block or in Global Styles.
11. On a block with no changed styles, confirm the Apply globally button is disabled.
12. Resize the browser to a narrow / mobile width and confirm the modal still displays
correctly.
**Expected:**
**Apply globally** opens a review modal listing each changed style with its current
and new values, all selected by default. Only the selected styles are pushed to
Global Styles; deselected styles remain as local overrides on the block and are
neither pushed nor cleared. **Apply** is disabled with nothing selected and when
there are no changes to push, cancelling changes nothing, and Undo restores the
previous state.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Follow [PR #79839](https://github.com/WordPress/gutenberg/pull/79839)
for more details.
## **Media**
### **Client-side media processing**
When you upload an image in the editor, your browser now decodes, resizes, and encodes
all sub-sizes locally (via **wasm-vips**) before sending them to the server — with
support for **AVIF, WebP, HEIC, UltraHDR, JPEG XL**, and **GIF→video** conversion.
Browsers and devices that can’t handle it silently fall back to the existing server-
side path. (Chromium browsers only; requires more than 2 GB RAM and a decent connection.)
**📣 Dedicated Call for Testing post:** [Call for Testing: client-side media processing](https://make.wordpress.org/core/2026/06/04/call-for-testing-client-side-media-processing/)—
follow it for the full set of scenarios (baseline uploads, HEIC from iPhone, modern
output formats, Ultra HDR, JPEG XL, GIF→video, batch/concurrent uploads, resilience,
fallback paths, extensibility, and low-powered devices).
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/) (tag them `[Feature] Client
Side Media`). Follow [#76756](https://github.com/WordPress/gutenberg/issues/76756)
for more details.
### **Media Editor Modal**
A new **Media Editor Modal** replaces the old inline image cropper, bringing **cropping,
rotation, flip, zoom, and metadata editing** together in one streamlined place.
It opens from the **Crop** button on the **Image** block (and the Site Logo and
Cover blocks).
**📣 Dedicated Call for Testing post:** [Media Editor Modal: call for testing](https://make.wordpress.org/core/2026/05/21/media-editor-modal-call-for-testing/)—
follow it for the full set of flows (basic crop, details/metadata editing, preserving
custom block alt/caption values, keyboard, and touch gestures).
**Testing Steps**
1. In a post or page, add an **Image** block and upload or choose an image.
2. Click the **Crop** button in the block toolbar and confirm a **modal** opens (
instead of the old inline cropper).
3. Try a **freeform crop** — drag the handles — and confirm it works.
4. Try an **aspect-ratio crop** (a locked ratio) and confirm the crop constrains
to that ratio.
5. Use **Rotate** (and fine rotation / snap, where shown) and confirm the image rotates.
6. Use **Flip** and confirm the image flips.
7. Use the **Zoom** controls (**+** / **−**) and confirm the image zooms within the
crop frame.
8. Toggle the **crop handles** on/off, if available, and confirm they behave.
9. Edit the **metadata** (for example, alt text or caption) in the modal, then **
Save**.
10. Confirm the cropped/edited image is applied to the block and **persists** after
saving the post and reloading.
11. Repeat from the **Site Logo** and **Cover** block crop buttons to confirm the
modal opens there too.
**Expected:**
The Media Editor Modal opens from the Crop button, supports freeform and aspect-
ratio cropping, rotation, flip, zoom, and metadata editing, saves the result back
to the image, and is reachable from the Image, Site Logo, and Cover blocks.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Follow [#73771](https://github.com/WordPress/gutenberg/issues/73771)
for more details.
### **Smarter galleries**
Gallery blocks get smarter: a new **Dynamic Gallery** mode automatically displays
all the media **attached to the current post** — in the editor and on the frontend—
much like the classic gallery shortcodeShortcode A shortcode is a placeholder used
within a WordPress post, page, or widget to insert a form or function generated
by a plugin in a specific location on your site. did. You can also manage a post’s
attached images from a new **Attachments** categoryCategory The 'category' taxonomy
lets you group posts / content together that share a common bond. Categories are
pre-defined and broad ranging. in the media inserter.
**Testing Steps**
1. Create a post and **upload a few images** to it, so they become “attached” to
the post.
2. Add a **Gallery** block and, in its empty/placeholder state, choose the **Use
attached images** option (Dynamic Gallery).
3. Confirm the gallery automatically shows **all the images attached to the post**.
4. **Save** and confirm the same images appear on the **frontend**.
5. Open the block’s **Source** settings, change the **sort order**, and confirm the
images re-order accordingly.
6. **Convert the Dynamic Gallery to a static gallery** and confirm you can now add,
remove, or reorder individual images.
7. Open the **media inserter** (the **Media** tab in the inserter) and find the new**
Attachments** category.
8. Confirm it lists the images attached to the current post.
9. Use **Attach** to add an image and **Detach** to remove one, and confirm the Dynamic
Gallery updates to match.
**Expected:**
A Dynamic Gallery auto-displays all media attached to the post (editor and frontend),
respects the sort setting, and can be converted to a static gallery. The media inserter’s**
Attachments** category lists the post’s images and lets you attach/detach, which
the Dynamic Gallery then reflects.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Follow [issue #77117](https://github.com/WordPress/gutenberg/issues/77117)
for more details.
## **Dashboard**
### **Visual RevisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. improvements**
The **Visual Revisions** view (from 7.0) lets you compare and restore past revisions
visually, right in the editor. WordPress 7.1 polishes how **autosaves** fit into
it. The autosave notice’s **“View the autosave”** now opens the **visual revisions
view** (autosave selected, changes highlighted) instead of the classic screen, and**
restoring** the autosave **dismisses the notice** — it falls back to the classic
screen when visual revisions are off (e.g. classic metaMeta Meta is a term that
refers to the inside workings of a group. For us, this is the team that works on
internal WordPress sites like WordCamp Central and Make WordPress. boxes). The revisions**
timeline** also shows an **“Autosave” badge** on autosave rows — visually and for
screen readers — so they’re easy to tell apart from regular revisions.
**Testing Steps**
1. Edit a **published post**, change some content, and trigger a **server autosave**(
wait for it, or run wp.data.dispatch( ‘core/editor’ ).autosave() in the console).**
Reload** without saving.
2. On the autosave notice, click **“View the autosave”** and confirm the **visual
revisions view** opens with the autosave selected and its changes highlighted (
no page reload).
3. Click **Restore** and confirm the autosave content is applied and the **notice
disappears**.
4. On a post with visual revisions **disabled** (e.g. classic meta boxes), confirm**“
View the autosave”** falls back to the **classic revisions screen**.
5. Open a post with both **revisions and a recent autosave**, open the revisions screen,
and confirm the **autosave row** shows an **“Autosave” badge** (regular rows don’t),
announced to screen readers too.
**Expected: **
“View the autosave” opens the visual revisions view (falling back to the classic
screen when visual revisions are off) and restoring dismisses the notice; autosave
rows in the timeline are clearly labelled “Autosave” while regular revisions aren’t.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Follow [#79120](https://github.com/WordPress/gutenberg/issues/79120)(
[PR #79947](https://github.com/WordPress/gutenberg/pull/79947), [PR #79950](https://github.com/WordPress/gutenberg/pull/79950))
for more details.
### **Untitled posts show an excerptExcerpt An excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox. in the Posts list**
Posts and pages with **no title** used to show only **“(no title)”** in the list
table, making untitled items hard to tell apart. In **Compact view**, WordPress
7.1 now appends up to **15 words of the post’s trimmed excerpt** after “(no title)”—
so untitled posts are identifiable at a glance.
**Testing Steps**
1. Create a few **posts with no title** and different opening content (plain text,
blocks, an image). Go to **Posts → All Posts** in **Compact view**.
2. Confirm each untitled row shows **“(no title)”** followed by the first part of
its content (up to 15 words, ending in an ellipsis), in a **lighter weight** than
a normal title. A post whose content starts with only an image should show just“(
no title)”.
3. Add a post **with a title** and confirm **no excerpt is appended** — the feature
only applies to untitled posts.
4. Switch to **Extended view** and confirm the trimmed excerpt is **not** appended(
the full excerpt already shows on its own line there). Switch back to Compact and
confirm it returns.
5. Create an untitled **password-protected** post and confirm it shows **only “(no
title)”** — no excerpt.
6. Repeat on **Pages**; **trashTrash Trash in WordPress is like the Recycle Bin on
your PC or Trash in your Macintosh computer. Users with the proper permission level(
administrators and editors) have the ability to delete a post, page, and/or comments.
When you delete the item, it is moved to the trash folder where it will remain
for 30 days.** an untitled post and confirm the excerpt still shows next to “(no
title)” (the title isn’t linked in Trash, as expected).
7. Confirm the list still **sorts, searches, and paginates** correctly, and that **
Quick Edit / Bulk Edit** still work for untitled posts.
**Expected:** In Compact view, untitled posts and pages show “(no title)” plus a
trimmed excerpt; titled and password-protected posts don’t; Extended view, Trash,
sorting, and Quick/Bulk Edit all still behave correctly.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://core.trac.wordpress.org/). Follow [Trac #65022](https://core.trac.wordpress.org/ticket/65022)(
PR [#11553](https://core.trac.wordpress.org/ticket/11553)) for more details.
### **Re-parent a comment from the Edit Comment screen**
The **Edit Comment** screen now lets you change which comment a reply is **“In reply
to”** or set it to **None** to make it a top-level comment using a new dropdown
in the Save box. Previously this couldn’t be done from the admin at all.
**Testing Steps**
1. On a post with **threaded comments**, go to **wp-admin → Comments** and click **
Edit** on a reply.
2. In the Save box, click **Edit** next to **“In reply to:”** and pick a **different
comment** from the dropdown (the comment itself and its own replies are left out,
so you can’t create a loopLoop The Loop is PHP code used by WordPress to display
posts. Using The Loop, WordPress processes each post to be displayed on the current
page, and formats it according to how it matches specified criteria within The
Loop tags. Any HTML or PHP code in the Loop will be processed on each post. [https://codex.wordpress.org/The_Loop](https://codex.wordpress.org/The_Loop)).
3. Click **OK**, then **Update**.
4. View the post on the **frontend** and confirm the comment is now nested **under
the new parent**.
5. Edit it again, set **“In reply to:”** to **None**, **Update**, and confirm it appears
as a **top-level** comment.
**Expected:** You can change a comment’s parent (or clear it to top-level) from
the Edit Comment screen, and the new threading shows on the frontend.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://core.trac.wordpress.org/). Follow [Trac #65570](https://core.trac.wordpress.org/ticket/65570)(
PR [#12406](https://core.trac.wordpress.org/ticket/12406)) for more details.
## **Blocks**
### **Playlist block**
The **Playlist** block plays back a list of audio tracks with an interactive waveform
player and a track list. Add your audio files and play them right in the editor
and on the frontend, and customise the waveform and track list from the block settings.
It’s made up of **Playlist** → **Playlist track** (one per track).
**Testing Steps**
1. Add a **Playlist** block and **upload a few audio files** (e.g. MP3s). Confirm
a track is added for each file, with a waveform player and a track list.
2. Press **play** and confirm audio plays; click another track in the list and confirm
it switches. **Save** and view on the **frontend**, and confirm playback works
there too.
3. In the block settings, open the **Waveform** panel and switch the **Visualization
style** (Bars, Mirror, Line, Blocks, Dots, Seekbar). Confirm the waveform updates
in the editor and on the frontend.
4. Set a **waveform color** and a **waveform background color** (try the gradient
options too) and confirm they render in both the editor and the frontend.
5. Toggle the track-list options — **Show tracklist**, **Show images** (album-art
thumbnails), **Show artists**, **Show numbers**, and **Show track length** — and
confirm each shows or hides correctly.
6. Turn on **Show play button artwork** and confirm the track’s artwork appears inside
the play button.
7. Change the **font size** in the typography settings and confirm it applies to the
track list and the current track.
8. Set a **background color**, **padding/margin**, and **border** on the block and
confirm they apply in the editor and on the frontend.
**Expected:**
Audio plays back in the editor and on the frontend; the waveform’s visualization
style, colors, and background render correctly; the track-list toggles (tracklist,
images, artists, numbers, track length) and play-button artwork all work; and the
block’s color, spacing, border, and typography styling apply consistently across
editor and frontend.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Follow the PR [#80203](https://github.com/WordPress/gutenberg/pull/80203)
and the iteration issue [#77421](https://github.com/WordPress/gutenberg/issues/77421)
for more details.
### **Tabs block**
The **Tabs** block shows a row of clickable tab labels above a set of content panels—
click a tab to bring its panel into view. It’s made up of **Tabs** → **Tab List**(
the tab buttons) and **Tab Panels** → **Tab Panel** (one panel per tab). The labels
and panels stay **automatically synchronised**, so adding, removing, or reordering
a tab updates its matching panel too.
**
Testing Steps
1. Add a **Tabs** block and confirm it inserts a tab list with two tabs and two matching
panels. Then **add**, **remove**, and **reorder** a tab and confirm the corresponding
panel **syncs** each time.
2. Style the **Tab List** globally under **Styles → Blocks** and confirm the styles
apply to the tab button elements (the **block gap** is the exception). Override
the styles on a **single instance** and confirm only that one changes.
3. Change the **background color** and confirm the tab buttons stay legible — their
text and borders inherit the current text color.
4. Inspect the markup: confirm tabs and panels are linked by **generated IDs**, and
that a **manually-set panel ID** is respected.
5. **Save** and view on the **frontend**; confirm clicking a tab switches the visible
panel.
6. On the frontend, use **Tab** to focus the tabs and panels, **Left / Right arrows**
to move between tabs, and **Enter** to activate one. With a screen reader, confirm
the tab list’s aria-label (default **“Tabbed content”**) is announced.
**
Expected:
Tabs and panels stay synchronised, global Tab List styles apply to
the tab buttons (overridable per instance, block gap excepted), tabs and panels
are linked by correct IDs (custom IDs respected), and the block follows the W3CW3C
The World Wide Web Consortium (W3C) is an international community where Member organizations,
a full-time staff, and the public work together to develop Web standards.[https://www.w3.org/](https://www.w3.org/).
tabs pattern — focusable with Tab, navigable with arrows, activated with Enter,
and announced by screen readers.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Follow [PR #80163](https://github.com/WordPress/gutenberg/pull/80163)
and the tracking issue [#73230](https://github.com/WordPress/gutenberg/issues/73230)
for more details.
### **Background gradients now work alongside background images**
Background gradients and background images no longer conflict. The gradient used
to get silently overridden by the image; now they combine and display together.
This applies to the **Group**, **Verse**, **Accordion**, **Pullquote**, **Post Content**,
and **Quote** blocks.
**Testing Steps**
1. Add one of the supported blocks – for example, a Group block with some content
inside.
2. In Styles, set a background image on the block.
3. On the same block, also set a background gradient.
4. Confirm **both the image and the gradient show together** in the editor, with neither
cancelling the other out.
5. **Save** and view on the front end; confirm both render together.
6. Repeat on at least one other supported block (**Verse, Accordion, Pullquote, Post
Content,** or **Quote**) and try a couple of different gradient/image combinations.
**Expected:**
Each supported block – Group, Verse, Accordion, Pullquote, Post Content, and Quote–
can display a background image and a background gradient at the same time, in both
the editor and on the front end.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Follow [PR #75859](https://github.com/WordPress/gutenberg/pull/75859),
[#79391](https://github.com/WordPress/gutenberg/pull/79391), [#79840](https://github.com/WordPress/gutenberg/pull/79840),
[#79841](https://github.com/WordPress/gutenberg/pull/79841), [#79842](https://github.com/WordPress/gutenberg/pull/79842),
[#79843](https://github.com/WordPress/gutenberg/pull/79843) for more details.
### **Image block — “Mark as decorative” toggle**
The Image block has a new “Mark as decorative” toggle that hides an image from screen
readers. Use it for purely decorative images (backgrounds, flourishes) so assistive
technology skips them an improved experience for screen-reader users.
**Testing Steps**
1. Add an Image block and choose an image.
2. Open the block’s Settings sidebar and find the “Mark as decorative” toggle.
3. Turn it on.
4. Inspect the image’s markup and confirm it gets an empty alt (or role=”presentation”/
aria-hidden, depending on output) so screen readers ignore it.
5. View the post on the frontend and confirm the decorative markup is present there
too.
6. Turn the toggle off again, add meaningful alt text, and confirm the image is announced
to screen readers once more.
**Expected:**
With the toggle on, the image is hidden from screen readers (empty/presentation
alt); with it off and alt text set, the image is announced normally.
**Testing Instructions:**
If you encounter any issues or unexpected behaviour while testing, please log them
[here](https://github.com/WordPress/gutenberg/issues/). Follow [PR #78064](https://github.com/WordPress/gutenberg/pull/78064)
for more details.
### **Editable blocks inside the Custom HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites. block**
The Custom HTML block can now keep editable blocks inside an otherwise static HTML
structure (powered by a new innerContent block support). This is ideal for AI-generated
or hand-built markup, where most of the HTML stays as-is but you mark just some
parts a paragraph, an image — as editable. The editable inner blocks sit at their
exact position in your markup but are locked: they can’t be moved, removed, or inserted,
and they offer no alignment controls.
You add an editable block by writing its block
delimiter inside the Custom HTML’s code, for example `…`.
**Testing Steps**
1. Add a Custom HTML block to a post or page, then open its Edit HTML modal.
2. Paste this code — it has a Paragraph block delimited inside static HTML — and click
Update:` Static heading
Editable
paragraph