WordPress 6.6 Source of Truth

I’m offering up the next edition of the Source of Truth for WordPress 6.6, set to launch July 16th, 2024. You can see all prior editions under this tag. As always, I’d recommend staying up to date on the dev notes as those are rolling out along with reviewing the Field Guide.

As a reminder, this is not meant to replace dev notes or the release specific field guides, which serve important roles and are separate efforts. I mainly see it as for folks close to the WordPress release itself and educating others than I see it as something broadly helpful for the average WordPress user. It’s a foundational resource but, it’s so long and detailed, it needs to be repackaged to be useful in each space. Feedback is welcomed for improvements for this version and for future versions as I consider how best to share this information.

Big thank you to everyone who helped in big and small ways.

Important Note/Guidelines

Please do not copy and paste what is in this document since this is public. This should be used to inspire your own content and to ensure that you have the best information about this release. If you do copy and paste, keep in mind that others might do the same, opening the door for some awkwardness around duplicated content out on the web.

If there are drastic changes, this document will be updated and it will be noted in a changelog.
Each item has been tagged using best guesses with different high level labels so that you can more readily see at a glance who is likely to be most impacted.
Each item has a high level description, visuals (if relevant), adoption strategy (if relevant), and key resources if you want to learn more.

Changelog

This will be kept up to date with any major changes.

June 27th: added more nuance under the Define multiple style options for sections of blocks, including all nested blocks section.

Overview

WordPress 6.6 is slated for release on July 16, 2024. Following the technical advancements of WordPress 6.5, this new version represents a major leap in design, improving both tooling and user experience.

Design tools take center stage, with grid layout support, section specific block styling, aspect ratio preset support, negative margins, and enhanced style variations available out of the box that allow you to mix & match color and typography options across different variations. Theme.json updates to v3 as part of changes made for theme authors to customize default font sizes and spacing, including disabling showing the default font sizes and spacing options if desired. These updates strengthen the foundation of a unified design system, offering more control and optionality.

From a user experience perspective, WordPress 6.6 introduces a unified publish flow, resulting from both technical and design efforts to create a seamless experience across editors. The start of admin redesign work initiated in 6.5 continues to evolve, with Data Views offering new layout options, a unified template part and pattern experience, and more accessible management sections. Classic themes now have a modern pattern management system, broadening exposure to WordPress’s future.

To make writing and creating with patterns and blocks easier, you can now bulk export patterns, navigate through patterns in the same category within specific contexts, swap templates and template parts in the inspector effortlessly, use starter patterns in the Site Editor, and see all blocks in the Inserter, not just the ones currently allowed.

Of note, this release includes Gutenberg 17.8 – 18.5.

Special Anne note: In terms of features, I am expecting the most feedback around exposing new pattern management to classic themes due to size of impact and the unified publish flow which includes changes to both the design and workflow of publishing content.

Table of Contents

Important links:

6.6 assets:

To view all assets in this document, please review this drive folder.

Priority Items for 6.6

Advancing the new Data Views in the Site Editor

As a reminder, Data Views refers to an improved and reusable UI for different screens in WordPress that deal with collections of things whether that’s templates, patterns, posts, media, and more. It’s being built with extensibility in mind and is a big part of phase 3, specifically the Admin Redesign efforts. This new UI will also power other aspects of phase 3 work, including aspects like workflow improvements for assigning folks to review posts or creating custom views to streamline processes.

Building on an initial launch in 6.5, the new views in the Site Editor continue to be refined and advanced. This includes work to bring the various management pages forward (manage all templates, manage all template parts, manage all pages) so those options are immediately seen when visiting the respective sections, reducing the number of steps to access important information. To streamline further, all Detail pages have been removed, eliminating an interstitial step and bringing you straight into editing.

For pages, a new side by side layout has been introduced as the default experience so one can see both a list of all pages and a preview of the currently selected page. For patterns, template part management was integrated into the current overall patterns section. Interspersed within all of these larger changes are smaller enhancements in functionality and feel, including improvements to keyboard navigation, new bulk edit actions, badges to communicate important information (like Posts page and Front page), performance improvements, and animation refinements.

Visuals: demo going through each section (template, patterns/template parts, pages) with simple bulk action items.
Adoption approach: Extensibility has been a key piece of this work baked into all of these efforts from the very beginning. For now, folks can bundle the dataviews styles in your plugin and you can even copy/paste these frames in the design library for quick mockups. Read through this full June 2024 update for more information.
Key Make Posts/GitHub/Trac Issue(s): Advancing site editor index views (59659)

Unifying editor experiences, including publish flow and slots

