Accessibility Improvements in WordPress 6.8

WordPress 6.8 introduces a comprehensive set of 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) improvements across WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 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. Editor, making the platform more inclusive and user-friendly. These updates span administration, customization, themes, editing workflows, and the block editor, ensuring a smoother experience for users relying on assistive technologies.

Core

In WordPress Core, improvements include 33 accessibility fixes across all bundled themes, completion of a long-term effort to remove title attributes in the adminadmin (and super admin) interface, and better navigation menuNavigation Menu A theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site. management. 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. and Administration areas have significant updates, from more descriptive labels, clearer screen reader feedback, and better motion preferences support.

Administration

Several accessibility enhancements to the admin interface make it easier for all users, including those relying on assistive technologies, to navigate and interact with the dashboard. These updates improve clarity, feedback mechanisms, and usability across key administrative areas.

Simplified ‘Add New’ Labels

The ‘Add New’ labels for core post types have been streamlined. For instance, ‘Add New Post’ is now ‘Add Post’, reducing verbosity and aligning with Gutenberg’s button labeling conventions (#61219).

Screen Reader Confirmation for Screen Options

When users adjust settings in the Screen Options panel, screen readers now announce confirmations of saved changes. This provides immediate feedback, enhancing the experience for visually impaired users (#62550).

Elimination of Empty Author Links

In list tables, entries without an assigned author used to display empty anchor tags. That caused usability issues for keyboard and screen reader users. Now, if no author is assigned, the field displays an em dash (—) with a screen reader-friendly ‘(no author)’ label, improving clarity and accessibility (#62913).

Removal of title Attributes

Lots of unnecessary and often redundant title attributes have been removed from the WordPress admin interface, making the interface easier to use for visually impaired users and more in line with best accessibility practices.

This change continues a broader effort started in WordPress 3.7 (#24766).

Customizer

In the Customizer, WordPress 6.8’s accessibility improvements add clarity, reduce unnecessary attributes, and make life easier for assistive technologyAssistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities 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 needed to accomplish such tasks. https://en.wikipedia.org/wiki/Assistive_technology users. They restore proper heading semantics, improve widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. area selection, and respect user motion preferences.

Restoring Heading Semantics in Customizer Navigation Menus

WordPress 6.8 removes the role="presentation" attribute from <h4> section headings in the Customizer’s navigation menus. This change restores proper heading semantics, making the Customizer interface easier to navigate for users relying on assistive technologies (#62215).

Displaying 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. Descriptions in Widget Area Selection

The Customizer’s widget area selection now displays sidebar descriptions directly below their names, replacing the previous title attribute tooltips. This adjustment makes sidebar information more accessible to all users, particularly those using assistive technologies (#62836).

Respecting Reduced Motion Preferences in the Customizer

The Customizer now respects users’ preferences to minimize non-essential motion, as indicated by the prefers-reduced-motion media query. This enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. reduces animations and transitions for users who have opted for reduced motion, providing a more comfortable experience (#62806).

Editing

Several accessibility improvements to the editor experience make it more intuitive and user-friendly for all users, including those relying on assistive technologies. These updates simplify interface elements, improve keyboard navigation, and remove redundant attributes for a more accessible editing workflow.

Conditional Display of ‘Disable the Visual Editor’ Option

The ‘Disable the visual editor when writing’ option in user profiles has changed. Now it only appears if it is currently enabled, allowing users who have previously disabled the visual editor to re-enable it. For users who have not disabled the visual editor, the option is hidden, simplifying the user interface and reducing potential confusion (#34681).​

Renaming the ‘Text’ Tab to ‘Code’

The ‘Text’ tab in the Classic Editor is now called ‘Code’. This change makes it clear to nontechnical users that the tab is for code editing. (#38061).

Removal of Redundant title Attributes in Classic Editor

WordPress 6.8 moves the title attributes used with placeholder images in the classic editor to the alt attribute. Where images previously did not differentiate between different placeholders, they have been replaced with unique images.  (#62861).

Ensuring Visibility of Screen Reader Shortcuts in Block Editor

Screen reader shortcuts are now consistently visible, so users with visual impairments can access necessary navigation aids regardless of screen size. This fixes an issue where the shortcuts were hidden in the block editor on smaller screens (#63084).

Miscellaneous

Beyond updates across core components, WordPress 6.8 adds several accessibility enhancements that refine various admin interfaces, semantic HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers., and content interactions for a more inclusive experience.

Improved Feedback for Password-Protected Posts

Users who enter an incorrect password on a password-protected post will now see an error message, improving feedback and reducing confusion (#37332).

Accessible Validation for Custom Menu Links

The validation process for custom links in the admin menu is now consistent and accessible, so invalidinvalid A resolution on the bug tracker (and generally common in software development, sometimes also notabug) that indicates the ticket is not a bug, is a support request, or is generally invalid. URLs trigger accessible feedback for sighted users and users of screen readers (#60969).

Updated screen-reader-text CSSCSS Cascading Style Sheets. Class

The screen-reader-text class and its local implementations have eliminated outdated clip and -webkit-clip properties to improve styling consistency. (#62238).

Fix for Comment Reply Form Escape Key Behavior

Pressing Escape to close the comment reply form no longer causes content loss (#62346).

Removal of Redundant title Attributes

6.8 removes the title attribute on the shortlink function (the_shortlink()), for cleaner markup and better compatibility with screen readers (#62838).

The title attributes in the calendar widget column headers are also gone, as are any redundant or unclear tooltips (#62860).

Improved HTML Semantics in Site Health Info Tables

The Site Health Info tables have better structured HTML, making it easier for assistive technologies to parse and read content (#62880).

Themes

Several accessibility enhancements have come to the Themes component, improving navigation, readability, and customization.

Theme Details Dialog Overlay

The Theme Details dialog previously obscured the admin sidebar sub-menu navigation, hindering accessibility. Thanks to this fix, the dialog no longer hides the sidebar, allowing seamless navigation (#41155).

“Skip to Content” Link Enhancement

The “Skip to content” link lacked a corresponding ID, reducing its effectiveness for keyboard navigation. Now the main content area has a unique ID, so users can bypass repetitive elements more efficiently (#62311).

Improved aria-current Management for Custom Logos

The logic to show that a linked logo pointed to the current page has improved, so users of screen readers get better information. (#62879)

Removal of Redundant Title Attributes

Title attributes in theme list tables, often redundant and confusing, are now gone. The result: a cleaner and more accessible interface (#62834).

Support for :focus-visible Pseudo-Selector in theme.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML.

To enhance focus styles, particularly for keyboard users, theme.json supports the :focus-visible pseudo-selector. That lets theme developers define focus styles apply only when an element receives focus via keyboard navigation (#62906).

Bundled Themes

WordPress 6.8 adds accessibility enhancements across multiple bundled themes that refine skip links, menu interactions, and accessibility attributes to enhance the experience for all users.

Skip Link Placement Adjustments

  • Twenty Ten: The skip link now appears earlier in the markup for better keyboard navigation (#14795).
  • Twenty Twelve, Thirteen, and Fourteen: Now skip links appear before navigation elements, ensuring a logical tab order (#62967, #62968, #62969).

ARIA Attribute Improvements in Menus

  • Twenty Twelve: The mobile menu button now includes an aria-expanded attribute to indicate its state (#62892).
  • Twenty Fifteen: Updates to ARIA attributes ensure the primary menu is properly labeled for assistive technologies (#62936).
  • Twenty Nineteen: Limits the scope of aria-haspopup and aria-expanded attributes only to menu items with submenus, reducing unnecessary attributes (#62896).
  • Twenty Twenty: The horizontal menu’s submenus are now dismissible, making it easier to close expanded menus (#49950).
  • Twenty Twenty-One: The primary menu now includes aria-controls attributes, ensuring proper interaction for screen reader users (#62973).

Improved Accessibility for Site Titles

Bundled themes now add accessibility attributes to the site title link, making it easier for assistive technologies to interpret site navigation (#62895).

Gutenberg

The Block Editor saw over 70 accessibility enhancements that enhance core blocks, global styles, popovers, tooltips, and the editor interface itself. Additionally, improvements to the DataViews component refine media selection, layout semantics, and interactive elements, ensuring a more accessible editing experience.

Blocks

WordPress 6.8 introduces significant accessibility enhancements to Gutenberg’s core blocks, improving usability, clarity, and assistive technology support. Updates include better labeling and terminology for the Query 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., Post URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, and Navigation blocks, ensuring clearer communication for all users. Focus management fixes include preventing focus loss in the Site Logo block and improving keyboard navigation for the Site Icon component. Refinements to ARIA attributes and tooltips across Image, Video, and Navigation blocks eliminate redundant elements and improve screen reader compatibility.

In short, the 6.8 block editor is the most accessible, intuitive, and inclusive it’s ever been:

  • Query Loop Block Enhancements: Made the display settings labels for the Query Loop block clearer to users (#65524).​
  • Post URL Accessibility: Made the terminology in the Post URL component more intuitive for all users (#63669).​
  • Radius Control Simplification: Removed unnecessary, confusing tooltip components from the radius control linked button (#66274).​
  • Featured ImageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. Alt Text: Added alt text and fallback options for featured images in the editor sidebar, ensuring better accessibility for screen readers (#66189).​
  • Link Preview Improvements: Made labeling of link previews more accessible, informative, and user-friendly (#60908).​
  • Site Icon Focus Fix: Addressed focus issues with the Site Icon component, ensuring consistent and expected behavior (#66952).​
  • Image Block ARIA Attributes: Added the aria-haspopup property to the Image block’s “More tools” menu items, improving screen reader interactions (#66815).​
  • Video Block Tooltip Removal: Eliminated unnecessary tooltips from the Video block’s text tracks button (#66716).​
  • Navigation Block ARIA Label: Fixed the ariaLabel block support in the Navigation block, ensuring accurate labeling for assistive technologies (#66943).​
  • Featured Image UIUI User interface Enhancement: Gave clearer user feedback for featured images when the image file cannot be retrieved (#66936).​
  • Video Track Editor Accessibility: Made the video track editor more accessible, navigable and usable for all users (#66832).​
  • Menu Selection Label Fix: Corrected the “Choose menu” label when a menu has been deleted to give users accurate information (#67009).​
  • Site Logo Focus Preservation: Prevented focus loss when updating media from the sidebar in the Site Logo component for a seamless editing experience (#68621).
  • Lightbox Feature Label Consistency: Fixed inconsistent labels for the Lightbox feature for uniform terminology across the editor and frontend (#68261).
  • Navigation Element Labeling: Replaced the term “navigation” with “menu” in navigation element labels, aligning with accessibility best practices (#68683).
  • Navigation Link Tooltip Removal: Removed non-interactive tooltips from Navigation Link blocks (#68628).

DataViews

In the latest updates to Gutenberg’s DataViews component, several accessibility improvements have been implemented to enhance user interaction and compliance with accessibility standards.

  • Badge Color Contrast Adjustment: Improved the color contrast of badges, for readability for users with visual impairments (#66360).
  • Focus Management Fixes: Fixed issues where focus was lost after removing or resetting all filters, for a consistent user experience (#67003).
  • Keyboard Interaction Enhancements: Enforced expected keyboard behavior, that pressing the spacebar triggers media buttons in grid view (#67791).
  • Accessible Naming for Media Buttons: Added accessible names to media buttons in page view grids, improving screen reader navigation (#67690).​
  • Semantic HTML Corrections: Removed inappropriate use of the grid role on ul elements in list layouts, following semantic HTML practices (​​#67849).
  • Visible Focus Indicators: Addressed the lack of visible focus styles on media items in grid view, so users can identify focused elements (#67789).
    Simplified Checkbox Labels: Removed extraneous labeling from checkboxes in data views, improving the interface for assistive technologies (#67868).

Miscellaneous

WordPress 6.8 introduces several accessibility improvements that improve editor responsiveness, modal dialogs, search inputs, button components, motion preferences, color contrast, and focus management.

Editor Resizability and Responsiveness

  • Resizable Editor with Keyboard Support – Users can now adjust the editor size using arrow keys, improving accessibility for keyboard users (#65546).
  • Responsive .screen-reader-text CSS – Updates ensure better readability and responsiveness for screen reader text across devices (#66145).

Modal Dialogs and Popovers

  • Improved Modal Dialog Accessibility – Enhancements to modal dialogs make them more accessible for screen reader users (#65941).
  • Popover Close Button Labeling – The close button in popovers now includes accessible labels, aiding assistive technology users (#66813).

Search Inputs and Global Styles

  • Consistent Search Input Labeling – Visible labels now match actual labels in search inputs (#65458).
  • Global Styles Menu Labeling – Adjustments prevent mismatches between visible labels and accessible names in global styles menus (#65124).

Snackbar Notices and Sidebar Navigation

  • Snackbar Notice Consistency – Fixes ensure uniform messaging and behavior across snackbar notices (#66405).
  • Sidebar Navigation Focus Visibility – The focus style in sidebar navigation is now fully visible, to aid keyboard navigation (#67817).

Button Components and Motion Preferences

  • Button Component Enhancements – Secondary variant buttons now include hover styles, and unnecessary tooltips have been removed (#67325, #68498).
  • Reduced Motion Handling – Standardized handling of reduced motion preferences ensures a better experience for users sensitive to motion (#68417, #68426, #68425, #68423, #68315).

Color Picker and Contrast Checker

  • Color Picker Accessibility – The color picker includes accessible labels for copy buttons (#67094).
  • Contrast Checker CSS Simplification – Unnecessary CSS properties have been removed from the contrast checker in the color hook (#68055).

Pattern Modal and Post Editor

  • Pattern Modal Focus Management – When the user inserts a pattern, the modal closes. Focus shifts to the newly inserted pattern (#68975).
  • Post Editor CSS Class Fixes – Corrections make theming and functionality consistent in the post editor’s iframe body (#68481).

Keyboard Navigation and Screen Reader Enhancements

  • Improved Speak Messages for Mode Switching – Screen readers now announce clearer messages when users switch editor modes (#66278).
  • Speak ‘Block Moved’ Notification for Keyboard Users – Users moving blocks with keyboard actions now receive an audible confirmation from screen readers (#64966).

UI Consistency and Focus Management

  • Fix Inconsistent Sidebar Close Button Sizes – Sidebar close buttons have consistent sizing across the interface (#66756).
  • Increase Modal Close Button Size – The close button in modals is bigger (#66792).
  • Improve ‘Last Modified’ 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. Button Accessibility – The Revisions button has better labeling for screen reader users (#66606).
  • Improve Accessibility of the Warning Component – Enhanced the Warning component to improve contrast, visibility, and screen reader support in the block editor (#67433).
  • Improve EntitiesSavedStates Modal Dialog Design & Labeling – Better visual clarity and accessibility of the EntitiesSavedStates modal (#67792).

Refinements in Block Patterns, Global Styles, and Layout Components

  • Fix Visual Title and Tooltip Inconsistencies in Block Patterns List – Fixed inconsistencies in visual titles and tooltips in block patterns (#64815).
  • Fix: Templates and Patterns Nesting Two Button Elements – Corrected nesting of multiple elements with the button role in templates and patterns, for better accessibility (#67801).
  • Fix Inserter CategoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. Tabs Unnecessary ARIA Label – Avoids redundant ARIA labels, so screen readers deliver clear navigation (#68160).
  • Add Missing List Role to Global Styles Block List – Delivers proper accessibility semantics in the Global Styles panel (#69027).
  • Preserve ARIA Label Value in Comment Delimiter Block Support – Makes screen readers correctly interpret comment delimiter sections (#69002).

Improvements to UI Components and Controls

  • Replace ButtonGroup Usage with ToggleGroupControl – Updated the ButtonGroup component to use ToggleGroupControl, for better usability and accessibility (#65346).
  • Fix Incorrect Usage of ItemGroup in the Image Block Filters Panel – Corrected nested elements and fixing accessibility issues in the filters panel (#67513, #67427).
  • Fix EntitiesSavedStates Panel Dialog Props – Refined dialog properties to improve screen reader support (#67351).
  • BoxControl ARIA Value Fix – The aria-value text attribute in BoxControl now delivers correct screen reader output (#68362).
  • BlockSwitcher Refactor – Improved layout in BlockSwitcher for better consistency (#67502).
  • CustomSelectControl Refactor – Updated CustomSelectControl to use Ariakit state management, ensuring better UI behavior (#67815).
  • Fix Tooltip Usage in Circular Option Picker – Corrected tooltip behavior for proper user interaction (#68602).

Enhancements to Style and Theme Components

  • Remove clip and -webkit-clip for Block Library Styles – Eliminated outdated clip and -webkit-clip properties (#66144, #66147).
  • Visual Refactor: Add Chevron Icon for Shadows in Global Styles – Improves visibility of shadow settings in the UI (#67720).
  • Shadows: Always Show Reset Button When Hover Is Not Supported – Ensures accessibility by keeping reset options visible for users without hover support (#68122).

Enhancements for Text and Font Controls

  • Update Description for ‘Contain Text Cursor Inside Block’ Preference – Explains cursor containment settings more clearly (#68132).
  • Font Size Picker: Remove ‘Custom’ Option in Dropdown – Simplifies the font size picker UI (#69038).
  • InputControl: Ensure Consistent Placeholder Color – Adjusted placeholder text styling for better consistency across the UI (#69334).
  • Cover Block: Fix Placeholder Color Options Keyboard Accessibility – Makes sure users can navigate placeholder color options with the keyboard (#68662).

Props to @jeffpaul, @marybaum, @benjamin_zekavica, @audrasjb for editing and review.

#6-8, #dev-notes, #dev-notes-6-8

Miscellaneous developer changes in WordPress 6.8

WordPress 6.8 delivers a broad set of developer-focused enhancements that improve extensibility, consistency, and modern standards across the platform. These updates include changes to shortcodes and media handling, expanded theme and 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. support, improved adminadmin (and super admin) validation and hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same., and fine-tuned control over post type registration and scheduling APIs. While these updates may not individually warrant their own developer note, they collectively represent important refinements for 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/ or can be cost-based plugin from a third-party, theme, and site developers working with WordPress under the hood. This post rounds up the miscellaneous changes worth knowing as you prepare your code for WordPress 6.8.


Table of contents


Removed option to disable the Visual Editor from user profile settings

The option to disable the visual editor was used to enforce the usage of the text interface in the classic editor. This setting was removed in #34681. The setting is removed conditionally; if you have it enabled, it will remain enabled and editable until it is disabled for a user.

The text editor will continue to be an option for all users. $user->rich_editing continues to be a valid user profile field, and the visual editor can be disabled by toggling that value to false.

Example code:

update_user_option( $user_id, 'rich_editing', 'false' );


Changed WP_Image_Editor::generate_filename( $suffix ) to allow empty string as a suffix

The previous  implementation of the WP_Image_Editor::generate_filename() method automatically appended a dimension suffix (e.g., -600×800) to the file name when no $suffix is provided, or when it is any “falsey” value (e.g., null or false). 

With the addition of image format switching like the switch from .heic to .jpg added in #62359, it became more apparent that there was a need to create copies of files without changing their file names.

In #62385, the behavior of this method was changed to accept an empty string as an intentional value for $suffix. The method will treat false or null as empty values where a dimension suffix should be generated; but will treat an empty string as the desired value for the suffix.

The default function value remains null

For extenders, if you are passing a value into the generate_filename() that could be an empty string, you should ensure that the variable type is null or bool to keep your method behavior unchanged.


In #60969, validation was added to the classic menu administration when adding custom links. This validation matches the existing validation used in 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. when adding custom links. It is a partial validation, checking for the following structures:

 * – http://example.com/

 * – //example.com

 * – /directory/

 * – ?query-param

 * – #target

 * – mailto:foo@example.com

If your use case requires content in a custom link’s href attribute that is not a generally valid URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org pattern, it may no longer be accepted.


New action hook in Import administration screen

A new action hook, after_importers, has been introduced to the Import administration screen (/wp-admin/import.php). This enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. allows developers to execute custom functions at the end of the importers page, aligning its extensibility with other administration screens like Tools. The hook is implemented as follows:

/**

* Fires at the end of the importers Administration screen.

 */

do_action( 'after_importers' );

This addition provides a standardized method for extending the importers page, facilitating the integration of custom functionalities. For more details, refer to #54419.


Update to wp_video_shortcode() HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. attributes

The wp_video_shortcode() function has been updated to generate valid HTML by properly handling boolean attributes. Previously, attributes like loop, autoplay, and muted were assigned a value of "1", leading to HTML validation errors. Now, these attributes are rendered without values, aligning with HTML specifications for boolean attributes. For instance, the loop attribute will now appear as loop instead of loop="1". This change ensures that video elements produced by the 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. are semantically correct and pass HTML validation. For more details, refer to #60178.


Update to wp_audio_shortcode() HTML Attributes

The wp_audio_shortcode() function has been updated to generate valid HTML by properly handling boolean attributes. Previously, attributes like loop, autoplay, and muted were assigned a value of "1", leading to HTML validation errors. Now, these attributes are rendered without values, aligning with HTML specifications for boolean attributes. For instance, the loop attribute will now appear as loop instead of loop="1". This change ensures that audio elements produced by the shortcode are semantically correct and pass HTML validation. For more details, refer to #61515.


New is_embeddable argument for register_post_type()

A new is_embeddable argument has been introduced to the register_post_type() function, allowing developers to control the embeddability of custom post types. By default, this parameter inherits its value from the public argument, ensuring that publicly accessible post types remain embeddable unless explicitly specified otherwise. This enhancement provides greater flexibility in managing content embedding, enabling developers to restrict embedding for specific post types as needed. For more details, refer to #35567.


Updates to body_class classes

Some new classes were introduced to the <body> tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.).

The classes wp-theme-<name> and wp-child-theme-<name (when the current theme is a child themeChild theme A Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/.) were added, where <name> represents the sanitized name of the active theme. Please note that these classes are added on both front-end and in the administration. For more information, refer to #19736.

The wp-singular class was added to the list of body classes when viewing a single post object. This class includes a wp- prefix to avoid conflicts with existing classes in themes or plugins. For more information, refer to #35164.


readme.html file is now noindex,nofollow

Because site owners likely don’t intend for the content of the readme.html file to be indexed, as it’s unrelated to the site content. A noindex,nofollow 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. tag was added to this file, to prevent it from being indexed. Polyglot teams that are translating this file manually are encouraged to update their version. For more information, refer to #63069.


Style Book availability for classic themes

The Style Book feature has been extended to support classic themes. This enhancement allows developers and users to preview and understand site colors, typography, and block styles within the context of their classic themes. To utilize the Style Book in a classic theme, ensure that the theme either:

  • Supports editor styles: Implement this by adding add_theme_support( 'editor-styles' ); in the theme’s functions.php file.
  • Includes a theme.json file: Incorporate a theme.json configuration file to define global styles and settings.

By adopting either of these methods, classic themes can leverage the Style Book’s capabilities, providing a more consistent and customizable editing experience.

For detailed guidance on integrating theme.json into classic themes, refer to the Global Settings & Styles (theme.json) – Block Editor Handbook. Additionally, the tutorial “Using theme.json with classic themes” offers practical insights and examples. These resources provide comprehensive information on enhancing classic themes with modern styling capabilities. For more information, refer to #62509.


Enabling Block Hooks for post content

The Block Hooks mechanism has been extended to apply to post content, in addition to its existing support for templates, template parts, patterns, and navigation menus. This enhancement allows developers to insert hooked blocks directly into posts and pages, offering greater flexibility in content customization.

Key considerations:

  • User expectations: Aligns block insertion capabilities with user expectations across various site components.
  • Content management: Introduces the ability to manage hooked blocks within individual posts and pages, enhancing content control.

This update provides developers with expanded tools for dynamic content placement, improving the customization capabilities. For more information, refer to #61074.


Block Hooks enabled for Synced Patterns

The Block Hooks feature has been extended to support synced patterns (i.e., core/block blocks). Previously, Block Hooks were applied to templates, template parts, patterns, navigation menus, and post content. This enhancement ensures consistent behavior across all these entities, allowing developers to insert hooked blocks into synced patterns seamlessly. This update provides greater flexibility and control over content customization within the WordPress ecosystem. For more information, refer to #62704.


Standardized behavior for render_block_context FilterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output.

The behavior of the render_block_context filter has been standardized to ensure consistent application across all block levels. Previously, this filter applied differently to top-level blocks compared to inner blocks, leading to inconsistencies in context propagation. Specifically, context provided via render_block_context was available to inner blocks when applied to top-level blocks, but not when applied to inner blocks.

This discrepancy has been addressed, ensuring that context supplied through the filter is uniformly available to all nested inner blocks, regardless of their position within the block hierarchy. For more information, refer to #62046.


Cron 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.: Introduce a new filter of the same name to wp_next_scheduled()

The wp_next_scheduled hook allows plugin developers to modify the timestamp of the next scheduled event for a given wp-cron job. The full event object, hook name and arguments are provided as additional arguments for this filter. Fore more information, refer to #52655.


HDR Image support for Imagick: new filter to control maximum bit depth of resized images

WordPress 6.8 introduces a new filter, image_max_bit_depth, that developers can use to control the maximum bit depth for resized images. The filter is also passed the original bit depth of the uploaded image. Note that this filter only works when the site’s hosting supports Imagick and coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is using the Imagick editor because the GD image editor does not support reading or controlling bit depth (#62285).

By default, the maximum depth matches the bit depth of the original uploaded image. Previously, the maximum bit depth was reduced to 8 for images with higher bit depths, so HDR images were always output with reduced bit depth. Starting in 6.8 HDR images will be output with the bit depth they are uploaded with (for example 12 bits). To enforce the previous behavior, developers can use the following code:

{{{
add_filter( ‘image_max_bit_depth’, function( $max_depth, $original_depth ) { 
	return ( 8 &lt; $original_depth ) ? 8 : $original_depth;
} ); 
}}}

Media: enable setting image output quality by image size

A new $size parameter was added to the wp_editor_set_quality filter. $size is an array with ‘width’ and ‘height’ keys. Developers can use this information to set image quality based on the image size, for example using a lower quality setting for small images (#54648).


Media: control uploading of unsupported media types

In 6.8, a new filter wp_prevent_unsupported_mime_type_uploads controls the behavior of the editor and media library when users upload an image type that the server does not support. By default, users will see an error message that “This image cannot be processed by the web server. Convert it to JPEG or PNG before uploading”. Developers can return false from the filter to enable uploading of these images; however, sub-sized images will not be created (#61167).


Props to @joedolson @audrasjb @webcommsat @joemcgill @benjamin_zekavica @peterwilsoncc @adamsilverstein @azaozz for input and review.

#6-8, #dev-notes, #dev-notes-6-8

Miscellaneous Block Editor Changes in WordPress 6.8

WordPress 6.8 brings a range of smaller yet meaningful updates to the 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. editor that enhance consistency, improve developer experience, and refine default behaviors.  These changes include refinements to the Navigation block’s class and markup handling, a new filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. for customizing visible post statuses, and updates to the behavior of the iframeiframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. and LinkControl components.  You will also notice stabilization of previously experimental features, improved block registration requirements, and changes that prepare the block editor for broader extensibility and UIUI User interface consistency moving forward.  This post highlights these miscellaneous updates that don’t warrant individual dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. but are still important to be aware of when building with or extending the block editor.

Table of Contents

Customizable Post Status Visibility in Navigation Block Links

The Navigation block now supports filtering of the post statuses of Posts shown in the Navigation on the front of the site. The new filter render_block_core_navigation_link_allowed_post_status defaults to publish but that list can be extended via the hook:

add_filter( 
    'render_block_core_navigation_link_allowed_post_status', 
    static function(array $post_status): array {
        $post_status[] = 'private'; // append statuses to the array of default statuses.
        return $post_status;
} );

For more information, visit #63181.

Consistent Class Application for Navigation Block Menu Items

The Navigation block’s handling of the current-menu-ancestor CSSCSS Cascading Style Sheets. class has been updated for improved consistency.  Previously, the current-menu-item class was applied to the <li> element of the current menu item, while the current-menu-ancestor class was applied to the <a> element of ancestor items.  This inconsistency posed challenges for developers aiming to style navigation menus uniformly.  With the changes introduced in #67169, both classes are now applied to their respective <li> elements, ensuring a consistent and predictable structure for styling purposes.

Key Change:

  • The current-menu-ancestor class is now applied to the <li> element of ancestor menu items, aligning its behavior with that of the current-menu-item class.

Implications for Developers:

  • This update standardizes the application of CSS classes within the Navigation block, simplifying the process of targeting and styling current and ancestor menu items.
  • Developers should review and adjust any custom styles or scripts that rely on the previous application of the current-menu-ancestor class to ensure compatibility with this change.

By implementing this adjustment, WordPress 6.8 enhances the consistency and reliability of its Navigation block, facilitating more intuitive and maintainable menu styling for developers.

Consistent Markup for Navigation Item Labels

The Navigation block has been updated to enhance consistency between navigation items and submenu items.  Previously, navigation items containing submenus lacked the <span class="wp-block-navigation-item__label"> wrapper around the navigation item text, which was present in standard navigation items.  This inconsistency made styling and scripting more challenging for developers.  With the changes introduced in #67198, both navigation items and submenu items now include this <span> wrapper, ensuring uniform markup structure across all navigation elements.

Key Changes:

  • Consistent Markup: All navigation items, including those with submenus, now wrap the item text within a <span class="wp-block-navigation-item__label"> element.

Implications for Developers:

  • Simplified Styling: The uniform use of the <span> wrapper allows for more straightforward and consistent CSS targeting of navigation item labels.
  • Enhanced Scripting: Developers can now reliably select and manipulate navigation item labels using 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/., regardless of whether the item contains a submenu.

By standardizing the markup structure of navigation items, WordPress 6.8 improves the developer experience when customizing and extending navigation menus.

Stabilize the isPreviewMode settings flag

The isPreviewMode settings flag is now stable, and using select( ‘core/block-editor’ ).getSettings().__unstableIsPreviewMode will now log a deprecation warning.

This public flag is commonly used to disable behaviors that cannot be used when rendering block or template previews. A good example is keyboard shortcuts.

For more information, visit #66149.

Iframed Content: Always enable for block themes

Continuing the effort to use iframed content in the post editor initiated in WP 5.9. Starting from WP 6.8, the editor will always render iframed content for block themes. This behavior was only enabled when using the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 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/ or can be cost-based plugin from a third-party.

Note: There are no changes for classic themes.

For more information, visit #66800 and #33346.

Block registration: Normalize blockType.parent to an array

The block registration 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. now enforces the parent setting to be an array. The editor will now display a warning if it’s a different type, such as a `string`.

For more information, visit #66250.

Stabilized LinkControl component

The LinkControl component, which has been in an experimental state for several years, is being stabilized in WordPress 6.9. This change affects plugin developers who are using the __experimentalLinkControl component in their custom blocks or extensions.

For backwards compatibility, the __experimentalLinkControl import will continue to work but will display deprecation warnings.

In addition, the following sub components have been deprecated:

  • __experimentalLinkControlSearchInput
  • __experimentalLinkControlSearchResults
  • __experimentalLinkControlSearchItem

For more information, visit #56384.

Changes to the Iframe Component

WordPress 6.8 changed the behavior of the scale prop on the Iframe component. This change may affect existing code.

Code using the following pattern may be affected:

import { __unstableIframe as Iframe } from '@wordpress/block-editor';

<Iframe scale="default" />

If you want to use autoscaling, change scale="default" to scale="auto-scaled".

For more information, visit #66280.

Co-authored by @jeffpaul

Props to @jeffpaul @mamaduka @fabiankaegy for review.

#6-8, #dev-notes, #dev-notes-6-8

Updates to user-interface components in WordPress 6.8

This post lists notable changes to the @wordpress/components package for the WordPress 6.8 release.

Table of Contents

RadioGroup: Log deprecation warning

The RadioGroup component has been deprecated. To be consistent with the current WordPress design system, use RadioControl or ToggleGroupControl instead.

For more information visit #68067.

The Navigation component (and all its subcomponents) are deprecated, planned for hard removal in WordPress 7.1. Use the Navigator component instead.

For more information, visit #68158.

SearchControl: Deprecated onClose prop

This prop was originally intended for adding a custom click handler to the suffix button to close the search field entirely, rather than just clear the input value.

The pattern of repurposing the search clear button as a search close button is no longer used in WordPress, and is no longer recommended as a UIUI User interface pattern since it can be confusing to users.

If you were relying on this prop, we recommend adding a separate close button to your UI.

For more information, visit #65988.

Soft deprecate the ButtonGroup component

The ButtonGroup component has been deprecated, as it can easily lead to 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) issues. For simpler adherence to accessibility best practices and to be consistent with the current WordPress design system, use ToggleGroupControl instead.

For more information, visit #65429.

Default 32px sizes are now deprecated

UI components across the editor (input fields, buttons, etc.) are currently rendering in a range of heights between 30px and 40px. To add consistency and visual polish to the editor’s UI, we started working on standardizing components toward a default height of 40px.

Continuing the standardization effort started in previous releases, for the WordPress 6.8 release, we will start logging deprecation warnings for the following components if they are not yet opting into the new default size:

  • BorderBoxControl
  • BorderControl
  • BoxControl
  • ComboboxControl
  • CustomSelectControl
  • DimensionControl
  • FontAppearanceControl
  • FontFamilyControl
  • FontSizePicker
  • FormFileUpload
  • FormTokenField
  • InputControl
  • LineHeightControl
  • NumberControl
  • Radio
  • RangeControl
  • SelectControl
  • TextControl
  • ToggleGroupControl
  • TreeSelect
  • UnitControl

To start opting into the new 40px default height, set the __next40pxDefaultSize prop.

<SelectControl
	options={ selectOptions }
	value={ selectValue }
	label={ __( 'Label' ) }
	onChange={ onSelectChange }
	__next40pxDefaultSize
/>

For more information, visit #65751.

The close button in the Modal component has been enlarged from the “small” button size (24px) to use the “compact” button size (32px).

If you are using the headerActions prop to inject buttons beside the close button, we recommend you also use the “compact” button size variant to match.

<Modal
	headerActions={ <Button icon={ fullscreen } label="Fullscreen mode" size="compact" /> }
/>

For more information, visit #66792.

Reducing experimental APIs

Stabilized BorderBoxControl

The __experimentalBorderBoxControl component can now be imported as BorderBoxControl.

The legacy __experimentalBorderBoxControl export is marked as deprecated.

For more information, visit #65586.

Stabilized BorderControl

The __experimentalBorderControl component can now be imported as BorderControl.

The legacy __experimentalBorderControl export is marked as deprecated.

For more information, visit #65475.

Stabilized BoxControl

The __experimentalBoxControl component can now be imported as BoxControl.

The legacy __experimentalBoxControl export is marked as deprecated.

For more information, visit #65469.

Stabilized Navigator

The legacy set of __experimentalNavigator* APIs is deprecated and should instead be imported as Navigator. All of the sub-components are also available via the Navigator namespace.

Moreover, the __experimentalNavigatorToParentButton component and the goToParent method available via the __experimentalUseNavigator hook are now deprecated, and they now behave identically to the __experimentalNavigatorBackButton and the goBack method.

To recap:

  • __experimentalNavigatorProvider => Navigator
  • __experimentalNavigatorScreen => Navigator.Screen
  • __experimentalNavigatorButton => Navigator.Button
  • __experimentalNavigatorBackButton => Navigator.BackButton
  • __experimentalNavigatorToParentButton => Navigator.BackButton
  • __experimentalUseNavigator => useNavigator

Co-authored by @mamaduka, @mciampini.

Props @mirka @jeffpaul @mamaduka for review.

#6-8, #dev-notes, #dev-notes-6-8

Interactivity API best practices in 6.8

WordPress 6.8 comes with a few new best practices and requirements in the Interactivity 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. that are part of a longer-term continuous-improvement effort. Some of the relevant changes in 6.8 are an intermediary step: They do not include these enhancements themselves, but they prepare the project to add them in a future release by adding two new deprecation warnings.

If you have been using the Interactivity API in your project, especially if you have been writing your own stores, please read on to learn how you can prepare your changes for the latest and future behavior of the API.

How to apply the latest best practices (and avoid deprecation warnings)

To help the Interactivity API speed up WordPress, the project is working towards running most store actions asynchronously by default, as a better foundation for achieving good INP (“Interaction to Next Paint”) performance. Right now, browsers invoke all synchronous Interactivity API event handlers as part of the same task—this means they stack up. This can make the user wait for longer than 50 milliseconds (also called a “long task”) for the site to reactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. to some interaction, like clicking a button.

Starting with 6.8, and going forward, the Interactivity API’s push towards asynchronous handlers as the default will make those long tasks less likely. The 6.8 release only prepares for the transition. In the following WordPress release, the API will automatically yield to the main thread in between handlers, so ideally there’s nothing to stack up, and nothing to make the user wait. (Also refer to async actions and the splitTask() function.)

This performance enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. also helps with cross-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/ or can be cost-based plugin from a third-party compatibility, as handlers for the same event may come from different plugins. The new requirements outlined below are an important step to prepare the Interactivity API for that future.

Wrap certain action callbacks in withSyncEvent()

Pay attention to any store action that is attached to an event listener (like data-wp-on--click) and accesses the event object: If the action callback uses any of the event properties or methods below, you need to wrap it in a newly added utility function called withSyncEvent():

  • Property: event.currentTarget
  • Method: event.preventDefault()
  • Method: event.stopImmediatePropagation()
  • Method: event.stopPropagation()

Starting in WordPress 6.8, if any action callback uses the above event properties or methods and is not wrapped in withSyncEvent(), that action callback will trigger a deprecation warning. For now, the logic will continue to work as before. But in a future WordPress release it will break if you do not migrate. For example, event.preventDefault() will not prevent the default action since the action will be asynchronous by default. As such, please make sure to resolve any deprecation warnings you see.

This correct (✅) code example illustrates how to use withSyncEvent():

import { store, withSyncEvent } from '@wordpress/interactivity';

store( 'myPlugin', {
	actions: {
		// `event.preventDefault()` requires synchronous event access.
		preventNavigation: withSyncEvent( ( event ) => {
			event.preventDefault();
		} ),

		// `event.target` does not require synchronous event access.
		logTarget: ( event ) => {
			console.log( 'event target => ', event.target );
		},

		// Not using `event` at all does not require synchronous event access.
		logSomething: () => {
			console.log( 'something' );
		},
	},
} );

This bad (❌) example will, going forward, emit a deprecation warning:

import { store } from '@wordpress/interactivity';

store( 'myPlugin', {
	actions: {
		// Missing `withSyncEvent()` around synchronous event access.
		preventNavigation: ( event ) => {
			event.preventDefault();
		},
	},
} );

Do not use actions to determine HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. attribute values

If you have been relying on Interactivity API store functions (like actions or callbacks) to determine HTML attribute values (e.g. via data-wp-bind--attr), please revise these attributes now. Instead, use global state, local context, or derived state. And please do not combine these function calls with directive logic like the ! operator.

Starting in WordPress 6.8, any directive using a store function in combination with the ! operator will emit a deprecation warning. The logic will continue to work as before for now, but in a future WordPress release it will break if you do not migrate. More broadly, if you are using store functions in directives that determine HTML attribute values, please migrate to using global state, local context, or derived state instead. More deprecation warnings around incorrect usage of store functions are expected soon, and eventually unmigrated code is going to break.

Please refer to the following correct (✅) code example to illustrate how to use derived state:

import { store } from '@wordpress/interactivity';

store( 'myPlugin', {
	state: {
		get isOpen() {
			const ctx = getContext();
			return !! ctx.open;
		},
	},
} );
<div
	data-wp-interactive="myPlugin"
	data-wp-bind--hidden="!state.isOpen"
>
	Content.
</div>

This bad (❌) example will, going forward, emit a deprecation warning:

import { store } from '@wordpress/interactivity';

store( 'myPlugin', {
	actions: {
		isOpen() {
			const ctx = getContext();
			return !! ctx.open;
		},
	},
} );
<div
	data-wp-interactive="myPlugin"
	data-wp-bind--hidden="!actions.isOpen"
>
	Content.
</div>

To provide context on why this new requirement is relevant: Using store functions for anything other than the “on”, “init”, or “watch” groups of directives has always been an anti-pattern. It is now being more formally discouraged, and will in the future be made impossible.

Support for the .length property in directives

An additional Interactivity API enhancement in WordPress 6.8 is support for the .length property on strings and numeric arrays in directives, ensuring consistency between server and client rendering.

Previously, the .length property was unavailable on the server, requiring workarounds. This update allows developers to use .length within all directives that reference global state, local context, or derived state, aligning behavior across environments.

This code example illustrates using the .length property:

<div data-wp-interactive="example">
  <div data-wp-bind--hidden="!state.list.length">
    <input type="range" min="1" data-wp-bind--max="state.list.length">
  </div>
  <div data-wp-bind--hidden="!state.string.length">
    <h1 data-wp-text="state.string"></h1>
  </div>
</div>

This improvement streamlines logic and improves developer experience.

Summary and further reading

Please refer to the following links for further reading:

  • GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ pull request #68097 for the withSyncEvent and new directive requirement enhancements
  • Gutenberg issues #64944 and #69552 with additional context on the long-term plans to run Interactivity API actions asynchronously by default.
  • Gutenberg issue #69269 with additional context on the long-term plans to more clearly separate directives that do something vs that determine a value.
  • TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #62582 for support of the .length property.
  • Documentation for understanding global state, local context, or derived state.

Co-authored by @gziolo.
Props to @westonruter, @jonsurrell, @webcommsat, @marybaum for review and proofreading.

#6-8, #dev-notes, #dev-notes-6-8, #interactivity-api, #performance

New filter should_load_block_assets_on_demand in 6.8

WordPress 6.8 introduces a new filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. should_load_block_assets_on_demand, which runs as part of a new function wp_should_load_block_assets_on_demand(). The filter complements the existing should_load_separate_core_block_assets filter by more clearly separating concerns of both filters.

Until now the should_load_separate_core_block_assets filter had two different purposes:

  1. Loading separate stylesheets for CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks, instead of a combined wp-block-library stylesheet (as the name indicates).
  2. Loading 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. scripts and stylesheets on demand only if the blocks are included in the page (not indicated by the name).

Now the new filter (and its surrounding function) handles only the second purpose. To maintain backward compatibility, the existing filter still works for both purposes. But going forward, please use it only for the first purpose.

Having the two separate filters for these purposes lets you control them separately. For example, as a site owner who wants to opt in to loading block scripts and stylesheets on demand, but keep loading the combined wp-block-library stylesheet with your classic theme, now you can:

add_filter( 'should_load_separate_core_block_assets', '__return_false' );
add_filter( 'should_load_block_assets_on_demand', '__return_true' );

Block themes now opt in by default to both features, similar to how they were already doing before via just the one filter.

Refer to TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #61965 for more context.

Props to @jeffpaul, @michelleames, @marybaum, @webcommsat for review and proofreading.

#6-8, #dev-notes, #dev-notes-6-8

Changes to the .screen-reader-text class in WordPress 6.8

The screen-reader-text CSSCSS Cascading Style Sheets. class is a small bit of CSS used in WordPress to hide text visually but still make it available to assistive technologies, screen readers, and any other software reading a page.

Given poor browser support for the clip-path property, the class has supported the deprecated clip property longer than it probably needed to. WordPress 4.9 did finally add support for clip-path, which now has wide support without prefixes across browsers.

WordPress 6.8 takes two more steps to modernize the class: it removes the clip property and the prefixed -webkit-clip-path property. Worth noting this change applies to the CSS class used in the WordPress adminadmin (and super admin) pages and across all bundled themes.

Here’s the CSS class from WordPress 4.9:

.screen-reader-text {
	border: 0;
	clip: rect(1px, 1px, 1px, 1px);
	-webkit-clip-path: inset(50%);
	clip-path: inset(50%);
	height: 1px;
	margin: -1px;
	overflow: hidden;
	padding: 0;
	position: absolute;
	width: 1px;
	word-wrap: normal !important;
}

And here’s the new CSS class for WordPress 6.8:

.screen-reader-text {
	border: 0;
	clip-path: inset(50%);
	height: 1px;
	margin: -1px;
	overflow: hidden;
	padding: 0;
	position: absolute;
	width: 1px;
	word-wrap: normal !important;
}

The only changes are the removal of the clip property and -webkit-clip-path.

In most cases this small change shouldn’t require any update to plugins and themes. But be aware of one case: when the screen-reader-text CSS class is used to dynamically reveal text. In a few cases, WordPress itself reveals some visually hidden text. For example, when there’s no 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/. support or on small screens, screen-reader-text gets reset to make the visually hidden text visible again:

.no-js .some-element .screen-reader-text {
	position: static;
	clip-path: none;
	width: auto;
	height: auto;
	margin: 0;
}

If you make an update to a similar CSS technique in your 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/ or can be cost-based plugin from a third-party or theme admin pages, don’t forget to remove the clip property from the associated reset CSS.

For more details, see the related changeset and Trac ticket.

Thanks to @marybaum and @audrasjb for proofreading.

#6-8, #dev-notes, #dev-notes-6-8

More efficient block type registration in 6.8

WordPress 6.8 introduces a new function wp_register_block_types_from_metadata_collection(), which allows plugins to register multiple 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. types with a single function call.

This function expands on the foundational capabilities of the wp_register_block_metadata_collection() function, which was introduced in WordPress 6.7 to improve performance.

Context

To recap the relevant functionality added in WordPress 6.7:

Plugins can now optionally register a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher “manifest” file, which includes all the metadata for their block types. For any block type that is being registered, WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. will now check whether such a manifest file is present covering the block type, and if so, it will use the data from the manifest file instead of reading and parsing the block type’s block.jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. file directly.

Since the blocks manifest file includes all the block type names, a logical next step after adding support for such a file is to make the requirement for individual block type registration calls obsolete. This is what the new  wp_register_block_types_from_metadata_collection() function implements.

Benefits

By using the new function, you no longer need to add individual register_block_type() calls for every block type that you include in your 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/ or can be cost-based plugin from a third-party. This improves developer experience, especially when using the latest block development best practices where the block.json file is used as the sole entrypoint for both PHP (server-side) and 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/. (client-side). Adding a new block type to an existing plugin is now possible by creating the block’s directory and working exclusively within that directory. You no longer need to remember to register the block type somewhere else in the PHP codebase of the surrounding plugin.

Example

Let’s say you have a plugin with 5 custom block types: “accordion”, “carousel”, “carousel-slide”, “dialog”, and “icon-button”. At the present, this means your plugin’s PHP code may look like this:

$block_types = array( 'accordion', 'carousel', 'carousel-slide', 'dialog', 'icon-button' );
foreach ( $block_types as $block_type ) {
	register_block_type( __DIR__ . "/build/{$block_type}" );
}

With WordPress 6.8, you can now use the wp_register_block_types_from_metadata_collection() function to eliminate the need for the list of block types in the PHP code so that all block types are recognized and registered automatically.

To do that, you need to generate a manifest file for your block types. You can use the build-blocks-manifest command from the @wordpress/scripts NPM package, which was also explained in the relevant WordPress 6.7 dev note. It can be easily integrated into your build process by changing the scripts in your package.json file as follows:

  • Change the “build” script from wp-scripts build to wp-scripts build && wp-scripts build-blocks-manifest.
  • Change the “start” script from wp-scripts start to wp-scripts start && wp-scripts build-blocks-manifest.

With the generated manifest in place, the PHP code above can be simplified to no longer require a hard-coded list of block types:

wp_register_block_types_from_metadata_collection(
	__DIR__ . '/build',
	__DIR__ . '/build/blocks-manifest.php'
);

Backward compatibility with older WordPress versions

As the wp_register_block_types_from_metadata_collection() function is only available in the latest WordPress 6.8 release, you may still want to support older WordPress versions. Fortunately, the function can be easily replaced by a few lines of codeLines of Code Lines of code. This is sometimes used as a poor metric for developer productivity, but can also have other uses., as long as you have a generated blocks manifest in place as described above.

Here is a code example that uses the respective best practices for WordPress 6.8, WordPress 6.7, and older versions:

if ( function_exists( 'wp_register_block_types_from_metadata_collection' ) ) {
	wp_register_block_types_from_metadata_collection( __DIR__ . '/build', __DIR__ . '/build/blocks-manifest.php' );
} else {
	if ( function_exists( 'wp_register_block_metadata_collection' ) ) {
		wp_register_block_metadata_collection( __DIR__ . '/build', __DIR__ . '/build/blocks-manifest.php' );
	}
	$manifest_data = require __DIR__ . '/build/blocks-manifest.php';
	foreach ( array_keys( $manifest_data ) as $block_type ) {
		register_block_type( __DIR__ . "/build/{$block_type}" );
	}
}

The @wordpress/create-block NPM package has been enhanced to use the new functions conditionally, using a similar code snippet as shown above.

Summary and further reading

The new wp_register_block_types_from_metadata_collection() function is a very simple but neat way to eliminate individual block type registration calls from your PHP code, allowing you to focus exclusively on working on the block types in your plugin without having to modify anything else in the plugin.

Please see the following links for further reading:

  • TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #62267
  • Relevant WordPress 6.7 dev note about the previous block type registration enhancements

Props to @gziolo, @stevenlinx for review and proofreading.

#6-8, #dev-notes, #dev-notes-6-8

Data: A helpful performance warning for developers in the ‘useSelect’ hook

useSelect is a ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. hook that lets you subscribe to WordPress data in the 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. editor. It checks if consumed data has changed and then rerenders your components accordingly.

Usually, things just work, and consumers don’t have to worry about unnecessary rerenders. However, sometimes data is directly manipulated in the mapSelect callback, which can mislead the useSelect hook into thinking that the data has changed when it has not.

Example:

export function ExampleWithWarning() {
	const { nameAndIds } = useSelect( function mapSelect( select ) {
		const authors = select( 'core' ).getUsers( {
			who: 'authors',
			context: 'view',
		} );

		return {
			// `Array.map` will return a new array for every call,
			// even if the data is the same.
			nameAndIds: authors?.map( ( { id, name } ) => ( { id, name } ) ),
		};
	}, [] );

	return <>{ /* Your rendering logic here */ }</>;
}

WordPress will now display a warning when SCRIPT_DEBUG is enabled to help consumers identify possible performance bottlenecks.

Example warning:

The useSelect hook returns different values when called with the same state and parameters. This can lead to unnecessary re-renders and performance issues if not fixed.

Non-equal value keys: nameAndIds

This warning can be fixed by requesting only the values needed to render a component or moving data manipulation outside the mapSelect callback. The actual solution can vary based on your code and logic.

Please refer to the fantastic article “How to work effectively with the useSelect hook” to learn more about best practices for using the useSelect hook.

Here’s how I would fix the example code from this post:

export function ExampleFixed() {
	const { nameAndIds } = useSelect( function mapSelect( select ) {
		const authors = select( 'core' ).getUsers( {
			who: 'authors',
			context: 'view',
			// Requests only fields that are needed.
			_fields: 'id,name',
		} );

		return {
			nameAndIds: authors,
		};
	}, [] );

	return <>{ /* Your rendering logic here */ }</>;
}

Props to @kirasong for the review.

#6-8, #dev-notes, #dev-notes-6-8, #editor

Roster of design tools per block (WordPress 6.8 edition)

Below you find a table that lists all coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks available in the inserter marks in the grid the feature they support in the 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. editor. It’s a basic lookup table that helps developers to find the information quickly.

While this post is released as part of 6.8, the content summarizes changes between 6.1 and 6.8. This is an updated of the 6.7 edition and provides a cumulative list of design supports added with the last six WordPress releases. The icon ☑️ indicates new in 6.8.

The features covered are:

  • Align
  • Typography,
  • Color,
  • Dimension,
  • Border,
  • Layout,
  • Gradient,
  • Duotone,
  • Shadow,
  • Background image
  • Pattern overrides / Block Bindings (PO/BB)

Work in progress

The issue Tracking: Addressing Design Tooling Consistency lists tracking issues for individual block supports.

Props to @audrasjb for review.

#6-8, #dev-notes, #dev-notes-6-8, #editor