The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
The RadioGroup component has been deprecated. To be consistent with the current WordPress design system, use RadioControl or ToggleGroupControl instead.
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 UIUIUser 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.
The ButtonGroup component has been deprecated, as it can easily lead to accessibilityAccessibilityAccessibility (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.
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.
Modal: Buttons in headerActions should use “compact” size
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.
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.
WordPress 6.8 brings a range of smaller yet meaningful updates to the blockBlockBlock 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 filterFilterFilters 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 iframeiframeiFrame 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 UIUIUser interface consistency moving forward. This post highlights these miscellaneous updates that don’t warrant individual dev notesdev noteEach 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.
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;
} );
Consistent Class Application for Navigation Block Menu Items
The Navigation block’s handling of the current-menu-ancestorCSSCSSCascading 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 JavaScriptJavaScriptJavaScript 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.
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 GutenbergGutenbergThe 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/pluginPluginA 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.
Block registration: Normalize blockType.parent to an array
The block registration APIAPIAn 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`.
The LinkControl component, which has been in an experimental state for several years, is being stabilized in WordPress 6.8. 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:
WordPress 6.8 introduces a new function wp_register_block_types_from_metadata_collection(), which allows plugins to register multiple blockBlockBlock 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.
To recap the relevant functionality added in WordPress 6.7:
Plugins can now optionally register a PHPPHPThe 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 CoreCoreCore 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.jsonJSONJSON, 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 pluginPluginA 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 JavaScriptJavaScriptJavaScript 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:
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.
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 CodeLines 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:
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:
TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.ticketticketCreated for both bug reports and feature development on the bug tracker.#62267
WordPress 6.8 comes with a few new best practices and requirements in the Interactivity APIAPIAn 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 reactReactReact 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 enhancementenhancementEnhancements 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-pluginPluginA 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 HTMLHTMLHyperText 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;
},
},
} );
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:
This improvement streamlines logic and improves developer experience.
Summary and further reading
Please refer to the following links for further reading:
GutenbergGutenbergThe 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.
TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.ticketticketCreated for both bug reports and feature development on the bug tracker.#62582 for support of the .length property.
WordPress 6.8 is set to be released on April 15th, 2025. This release continues refining foundational features introduced in previous versions, focusing on improving data views, query loops, and blockBlockBlock 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. interactions. It introduces a more streamlined design experience with a “Zoom Out” editing approach, expanded style controls, and enhanced typography options. Additionally, new “Write” and “Design” modes provide users with greater flexibility when editing content. APIAPIAn 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. developments, including the Block HooksHooksIn 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 Block Bindings APIs, aim to enhance extensibility, while speculative loading integration and performance optimizations seek to improve site speed. AccessibilityAccessibilityAccessibility (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 and ongoing support for PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 8.x ensure WordPress remains user-friendly and forward-compatible.
As always, what’s shared here is being actively pursued, but doesn’t necessarily mean each will make it into the final release of WordPress 6.8.
For a more detailed look at the work related to the block editor in WordPress 6.8, please refer to the 6.8 release cycle page and review the currently open Iteration issues. These Iteration issues reflect actively scoped work targeted for this release. Additionally, to gain insight into ongoing developments and future enhancements, you can explore the discussions and updates shared in the latest Gutenberg pull requests and tracking issues.
Design Improvements
The design focus will be on polish and fix, clearing ‘needs design feedback‘ issues.
The Style Book provides a comprehensive overview of your site’s colors, typography, and block styles in an organized layout. Each block example and style group is labeled, making it easy to preview and understand your theme’s current design settings. For classic themes that support the Style Book, site patterns have been relocated to Appearance > Design > Patterns, consolidating all design-related functionality from the Site Editor into one place. Previously, patterns were listed under Appearance > Patterns.
In zoom-out mode, users can now apply different section styles and designs directly from the toolbar, cycling through them and inspecting them in the context of the rest of the page. This enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. streamlines the decision-making and production process (#67140).
Another user experience improvement can be found in the list of fonts: Each font family is now previewed in the font picker dropdown and gives users a better indication as to what the font will look like (#67118).
The outcome of the Image manipulation methods are now better communicated in the block editor. The success notices are now displayed at the bottom of the editor. The notices also come with a handy Undo link to revert to the original if necessary (#67314, #67312).
Block supports: Show selected item in font family select control. (#68254)
Fix: Ensure consistency in editor tools for navigation buttons and delete options. (#67253)
Global Styles: Fix handling of booleans when stabilizing block supports. (#67552)
Support for Speculative Loading
Building upon the success of the Speculative Loading plugin, which has over 40,000 active installations, WordPress 6.8 plans to integrate speculative loading into coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. This feature utilizes the Speculation Rules API to prefetch URLs dynamically based on user interaction, aiming to improve performance metrics like Largest Contentful Paint (LCP). The current proposal has default configuration employing conservative prefetching to ensure safety and compatibility, but feedback is requested on this. Developers will have access to filters for customization, allowing adjustments to the speculative loading behavior as needed (#62503).
Polishing the Query LoopLoopThe 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.
By polishing the query loop we are focusing on enhancements like filterFilterFilters 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. by year, pagination, fetching results by adding offset, block spacing improvements, Sticky post not working when query type is default in editor, query loop depth set etc.
(This data comes from WordPress 6.8 Editorial Tasks and GutenbergGutenbergThe 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/ releases from 19.4 to 20.2.)
Working on fixing and enhancing List layouts, grid layouts, text truncation, padding and spacing in grid and list.
Zoom out to compose with patterns
With patterns getting more feature-rich and pervasive. This effort aims to provide a new, high-level approach to building and interacting with your site, with several key features in development:
Improvements to UXUXUser experience for dragging patterns (e.g. Hide Zoom Out Inserters when dragging into canvas).
UX improvement on Zoom Out (e.g. Rely on Zoom level instead of Zoom Out, Zoom Out shortcut on Windows, Add Keyboard shortcut in editor, Move default background to the iframeiframeiFrame 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. component, Zoom animation scrollbar fix)
Interactivity API (Not on track for WordPress 6.8)
In WordPress 6.7, work focused on important improvements to enhance the stability and simplicity of the Interactivity API internals, the introduction of new APIs like getServerState/getServerContext and wp_interactivity_get_element, improvements to the types, and progress on the Gallery block lightbox and Query block’s Instant Search.
In WordPress 6.8, the primary focus will be on:
Enhancing client-side navigation, advancing full page client-side navigation while addressing and improving the limitations of region-based client-side navigation.
Finishing the lightbox of the Gallery Block and the Instant Search functionality for the Query and Search Blocks.
Work is also continuing to improve the documentation. Follow this tracking issue for more information.
Support length property on strings and arrays on the server
Interactivity API directives support invalidinvalidA 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. data attribute characters on the server
Support for marking store actions that require synchronous event access (#68097)
The Block Hooks API is an extensibility mechanism that allows you to dynamically insert blocks into block themes. In WordPress 6.8, work will continue on improvements of Block Hooks.
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. API
HTML API enhancements will be focused on HTML process speed improvements and new features like introducing safe composable HTML templating, Inner and outer HTML support.
Various security-related enhancements are planned for WordPress 6.8, the most significant of which is the switch to using bcrypt for password hashing. This includes improvements to the algorithm that’s used for storing application passwords and security keys. A dedicated post will be published soon on make/core covering these changes in detail.
Additional performance improvements
A variety of initiatives are also focused on improved loading times like Lazy load post metaMetaMeta 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., Lazy load user capabilities in wp_user object, ORDER by RAND() speed improvements, cache the result of get_uploaded_header_images(), Improve cache generation in WP_Query class, and Cache duplicate calls to WP_Theme_JSON::sanitize. In preparation for the WordPress 6.8 release, several key performance improvements have been implemented in the block editor and collectively contribute to a more responsive and efficient editing experience.
Navigation Block Optimization: Addressed performance issues in the site editor when handling navigation blocks with multiple submenu items, enhancing responsiveness during template editing (#68875).
Selector Efficiency Enhancements: Improved the isBlockVisibleInTheInserter selector to prevent unnecessary computations, resulting in a more efficient block editor experience (#68898).
StyleBook Resizing Improvement: Resolved issues causing unsmooth resizing in the StyleBook for classic themes, leading to a more fluid user experience (#68978).
Event Handling Optimization: Introduced the withSyncEvent action wrapper utility to streamline event handling, reducing potential performance bottlenecks (#68097).
Inserter Selector Optimization: Implemented changes to avoid unbounded requests in inserter selectors, enhancing the efficiency of block retrieval processes (#66817).
Review usage of target=”_blank” in the adminadmin(and super admin)
Title attributes galore. They serve no useful purpose.
Submit buttons on form fields in the Add Media panel
Semantic elements for non-link links
Enhancement: Add a wrong password message on password protected posts
Code Editor: Linter (HTMLHint) should show error if checkbox doesn’t have associated <label>
Media uploader does not restrict file upload `accepts` parameters based on current context
Twenty Twenty: with horizontal menu, submenu should be dismissible
Add prefixes to all admin notices (Warning, Error, Success, Info)
Improve the admin notices accessibility
Fix and improve arranging metaboxes
Add a mechanism for accessible tooltips in core
Twenty Twenty: Menu + Search can cause a scroll jump on close
Excess text read with errors in Media Library
The WordPress core password reset needs to pre-populate the username to meet WCAGWCAGWCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/. 2.2
Validation of custom links in admin menu not accessible
Simplify add_new_item labels for core post types
Update the screen-reader-text CSSCSSCascading Style Sheets. class and its local implementations
Missing “submit” button – bad accessibility
Bring in lighter background for admin
Add padding and color changes to buttons and inputs
Change font weight of settings and other similar labels
Adjust background alternate row on post and page tables
core/site-title block adds aria-current to the blogblog(versus network, site) page when it is not the front page
get_custom_logo does not apply the aria-current attribute in all cases
Improve HTML semantics in Site Health Info tables
Consider removing title attributes from Classic Editor scripts
If you have something you’re working on that you don’t see reflected in this post, please share a comment below so we can all be aware! If you’re reading this and want to help, a great place to start is by looking through each issue associated with each area or by diving into the Polish board where a curated set of issues are in place that anyone can jump in on.
The live meeting will focus on the discussion for upcoming releases, and have an open floor section.
Additional items will be referred to in the various curated agenda sections below. If you have ticketticketCreated for both bug reports and feature development on the bug tracker. requests for help, please continue to post details in the comments section at the end of this agenda.
Announcements 📢
WordPress 6.8 | BetaBetaA 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. 3 is now available 🥳
The Beta 3 release of WordPress 6.8 is now available! A heartfelt thank you to everyone who joined the Release Party. We appreciate your testing and feedback.
Help Test 6.8 Beta version 🧪
The Test-Team has written two helpful guides for people interested in testing:
Next GutenbergGutenbergThe 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/ version: 20.5
Gutenberg 20.5 is scheduled for release on Wednesday, March 19th. This will be the first version of Gutenberg to be merged into WordPress 6.9.
Release Candidaterelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1 of 6.8: March 25th
The Release Candidate 1 release of WordPress 6.8 will be available on Tuesday, March 25th.
A detailed overview of the release schedule for WordPress 6.8 can be found here. The article also includes information about the individuals assigned to each release party.
Next major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.: 6.8
The discussion section of the agenda is to provide a place to discuss important topics affecting the upcoming release or larger initiatives that impact the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Team. To nominate a topic for discussion, please leave a comment on this agenda with a summary of the topic, any relevant links that will help people get context for the discussion, and what kind of feedback you are looking for from others participating in the discussion.
Release Support Needed
Assistance with drafting, reviewing, and publishing developer notes Assistance is requested for the drafting, review, and final publication of the developer notes.
Field GuideField guideThe field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. draft coming Thursday, please be ready for review The Field Guide draft will be available on Thursday. Please be prepared to review it promptly.
Review of the “About” page and potential issues The “About” page should be reviewed to identify any potential issues in the text or content. See more here: #63025
Reminder of the string freeze next week before RCrelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1 Please remember that the string freeze will take place next week before the release of RC 1.
Assistance with reviewing the email to PluginPluginA 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 Authors about major changes Assistance is needed to review the email to be sent to Plugin Authors, informing them of the key changes.
Critical Issues Before RC 1
Discussion of critical issues before RC 1 It’s suggested to discuss any critical or new issues before the release of RC 1 to ensure all problems are addressed in time.
Open floor 💬
Any topic can be raised for discussion in the comments, as well as requests for assistance on tickets. Tickets in the milestone for the next major or maintenance release will be prioritized.
Please include details of tickets / PRs and the links in the comments, and indicate whether you intend to be available during the meeting for discussion or will be async.
Below you find a table that lists all coreCoreCore 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 blockBlockBlock 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.
AvatarAvatarAn 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.
✅
–
✅
✅
–
✅
Button
✅
✅
✅
✅
–
✅
–
✅
✅
Buttons
✅
✅
✅
✅
✅
✅
✅
–
✅
Calendar
✅
✅
✅
–
–
–
–
Categories
✅
✅
☑️new
✅
✅
–
–
Code
✅
✅
✅
✅
✅
–
–
Column
✅
✅
✅
✅
✅
✅
–
✅
Columns
✅
✅
✅
✅
✅
✅
✅
–
✅
Comment Author Avatar
–
✅
✅
✅
–
–
Comment Author Name
✅
✅
✅
✅
–
✅
–
Comment Content
✅
✅
✅
✅
–
✅
–
Comment Date
✅
✅
✅
✅
–
–
Comment Edit Link
✅
✅
✅
✅
–
–
Comment Reply Link
✅
✅
✅
✅
–
–
Comment Template
✅
✅
–
✅
–
–
–
Comments
✅
✅
✅
✅
✅
–
Comments Pagination
✅
✅
✅
–
–
✅
–
Comments Pagination Next
✅
✅
–
–
–
✅
–
Comments Pagination Numbers
✅
✅
–
–
–
✅
–
Comments Pagination Previous
✅
✅
–
–
–
✅
–
Comments Title
✅
✅
✅
✅
✅
–
✅
–
Cover
✅
✅
✅
✅
✅
–
✅
✅
Details
✅
✅
✅
✅
✅
✅
Embed
✅
–
✅
–
–
–
File
✅
–
✅
✅
✅
–
✅
–
Footnotes
✅
✅
✅
✅
Gallery
✅
✅
✅
✅
✅
✅
–
Group
✅
✅
✅
✅
✅
✅
✅
–
✅
✅
Heading
✅
✅
✅
✅
✅
–
–
⭐️
Home Link – Navigation
✅
–
–
–
–
–
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.
–
–
–
–
–
–
Image
✅
–
✅
✅
–
✅
✅
✅
Latest Comments
✅
✅
✅
✅
✅
–
–
Latest Posts
✅
✅
✅
–
☑️new
–
✅
List
✅
✅
✅
✅
–
–
List Item
✅
–
✅
✅
–
–
Login/logout
–
–
–
–
–
–
Media & Text
✅
✅
✅
✅
✅
–
✅
–
More (Read More)
–
–
–
–
–
–
Navigation
✅
–
✅
–
✅
–
Navigation Link
✅
–
–
–
–
–
Navigation Submenu
–
–
–
–
–
–
Next Page (Page Break)
–
–
–
–
–
–
Page List
✅
☑️new
☑️new
☑️new
–
–
Paragraph
✅
✅
✅
✅
–
✅
–
✅
Post Author
✅
✅
✅
✅
–
✅
–
Post Author Biography
✅
✅
✅
✅
–
✅
–
Post Author Name
✅
✅
✅
✅
–
✅
–
Post Comments Count
✅
✅
✅
–
–
✅
–
Post Comments Form
✅
✅
✅
✅
–
✅
Post Comments Link
✅
✅
✅
–
–
✅
Post Content
✅
✅
✅
✅
☑️new
✅
✅
✅
Post Date
✅
✅
✅
✅
–
✅
–
Post ExcerptExcerptAn 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.
✅
✅
✅
✅
–
✅
–
Post Featured ImageFeatured imageA 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.
Over 12 years after #23311 was reported, WordPress 6.8 now properly localizes any user-visible PHPMailer error messages. To achieve this, a new WP_PHPMailer class extending PHPMailer was introduced to leverage the WordPress i18ni18nInternationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. system with PHPMailer. Note that developers don’t typically interact with this class directly outside of wp_mail() or the phpmailer_init action.
PluginPluginA 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 update emails in the adminadmin(and super admin)’s localeLocaleA locale is a combination of language and regional dialect. Usually locales correspond to countries, as is the case with Portuguese (Portugal) and Portuguese (Brazil). Other examples of locales include Canadian English and U.S. English.
This was reported and fixed in #62496. It’s a follow-up to the email localization change introduced in WordPress 6.7, where this instance was missed. Now, plugin update emails are correctly sent in the admin locale (if the admin email matches a user on the site).
Just-in-time translationtranslationThe process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. loading for plugins/themes not in the WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ directory
Back in version 4.6, WordPress introduced just-in-time translation loading for any plugin or theme that is hosted on WordPress.org. That meant plugins no longer had to call load_plugin_textdomain() or load_theme_textdomain().
With WordPress 6.8, this is now expanded to all other plugins and themes by looking at the text domain information provided by the plugin/theme. Extensions with a custom Text Domain and Domain PathheaderHeaderThe 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. no longer need to call load_plugin_textdomain() or load_theme_textdomain(). This reduces the risk of calling them too late, after some translation calls already happened, and generally makes it easier to properly internationalize a plugin or theme.
In short:
If your plugin/theme is hosted on WordPress.org and requires WordPress 4.6 or higher: you don’t need to use load_*_textdomain()
Else, if your plugin/theme provides the Text Domain and Domain Path headers and requires WordPress 6.8 or higher: you don’t need to use load_*_textdomain()
The live meeting will focus on the discussion for upcoming releases, and have an open floor section.
Additional items will be referred to in the various curated agenda sections below. If you have ticketticketCreated for both bug reports and feature development on the bug tracker. requests for help, please continue to post details in the comments section at the end of this agenda.
Announcements 📢
WordPress 6.8 | BetaBetaA 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. 2 is now available 🥳
The Beta 2 release of WordPress 6.8 is now available! A heartfelt thank you to everyone who joined the Release Party. We appreciate your testing and feedback.
Help Test 6.8 Beta version 🧪
The Test-Team has written two helpful guides for people interested in testing:
Thanks @ankit-k-gupt and @krupajnanda for your contribution!
Forthcoming releases 🚀
Next GutenbergGutenbergThe 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/ version: 20.5
Gutenberg 20.5 is scheduled for release on Wednesday, March 19th. This will be the first version of Gutenberg to be merged into WordPress 6.9.
Next Beta 3 of 6.8: March 18th
The Beta 3 release of WordPress 6.8 will be available on Tuesday, March 18th.
A detailed overview of the release schedule for WordPress 6.8 can be found here. The article also includes information about the individuals assigned to each release party.
Next major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.: 6.8
We have only two weeks until RCrelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1. Dev notes should be in progress. Please check @jeffpaul‘s message on Slack for details.
Discussions 🤔
The discussion section of the agenda is to provide a place to discuss important topics affecting the upcoming release or larger initiatives that impact the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Team. To nominate a topic for discussion, please leave a comment on this agenda with a summary of the topic, any relevant links that will help people get context for the discussion, and what kind of feedback you are looking for from others participating in the discussion.
Editor Updates 🔄
You can keep up to date with the major Editor features with the weekly updates, now on the blogblog(versus network, site)! Editor Weekly Updates: Mar 3 – Mar 7
Open floor 💬
Any topic can be raised for discussion in the comments, as well as requests for assistance on tickets. Tickets in the milestone for the next major or maintenance release will be prioritized.
Please include details of tickets / PRs and the links in the comments, and indicate whether you intend to be available during the meeting for discussion or will be async.
[Editor’s note: This survey was only answered by 3 people, only 2 of which were on the release squad. It’s useful as seeing three people’s distinct opinion, but not extrapolation.]
This post summarizes the feedback received from the WordPress 6.7 retrospective. Thank you to those who contributed their feedback via the retrospective survey and comments on the post. For ease of reading, feedback has been synthesized. Full feedback is available for review in the anonymized form responses and comments to the original post.
Please remember that the following feedback are suggestions to bear in mind for future releases rather than action items for implementation.
What would you keep?
Aligning Dev Chats to the time where Tech Release leads could attend was useful and should be considered in the future.
Release process.
What would you add?
Future release leads should be announced earlier—prior to the end of the previous release.
More robust testing around new features in conjunction with plugins.
What would you change, reduce, or remove?
The squad was announced too late.
The climate of contributing.
How did the collaboration feel?
This section included ways for one to indicate how much they agreed or disagreed with a statement around collaboration.
Would you like to be part of future release squads?
What is your feedback on the current release squad size?
Takeaways and next steps
One lead felt they and their co-leads were not appropriately respected by a sponsored non-lead and indicated their intent to not volunteer for another lead role without assurances that lead roles are to be respect by non-leads.
Another contributor indicated a general sense that release testing throughout the cycle was less that usual.
You must be logged in to post a comment.