Common experiences between the two editors grows closer thanks to a technical push to share code and a design push to create a single, coherent experience across the post and site editor. This helps lay the groundwork for a future where there’s less separation between the two experiences and more of a seamless feel, including for extensibility. To get a sense of scale, at a code level in Core, this means nearly 7,000 lines of code no longer needs to be maintained.

The more noticeable and big pieces for users will be seen in a unified publish flow and a new singular “summary” inspector panel, which will also be reused within the site editor when you are bulk editing items. The publish flow also has an updated design with a new, more prominent display for key information like title, status, and featured image. This includes moving the “move to trash” option to behind the three dot menu next to the title of the post in the inspector. For the inspector, you can expect more consistency in the information that’s displayed regardless of what you’re interacting with from a pattern to a post.

Of note, some confusion was created when a duplicate post/page option was added. This is now only available when using the Gutenberg plugin and will not be in this release.

Slots available across editors

Thanks to the technical unification, various slots are now available between the post and site editors allowing plugin authors to use the same code to load their plugins regardless of the context of the editor. The following slots are now available under the wp.editor global variable (@wordpress/editor package or wp-editor script handle):

Going forward, contributors can also build editor features in a single place and have them available in both post and site editors, making it easier for folks to extend. For current plugins, this means you need to check how you’ve used these now universal slots to ensure your plugin’s extension points show up in the right places. In general, rather than targeting an editor, now you’ll want to target by post type (template, page, post). To help mitigate any unexpected usage of these slots, EditPost slots will only work on edit-post and EditSite slots will only work on edit-site.

Visuals: demo showing changes between 6.5.3 new post flow vs 6.6 new post flow, demo of integrated actions in pages and data view.
Adoption approach: Please check how your plugins are using slotfills to ensure they show up in the right editors and review this dev note. To help mitigate any unexpected usage of these slots, EditPost slots will only work on edit-post and EditSite slots will only work on edit-site.
Key Make Posts/GitHub/Trac Issue(s): Follow this iteration issue for aligning features and this tracking issue for the inspector controls for more information.

Create individual typography and color variations to level up design options [theme author] [end user]

Theme style variations allow you to change the look and feel of your site, all while using the same theme. To build on the design possibilities of a block theme with style variations, 6.6 adds the ability to target color or font only variations and offers them as presets, separate from overall style variations. Whereas style variations can change virtually anything, these new color and typography presets offer more contained changes, making it simple to offer broader color options or typography options out of the box. Theme authors will need to target this new option specifically by creating color or typography only variations without creating wholesale new style variations. For any style variations that only contain color and typography only changes, these will now automatically appear in this separate preset flow.

Note: changes were made to this feature after beta 1 in light of this discussion.

Visuals: demo selecting between offered color and typography presets

Adoption approach: block themers will need to create color or typography only variations that target only the specific respective properties. For an example, check out the Onyx variation in Twenty Twenty-Four which offers a color palette variation with no other changes. An issue is already open to add this as an option to the Create Block Theme plugin.
Key Make Posts/GitHub/Trac Issue(s): Color & Typography Variations for WP 6.6, Core Editor Improvement: Upgrade your designs

Override specific items in synced patterns while keeping stylistic control

Overrides in synced patterns allow you to ensure a synced layout and style across patterns while allowing each instance of the pattern to have customized content. This provides consistency in design across different pieces of content. Currently, the following blocks and block attributes can add overrides:

Heading block: content
Paragraph block: content
Button Block: text, url
Image Block: url, id, title, alt

For instance, consider a testimonial pattern. With this additional option, someone can insert this testimonial pattern into multiple posts, ensuring that the layout and styling remains the same. Meanwhile, the content, such as Name, Image, and Role, would be local to each instance allowing for individual customization. Additionally, folks would then be able to revisit and modify the design of the overall testimonial pattern without affecting the content in existing instances.

To set overrides, select a block within a synced pattern > open block settings > head to “Advanced” > select the option to “Enable Override”. From there, you’ll name a block and an override is set. If you choose to later turn off that override, you can do so using the same flow and selecting “Disable Override”. Keep in mind that when you do this, every instance that was customized of that block will be reverted back to what’s in the original synced pattern.

To make it more intuitive to work with overrides, the UX was carefully considered with the ability to see exactly which blocks are editable via a handy list in the block settings sidebar and a visual cue of a purple background that flashes when you click into a synced pattern that lights up each editable block.

Of note, synced pattern overrides are not available in themes (i.e. patterns stored in theme folders) and are intended to be user generated features as this follows the current inability for themes to provide synced patterns overall.

Visuals: demo showing how to create an override, edit it, disabling, and resetting to original.
Key Make Posts/GitHub/Trac Issue(s): Follow this iteration issue for more information, Adjust allow pattern overrides UX flow. (60769)

Improvements to Grid Layout

Grid is a new layout variation for the Group block that allows you to display the blocks within the group as a grid, offering new flexibility and ease of use with visual resizing options. There are two options for the Grid layout:

“Auto” generates the grid rows and columns automatically using a minimum width for each item.
“Manual” allows specifying the exact number of columns.

You can resize grid children either manually by adding a specific number of rows/columns by changing the “Column Span” and “Row Span” settings under Styles > Dimensions in the block inspector. You can also drag to resize visually by selecting each individual child block and using the drag handles to change items to your liking. As a bonus, to ensure an easy to use experience, the outlines of the visualizer will match the text color of the blocks. Of note, any block can use this new grid layout thanks to the supports key in block.json.

Visuals: simple demo of grid layout, design forward demo of grid layout, public YouTube video with grid layout included.
Adoption approach: any block can use this new grid layout thanks to the supports key in block.json. For the Group block, this functionality is added automatically.
Key Make Posts/GitHub/Trac Issue(s): Dev note on grid layout type, improvements to grid layout and subgrid support (57478), Core Editor Improvement: Upgrade your designs.

Bringing a modern experience for Pattern management to Classic Themes

Classic Themes now have access to the new Patterns experience that the Site Editor provides, offering a feature rich and modern experience of managing and creating patterns. As part of this work, the previously available Template Parts submenu will redirect to the Patterns section since Patterns and Template Parts are managed from the same place. For those using Classic Themes, this enables you to continue using what you know while giving a taste of what’s been built and what’s to come.

Visuals: demo of the Twenty Twenty theme with new patterns experience, public YouTube video going through changes.
Adoption approach: available automatically. No opting in required. To opt, please use this hook.

Key Make Posts/GitHub/Trac Issue(s): Follow this iteration issue for more information, Classic Theme: Expose new Patterns page and remove Template Parts submenu. (61080), redirect template parts menu to Patterns (61446)

Directly edit custom field values and view bindings with Custom Fields & Block Bindings API [plugin author] [developer]

The Block Bindings API launched in 6.5 allows you to bind dynamic data to block attributes, solving many use cases for custom blocks and powering other features, like overrides in synced patterns. At this stage, work focused on refactoring the existing editor implementation, adding a block bindings panel to the Inspector to better surface bindings, allowing the editing of connected sources directly from the block, and updating the save flow to show changes to edited custom field values. When combined, these changes provide a more intuitive experience for end users interacting with connected blocks. Future work will focus on making the APIs public and continuing to refine the UX.

Visuals: image of the bindings in the inspector, various demos of editing the value of a custom field

Adoption approach: If you haven’t yet checked out these APIs, it’s recommended to review the resources released for 6.5 including the Block Bindings API dev note and these paired part 1 and part 2 of dedicated developer blog posts.
Key Make Posts/GitHub/Trac Issue(s): Follow this iteration issue for more information.

Additional Items for 6.6

Add Rollbacks to auto-updates

Since WordPress 6.3, when an administrator is manually updating plugins, the plugin will not be reactivated if the update causes a PHP fatal error. During an auto-update, this reactivation check does not occur and the next time the site runs users will see the white screen of death (WSOD). To further protect websites and increase confidence in automatic plugin updates, 6.6 includes the ability to perform rollbacks when fatal errors occur during attempted plugin auto-updates by default. A loopback request is performed to the home page of the site and the plugin is rolled back to its backed up version if a fatal error is observed. This allows you to enjoy the ease of auto-updates with the safety of rollbacks if anything goes wrong.

Key Make Posts/GitHub/Trac Issue(s): To learn more, please review the merge proposal for this feature and the trac commit that landed this feature.

Design tooling upgrades [theme author]

Define multiple style options for sections of blocks, including all nested blocks [theme author] [enterprise]

6.6 introduces the ability for theme authors to define style options for sections of multiple blocks, including inner blocks, that then appear in the Inspector in the same format as a block style variation. With just a few clicks, folks using block themes that add this functionality can quickly change just a section of a page or template to predefined styles that a theme author provides, like a light or dark version of a section. Overall, block style variations can now be:

registered across multiple block types at the same time.
registered via two methods: theme.json partials or by passing a theme.json shaped object in the style’s data given to existing block style registration functions.
customized via the styles.variations property in theme.json or theme style variation. But there’s a strong chance this will be deprecated or changed in the future. If you use this method, expect future changes per this discussion and this warning.

For those in the agency and enterprise space, you can use this same functionality to control branding when building a block theme. Rather than applying styles to blocks in a one off way and having to update them individually in the future, you can make variations for Group and Columns blocks that folks can use. Later on, if any updates need to happen, just update those variations, whether in theme.json or straight in Styles, and the changes will take care of themselves across the site.

The aim is to provide more composability, less duplication, and an intuitive experience to style your site. Ultimately, this new option levels up the systematic approach to styling that the Site Editor and block themes seek to provide. This feature came together thanks to work to expand the block style variations API, providing a familiar pathway to implement for themers and to use for end users.

Changes to CSS Specificity

As part of this effort, please note that some decisions had to be made around CSS Specificity (full discussion here) with :root prefix being chosen as the way forward. It’s recommended that you review these changes to ensure they work with your setup, especially for custom blocks and block style variations. Please review this change in CSS specificity dev note for more information.

Visuals: demo of switching between different section styles then changing overall color variations, demo of applying a section style then editing the section style in Styles.
Adoption approach: There are a few ways folks are aiming to offer this functionality:

Programmatically via `wp_register_block_style()`
By standalone theme.json partials within a theme’s /styles directory alongside a theme’s style variations.
Via theme style variations defining block style variations under styles.blocks.variations. Of note, registering within theme style variation exists but there’s a strong chance this will be deprecated or changed in the future. If you use this method, expect future changes per this discussion and this warning.

For examples, please dive deep with this Developer Blog tutorial and read the dedicated dev note.
Key Make Posts/GitHub/Trac Issue(s): Follow this iteration issue for more information.

Use negative margins

You can now add negative margins directly in the editor for all blocks that support margin controls. Previously, this option was only available via theme.json. By being able to set negative margins, you can create some overlapping designs with ease. Of note, the negative values need to be manually entered to balance some UX considerations and add some guardrails, meaning they can’t be selected by dragging.

Visuals: manually inputting negative margins demo, design forward demo, public YouTube video with negative margins included.
Adoption approach: automatically available with blocks that support margin.
Key Make Posts/GitHub/Trac Issue(s): allow negative values for margin (60347), Core Editor Improvement: Upgrade your designs

Set site background images in the Site Editor

Background images have been extended to the Site Editor within Styles and theme.json so you can add your own custom background images, including animated gifs, to your site. This image is then displayed on every page of your site. An example might be a photo that stretches with the window size, or a repeating pattern background. Similar to when interacting with images in other places, the background can be set to repeat or be displayed as contain or cover backgrounds. In all, background size, background position, and background repeat options are all supported.

Of note, WordPress already has support for custom site-wide background images in the Customizer and to ensure backwards compatibility the theme.json variant will not affect themes that have enabled this feature. Background images set via the customizer currently take precedence over those set in theme.json or in the Site Editor.

For theme authors, you can use both relative and absolute paths to your images depending on your use case.

Visuals: image of the background image option, demo of setting a background image and changing options
Adoption approach: One can either set the background image in the Styles section or via theme.json.

Here’s an example of a theme.json file with absolute paths to image files, meaning this file has to be hosted and maintained to work:

{

"$schema": "../../schemas/json/theme.json",

"version": 2,

"styles": {

"color": {

"background": "tomato"

},

"background": {

"backgroundImage": {

"url": "https://i0.wp.com/wordpress.org/files/2023/12/sotw-dotorg-drawer.png?w=1807&ssl=1",

"source": "file"

},

"backgroundPosition": "center center",

"backgroundRepeat": "repeat",

"backgroundSize": "cover"

}

}

}

Here’s an example of a theme.json file with relative paths to image files, meaning the image is a part of the theme’s assets. Relative paths to theme assets are defined using the file:./ prefix:

{

"styles": {

"background": {

"backgroundImage": {

"url": "file:./assets/my-theme-background.jpg"

},

"backgroundSize": "cover"

}

}

}

Key Make Posts/GitHub/Trac Issue(s): Global styles: background UI controls (59454) & Global styles: add background image to top-level theme.json styles (59354)

Add box shadow to Featured Image block

Box shadows can now be added to the Featured Image block to create unique designs. When combined with the ability to create and edit box shadows, numerous options open up to draw folks into your site. This also provides feature parity with the Image block so you can have a cohesive visual look across all images on your site.

Key Make Posts/GitHub/Trac Issue(s): Add Box Shadow support for featured image (59616)

Use your Featured Image in the Media and Text block

The Media & Text Block supports using the featured image of a post for media, which adds more design options when using Media & Text in single post and page templates.

Visuals: demo of adding media & text block with a featured image to a single post template.
Key Make Posts/GitHub/Trac Issue(s): Add featured image to Media & Text block (51491),

Add ability to create/edit shadows in Styles

Building on the four shadow presets and the ability to add more presets using theme.json, functionality has been added to Styles so you can create shadows and edit to your liking. This puts the power in your hands to create the exact shadow you’d like.

Visuals: public YouTube video with creating and editing shadows included.
Key Make Posts/GitHub/Trac Issue(s): Add ability to create / edit shadows in the Styles (57100)

Additional supports

A selection of smaller efforts come together to provide more design options directly in the editor:

Set a site wide background image complete with all of the expected image controls either in the root of theme.json or directly in the Styles interface under Layout (59354).
Enable shadow for Cover block (61883 ) alongside shadow support in the Featured Image block mentioned above.

Visuals: demo of setting a side wide background image.

Add aspect ratio presets support via theme.json [theme author]

To add another aspect (get it) of customization, aspect ratio preset support was added to theme.json. This means you can customize the available presets for aspect ratio for the following blocks that support aspect ratio:

Image
Cover
Featured Image

Adoption approach: You can add your own presets via the theme in theme.json settings.dimensions.aspectRatios like so:

{

"version": 3,

"settings": {

"dimensions": {

"defaultAspectRatios": true,

"aspectRatios": [

{

"name": "Extra Wide - 2:1",

"ratio": "2/1",

"slug": "2-1"

}

]

}

}

}

Key Make Posts/GitHub/Trac Issue(s): Add aspect ratio presets support via theme.json.(47271)

Added control for default font sizes and spacing in theme.json & incrementing theme.json to v3 [theme author]

The ability to provide defaultFontSizes was added to theme.json giving themers more control over which font size options are available and providing consistency in managing presets (color, gradient, etc). Thanks to this effort, defaultFontSizes can be set to false in theme.json to disable showing the default font sizes supplied from Core too!

For further consistency, a new defaultSpacingSizes has been added, giving control for showing default spacing sizes and preventing those defaults from being overridden. The default spacingSizes slugs are: 20, 30, 40, 50, 60, 70, and 80.

When defaultSpacingSizes is true it will show the default spacing sizes and prevent them from being overridden by the theme.
When defaultSpacingSizes is false it will hide the default spacing sizes and allow the theme to use the default slugs.

In theme.json v3, by default defaultFontSizes and defaultSpacingSizes are both set to true. This is to be consistent with how other default* options work such as settings.color.defaultPalette.

In theme.json v2, defaultFontSizes and defaultSpacingSizes aren’t a valid key, but are treated as false where it would be used when a theme has font sizes or spacing sizes defined for backwards compatibility of generated CSS. Because the default behavior of overriding font sizes and spacing has changed, this has caused the version of theme.json to increment to version 3.

Adoption approach: To learn more, explore the Theme.json v3 developer documentation and the theme.json how to guide for examples.
Key Make Posts/GitHub/Trac Issue(s): Add defaultFontSizes theme.json (58409), Add defaultSpacingSize option (61842)

Inserter shows all blocks instead of the blocks allowed

Previously, when selecting a block with the Inserter open, only the blocks that were allowed to be added to the selected block were shown often resulting in a confusing experience with an emptier than expected Inserter. With 6.6 when a block is selected, there’s now a list of blocks that can be inserted at the selected block, and a list with remaining blocks. This helps show both what’s allowed to be inserted within the selected block alongside the remaining blocks someone can still add. When you select a block outside of the allowed blocks, it’s inserted below the current block selection.

Visuals: demo showing before and after of 6.5.3 vs 6.6 experience with the Inserter.
Key Make Posts/GitHub/Trac Issue(s): Inserter: show all blocks (62169)

Copy custom CSS between style variations when switching

Previously, if you set any custom CSS in Styles and then switched to a different style variation, that added CSS was lost. With 6.6, this carefully added CSS will remain in place when switching between style variations to ensure you don’t lose any added custom styling.

Key Make Posts/GitHub/Trac Issue(s): Copy custom CSS between variations when switching. (61752)

Shuffle patterns in specific scenarios

To make it easier to swap between similar patterns, a shuffle button has been added when a pattern is inserted and has categories defined with a single top-level block such as a Group block. When shuffling, a new pattern from the same category is added in and the shuffle option remains to allow you to cycle through all available options.

Visuals: demo showing how the pattern shuffle option works.
Adoption approach: If you are a block themer and you want to have users have this option, you can adopt this by adding multiple patterns to the same category and ensuring each pattern has a top level Group block. For an example, review Twenty Twenty-Four’s call to action (cta) patterns.
Key Make Posts/GitHub/Trac Issue(s): Add Shuffle option to sections via pattern category (59251), Pattern Shuffling: Make the results deterministic. (60074)

Bulk export your patterns

Gone are the days of needing to individually export your patterns. Multiple patterns can now be selected and exported as JSON from the bulk edit menu. This will then download a zip archive containing JSON export files for all of the selected patterns that you can use to upload to whatever site you’d like.

Visuals: demo showing bulk selection and export.
Key Make Posts/GitHub/Trac Issue(s): Patterns: add bulk export patterns action. (58897)

Use Starter Patterns in the Site Editor

When creating a new post or page in the site editor, a modal window allows users to choose a pattern to kickstart their layout and design flow. This feature was previously only available in the post editor. (60745)

Visuals: demo showing starter patterns
Key Make Posts/GitHub/Trac Issue(s): Site Editor: Support starter patterns (60745)

Browse and switch templates and template parts in the Inspector [end user]

To make it easy to switch between different options baked into your theme, related templates and template parts from your theme are shown in the inspector. You’ll see the options for templates when viewing an individual template and you’ll see the options for template parts when you’re in the isolated editing mode viewing an individual template part. These options will only appear if your theme has provided them and there’s not yet a way to have custom templates or template parts to appear.

Visuals: image of replacing template parts, demo of replacing templates and template parts
Key Make Posts/GitHub/Trac Issue(s): Template editor/inspector: show and select related patterns. (55091)

Indent List block items via the tab key

The List block supports indenting and outdenting when the selection is at the beginning of the List item. This improves the usability of the List block by allowing indenting via the keyboard, while still preserving existing tabbing behavior for accessiblity in the editor canvas when the selection is elsewhere within the block.

Key Make Posts/GitHub/Trac Issue(s): List block: allow tab to indent/outdent at selection start (59199).

Continued performance improvements

As always, performance was on the mind for contributors this release cycle with a few stand out items to bring to attention from a larger list:

Remove additional calls to WP_Theme_JSON::_construct (59600).
Disable autoload for large options (42441) with a dedicated developer note.
Remove unnecessary polyfill dependencies (60962).
Lazy load post embeds (58143).
A new `data-wp-on-async` directive, being a performant async alternative to `data-wp-on` (61885)

In addition, you can expect improvement to editor performance, with a specific shout out to a 40% reduction in template loading.

Iterating on the Interactivity API [plugin author] [developer]

The Interactivity API provides a standard way to allow developers to add interactivity to the frontend of their blocks. After the release of the initial version of the Interactivity API in 6.5, this latest round of work focused on enhancing the developer experience (especially during debugging), better test coverage and code quality, and fixing reported bugs. This includes the following:

Compatibility with Preact developer tools.
A new `data-wp-on-async` directive, being an async alternative to `data-wp-on`.
Codebase refactor to TypeScript.
Debug messages for mistakes detected during server-side directive processing.

Key Make Posts/GitHub/Trac Issue(s): Review all PRs and changes in this dedicated iteration issue.

Block Hooks fixes [plugin author] [developer]

Efforts in this cycle focused on technical improvements and fixes, including a fix that shows the toggle for hooked blocks that were added by a filter to an _un_modified template and a fix for the harmonization for the ignoredHookedBlocks metadata injection logic.

Adoption approach: Learn more about using block hooks in this developer blog post.
Key Make Posts/GitHub/Trac Issue(s): Follow this tracking issue for more information.

Updates to the HTML API [plugin author] [developer]

Building on the initial launch in 6.2, the HTML API gets a nice maintenance update with the following:

A brand new text decoder to resolve issues not fixable with html_entity_decode() and PHP’s built-in functions that will help ensure that the HTML API remains safe and reliable.
A major internal refactor of the HTML Processor which treats HTML documents in an idealized form. Instead of presenting the tags in the raw HTML text, it’s able to present every tag and every element as found in the DOM, even the ones that don’t exist in the HTML itself.

Adoption approach: Read about the HTML API in this initial post from 6.2 on the developer blog.

Key Make Posts/GitHub/Trac Issue(s): Read this Make Core post for a full recap.

Introducing the Token Map [developer]

Summarized from the Make Core announcement post.

The Token Map, in short, is a new semantic utility meant to answer one simple question: given a string and a byte offset into that string, does the next sequence of bytes match one of a known set of tokens, and if so, what is the replacement for that token? It’s designed as a low-level utility for use in combination with other string parsing logic. There are two ways to create a Token Map: one is from an associative array whose keys are the tokens and whose values are the replacements. The other is an optimization for large token maps (referring again here to HTML with more than two thousand tokens).

In many cases, you likely won’t need to use this optimized data structure when a simpler approach will work just as well. It’s recommended that you experiment first before exploring using it. As an example of an appropriate use-case for the Token Map, you can consider using it to find and replace @-mentions in a document. If your organization has a couple thousand usernames, the Token Map can serve as an efficient way to find those. Username mentions fit this niche well: there are potentially hundreds or thousands of the lookup terms; and the terms have varying lengths without a trailing marker, making it slightly more difficult to segment with a regular expression.

Key Make Posts/GitHub/Trac Issue(s): Read this Make Core post for a full recap.

Dropping support for PHP 7.0 & 7.1

Summarized from the Make Core announcement post.

“Support for PHP 7.0 and 7.1 will be dropped in WordPress 6.6, scheduled for release in July 2024. The new minimum supported version of PHP will be 7.2.24. The recommended version of PHP remains at 7.4 or greater… The benefits to increasing the minimum supported PHP version manifest over time and in multiple places, including within the plugin and theme ecosystem, within the long term perception of the WordPress project, within developer relations, and over time within the WordPress codebase and its developer tooling.”

Key Make Posts/GitHub/Trac Issue(s): Dropping support for PHP 7.0 and 7.1

Changes to help prepare for React 19

WordPress 6.6 will include React 18.3, which introduces deprecation warnings to help developers prepare for React 19. It’s essential to stop using deprecated features to avoid bugs or unintended behavior when React 19 becomes stable. One significant change in React 19 is the removal of defaultProps for function components, requiring the use of ES6 default parameters instead. For a complete list of deprecations and changes, refer to the official React 19 upgrade guide.

Key Make Posts/GitHub/Trac Issue(s): Preparation for React 19 Upgrade

New filter to extend the list of post content blocks [plugin author] [developer]

When a template is locked, the template is rendered but all the blocks, except post content blocks, that are within the template have their block editing mode set to disabled. Previously, if you created a custom block that reads / writes data to the post object, your block wasn’t able to be edited directly as the list of allowed blocks was hardcoded. A new filter is now available so you can extend the list of post content blocks to include a custom or third party block that you want folks to be able to edit directly when a template is locked. This is particularly helpful for an agency or enterprise environment that needs to lock templates and selectively allow control over what’s editable. Any block that saves data to a post should be added to this list.

Adoption approach: review the block filters documentation for an example and more information.
Key Make Posts/GitHub/Trac Issue(s): Add filter to allow extending the list of post content blocks (60068)

Add ability to preview template in post editor for non administrators [site admin] [enterprise]

In WordPress 6.5 the ability to preview a template while working on a post or page was added, enabling an easy workflow to see how your content will look live on the site as well as to make any quick changes to the template directly. Previously, this option was reserved just for administrators but this release allows non-administrators to see templates while editing content. This means that folks who can only view templates are able to gain access to the preview while still being limited in their ability to edit templates directly.

Adoption approach: If you want folks who aren’t administrators to have access, ensure that their role is set to allow the edit_post capability.
Key Make Posts/GitHub/Trac Issue(s): Enable template preview in post editor for non administrators (60447)

Placeholders updates

Placeholders provide valuable information to folks about blocks, often acting as a piece of onboarding. To ensure consistency, especially for Group and Columns block, placeholders for a range of blocks have been updated visually to make it easier to know how best to interact with them.

Visuals: image of updated placeholders
Key Make Posts/GitHub/Trac Issue(s): Placeholder: Tweak placeholder style (61590), Fix alignment of Group block placeholder text (59271), unify placeholders (59275)

Refining the Font Library

After its debut in 6.5, this release cycle focused on bug fixes and smaller enhancements rather than any new functionality. This includes the following:

Update loading visual with new progress bar component (54797)
Font Library: show the scrollbar bottom edge (54401)
Clarify which fonts are uploaded vs theme provided in modal (55220)
Fix and improve handling of uploading font files (60835).

Add support for custom ports for multisites [developer] [enterprise]

Previously only available for single sites, multisites now have support for custom ports. By adding custom ports, this should make local development and building CI pipelines easier, as you can now use localhost:<port_number> for different sites on your multisite.

Key Make Posts/GitHub/Trac Issue(s): Add support for custom ports in multisite site addresses (21077)

Introduce wp_prime_network_option_caches() to load multiple network options with a single database request [developer] [enterprise]

Summarized from the trac commit

WordPress’s get_network_option function generally makes individual database requests for each network option. While some options are preloaded in wp_load_core_site_options, many still require single database calls to the network options table.

6.6 adds two new functions: wp_prime_network_option_caches and wp_prime_site_option_caches. These functions enable developers to pass an array of option names, allowing caches for these options to be primed in a single object cache or database request. If an option is not found, the notoptions cache key is refreshed, preventing unnecessary repeated requests.

The function wp_prime_site_option_caches is similar to get_site_option, enabling developers to retrieve network options on the current network without needing to know the current network ID. If these functions are called in a non-multisite environment, they fall back to using wp_prime_option_caches.

Key Make Posts/GitHub/Trac Issue(s): Introduce wp_prime_network_option_caches() to load multiple network options with a single database request (58182)

General improvements

Improvements across the WordPress experience continue to land in each release. While each of the items below aren’t enough to highlight alone, they each play a role in making WordPress better to use.

Command Palette: Add “Template Parts” command to site editor. (61287)
Keyboard shortcut: Add a shortcut to create group from the selected blocks. (46972)
List Block: Add block class name to the list block to make it easier to style the List block separately from other lists.
List View: collapse non-selected items using a handy new keyboard shortcut (Option-L on Mac, or Alt-L on Windows). (59978)
List View: Do not open list view by default on mobile. (59016)
List View: update spacing of individual items. (60713)
Multisite: Clarify edit site flow with “Edit site” opening the Site Editor and “Manage Site” to open up multisite network admin site editing screen (60977)
Social Icons: Update Medium icon. (57073)
Social Icons: Add Bluesky icon. (61372)
Social Icons: Update Reddit social icon to latest brand guidelines. (59438)
Site Editor: Display confirmation modal before clearing template customization. (60119)
Site Editor: Improve the frame animation. (60363)
Site Editor: Add create pattern button in patterns page. (60302)
Site Editor: Ensure more consistent root padding to ensure content is rendered as expected regardless of where they are inserted or edited. (60715)
Site Editor: For synced entities the icon should be purple. (62024)
Site Editor: Add block-level Text Alignment UI. (61717)
Site Editor: Site Editor: Use site title as a link. (61258)
Spotlight mode: Limit spotlight mode to the editor. (58817)
Themes: Don’t display Welcome Guide in a hybrid theme. (55865)
Quote block: Button for cite add/remove. (59073).
Writing flow: Remove first empty paragraph on Backspace. (61889)
Writing flow: unify split logic so t hat when pasting blocks, the split block is merged with the pasted blocks. (54543)

Punted to a future release

Zoom out to compose with patterns

A few different initiatives were underway for 6.6 to allow one to focus on building with patterns rather than granular block editing. This included a built-in zoom out that appears contextually when inserting patterns and that allows you to move, delete, and more while in a mode that helps you see the whole of your template. After inserting, the option to shuffle top level patterns within a template encourages you to quickly explore alternative patterns. Taken together, this work aimed to offer a first step towards a new way to interact with and build with patterns. However, the experience didn’t get far enough to release and the decision was made to punt.

Key Make Posts/GitHub/Trac Issue(s): advancing contentOnly editing and zoomed out view

Preferred languages

“Preferred Languages replaces the existing languages dropdown with a supercharged version that lets you select multiple preferred languages. WordPress then tries to load the translations for the first language that’s available, falling back to the next language in your list otherwise. Without this, WordPress would just fall back to English (US) in such cases, which is not a great experience. Such a UI is a pretty standard feature that can be seen for example also in operating system and browser settings.”

In light of feedback on the proposal, the decision was made to punt to allow for more time and iterations.

Key Make Posts/GitHub/Trac Issue(s): Merge Proposal Preferred Languages

After Script Modules were introduced in WordPress 6.5, server to client data sharing was explored but not explored in time for beta 1 for 6.6.

Key Make Posts/GitHub/Trac Issue(s): Read the initial proposal to add this feature to Core for more information.

View inherited style values

Knowing where a block’s style comes from is key to knowing where a change might need to be made to style it to your liking. For 6.6, work was started to show locally the value that a block inherits globally, when applicable. This means that, for example, if you set a paragraph to always have blue text in Styles, every paragraph you added will show blue text and the block settings will show the blue color as the chosen text color. This is in contrast to today’s experience, where it shows a circle with a line through it, to indicate that no local color has been set despite the block inheriting it globally. This change will not land for 6.6 but when it lands in a future release it will resolve long standing feedback on the experience of styling in the Site Editor and lay the groundwork for future improvements to showing the hierarchy of styling.

Key Make Posts/GitHub/Trac Issue(s): Follow this issue for more information.

One response

796 Block themes, alternatives to custom block dev, game's a changing for custom fields – Weekend Edition 297 – Gutenberg Times

June 29, 2024 at 4:54 pm

[…] McCarthy also posted the Source of Truth on WordPress 6.6 features. It again is a great source to learn about every feature that is coming to a WordPress […]