WordPress 6.2 Source of Truth

WordPress 6.2 highlight grid with green, blue, and black colors detailing various features coming to the release.

Since becoming a sponsored contributor in the wider WordPress community in 2020, I noticed the same problem repeating with each release: how can one get the most accurate information about the entirety of a release as quickly and painlessly as possible? I noticed it across both Automattic (where I work) and the community as teams rallied together to update docs, training materials, and more. The lack of a “one stop shop” led to a lot of duplicated efforts tracking down the same information, incorrect information getting out, delays in preparing for a release, and more.

To attempt to solve this, I started creating a “Source of Truth” in the form of a google doc that’s evolved over the releases, starting with WordPress 5.8. This is the first time I’m attempting to share this more publicly after previously sharing it on a more one on one basis.

As always, feedback is welcomed for improvements for future versions as I consider how best to share this information. Of note, this is not meant to replace dev notes or the release specific field guides which serve important roles and are separate efforts.

Finally, big thank you to the various editors, developers, designers, and more that contributed to this in so many ways from content reviews to technical reviews to creating specific assets.

Important Note/Guidelines

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 anything here, 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 post will be updated and a changelog will be added.
  • 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.


March 13th, 2023: update “a new way to interact with the site editor” in light of this PR to remove the navigation section


WordPress 6.2 is set to be released on March 28th with an exciting list of features. The main focus of this release is refinement and ease, with significant improvements in the site editing experience. This includes a revamped approach to navigating between templates and template parts, an additional way to manage menus with the navigation block, and the ability to import widgets to block themes. As always, we’ve improved the block experience with various features like a new distraction-free writing mode and better organized block settings. 

Wrapping up Gutenberg Phase 2 will be a two-part process, beginning with 6.2 and finishing with 6.3. Notably, the Site Editor has improved so significantly that we’re able to remove the beta label from the Site Editor. The changes included in 6.2 create a strong foundation for breaking ground on Phase 3, which will focus on collaborative workflows. However, a new phase doesn’t mean work is done, and we will continue to make improvements to this more powerful experience. From site editing to post writing, blocks are everywhere, and we invite you to experience a new way to WordPress. 

For a general sense of how the experience has evolved, what follows is a video from mid-December showing some of the earlier versions of features available in 6.2:

Important links:

6.2 assets:

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


To make this document easier to navigate based on specific audiences, the following tags are used liberally: 

  • [end user]: end user focus. 
  • [theme author]: block or classic theme author. 
  • [plugin author]: plugin author, whether block or otherwise.
  • [site admin]: this includes a “builder” type. 

If no tags are listed, it’s because the impact is broad enough to impact everyone equally. 

Priority Items for 6.2

A New Way to Interact with the Site Editor

6.2 introduces a fundamental shift: a new way of interacting with the Site Editor. Rather than being dropped directly into the template powering the homepage, you’ll be able to see the whole of your site. A dark-gray sidebar contains a list of all templates, template parts, and your primary navigation menu; clicking on any of these components will preview it in the editor’s main canvas. To edit any component, you can click on the pencil button or just click on the canvas itself. Taken together, these changes allow an unprecedented ease of access:

  • Quickly browse, preview, and edit templates and template parts.
  • See template descriptions. 
  • Resize the sidebar based on your previewing needs.
  • Save global changes all at once, similar to the multi entity saving (see video below under Visuals). 

This change allows future interaction improvements like content editing in the site editor, more extensibility options for plugins, and managing menus. 

If you’re looking for the technical project name in the Gutenberg GitHub Repo, look for references to “Browse Mode.” 


Key Make Posts/GitHub/Trac Issue(s): 

  • Reorganize the site editor experience with browse mode (36667).
  • Allow the option to resize the sidebar frame (46903).
  • Move the edit button in the site editor sidebar to a contextual widget (46700).
  • Allow adding new templates and template parts directly from the sidebar (46458).
  • Add back link to Design heading in site editor navigation to return to Dashboard (47950).
  • Add a nested level when selecting templates or template parts (47777).
  • Site Editor: update the edit button to a pencil (48584).

Navigation Block: New Editing Options and Better Defaults 

6.2 adds a new, editable view to the block settings sidebar for menu management. This works similarly to the List View but is isolated to the current menu you are editing. This option is offered in addition to the current editing experience introduced in WordPress 5.9, and represents a middle ground between the prior experience and the new block editing paradigm. 

More technically, the Navigation block also includes the ability to restrict editing the content on its inner blocks (links and submenus). This helps folks like site admins or agencies further tailor the experience, especially if you’re taking advantage of the ability to use block template parts in classic themes

Finally, this release continues to improve the inner workings of the Navigation block, including adding a location fallback for classic menus so that the most recently created classic menu is used by default. (If there is a menu named “primary” or has a primary location, that menu still takes precedence). Separately, when the Page List block is used, a simplified option guides you through the process to edit each item directly as you desire. 

Taken together, all of these make working with this critical site-building block a cleaner, more intuitive experience. 


Key Make Posts/GitHub/Trac Issue(s): 

  • Make the OffCanvasEditor the default experience (46938).
  • Clarify the explanation of how ‘Convert to Links’ works in Page List block (45394).
  • Adds content locking/content only editing to nav block (44739).
  • Various fallback improvements (45976) (46286).
  • Add an “open list view” option (46335).
  • Update and add the convert panel to the block settings sidebar (46352).

Important Interface Changes

Beta label removed from the Site Editor

After multiple release cycles, starting with WordPress 5.9, the beta label has now been removed from the Site Editor. This means that when you navigate to Appearance > Editor, you will no longer see the “(beta)” notice. Removing the beta label was not a quick decision, only coming after multiple releases’ worth of discussion and evaluation. However, although the label is being removed, enhancements and bug fixes will continue — just as they do with other parts of WordPress. 

Key Make Posts/GitHub/Trac Issue(s): removing the beta label. (39293)

Quickly identify Template Parts & Reusable Blocks with colorization [end user] [theme author]

Template parts and reusable blocks are synced, unlike other Core blocks. This makes it crucial that you know when you’re interacting with them, and can quickly identify them during the flow of site creation. With this release, these blocks are now outlined with a different color in various parts of the interface: List View, the Block Toolbar, and the Canvas itself. 

Visuals: image of a Header template part with the colorization applied.

Key Make Posts/GitHub/Trac Issue(s): colorize template parts and reusable blocks (32163). 

Organized block settings with split controls [plugin author] [end user]

With a growing number of design tools added in the last few WordPress releases, the block settings has been split into two tabs — Styles and Settings — to allow for a more intuitive and clear understanding of the options built into each block. This change will make highly configurable blocks, such as the Group block and Navigation block, easier to manage and customize. The tabs will only render if there are settings registered as well. For example, the paragraph block doesn’t have any specific setting so all options show in the sidebar without the split tabs.

For block plugin authors, this marks a fairly substantial change to ensure the options for your block show up where you want them to. As a result, the __experimentalGroup property was stabilized on the InspectorControls slots. You can now define which InspectorControls group to render controls into via the group prop. By default, registered controls are placed under the settings tab.

In addition to stabilizing the __experimentalGroup property, a new styles group was added, so styles-related controls that do not fit conceptually under the block support panels — border, color, dimensions, typography, etc. — can be included under the “Styles” tab in the block inspector:

<InspectorControls group="styles">

  // Add your custom styles related controls here.


Visuals: image of split tabs for the navigation block.

Adoption approach: N/A. There’s no way to turn this off. 

Key Make Posts/GitHub/Trac Issue(s):  

  • Split block settings between styles and settings (40204). 
  • Stabilize the split tab experiment (47045).
  • Inspector Controls: Stabilize the experimental control groups (47105).

Updated block settings icon [user] [site admin]

To make way for the block settings changes mentioned above, a new icon for the block setting sidebar has been added to prevent a “cog” from being used twice in the same interface. While a small change, it has a big impact as it touches numerous docs, training videos, and more. This is something to prepare for and to proactively update material as best as you can. 

Visuals: before/after image of the block settings icon.

Key Make Posts/GitHub/Trac Issue(s): Discussion around the change in icon (46851).

Improved discoverability with Inserter redesign [end user]

A new design offers a split view between categories and patterns, improving the navigation between categories and providing larger previews for patterns, resulting in better discoverability and at-a-glance context.

Visuals: new inserter design showing header & footer patterns and adjusted categories video.

Key Make Posts/GitHub/Trac Issue(s): 

  • New Pattern Inserter design discussion (41379).
  • Ensure the inserter shows pattern titles when focused on or hovering an individual pattern preview (46419).

Pattern improvements

Header and Footer Patterns [end user] [site admin]

With the Site Editor speeding up the creation process by allowing you to edit all parts of your site and patterns, new Header and Footer patterns are now bundled into Core for all to use. This helps democratize design and provide excellent out-of-the-box options for folks, regardless of what block theme they are using. The following are direct links to the new options:



Visuals: new inserter design showing header & footer patterns and adjusted categories video.

Key Make Posts/GitHub/Trac Issue(s): Ensure Header & Footer patterns use the Pattern Directory API (46017)

Reorganized pattern categories [user] [theme author]

Pattern categories have been revamped and consolidated in some cases to accommodate a growing number of patterns, including the header & footer options. This includes the following changes:

  • Query patterns were renamed to Posts for more user-friendly language.
  • Columns were merged into Text to consolidate categories. 
  • Call to Action category replaces Buttons. 
  • Banner category introduced to denote visually distinctive elements that typically help structure or contrast the contents of a page (including headings and “hero” elements).
  • Header & Footer categories were introduced. 

Visuals: new inserter design showing header & footer patterns and adjusted categories video.

Key Make Posts/GitHub/Trac Issue(s): recategorizing pattern categories (44501)

Register patterns for specific template types [theme author] [site admin]

Developers can also now register patterns for specific template types, limiting where the patterns appear. For example, an Error 404 pattern would only make sense when used with the 404 template. This builds on the prior pattern options of registering patterns to appear for post types so, for example, you could have specific patterns appear when creating a new post

Gist example: 404 pattern registered for the 404 template.

Adoption approach: opt in when registering patterns.

Key Make Posts/GitHub/Trac Issue(s):  Add: Template types to the patterns API (45814).

Style improvements and features

For an overview of how these various improvements relate to each other, please review this Core Editor Improvement post

See an inline preview when making changes to blocks globally [end user] [theme author]

When using the Styles interface in the Site Editor, you have access to customize individual blocks globally. Prior to this release, if a block you were editing wasn’t visible in the template you were in, you couldn’t get a clear sense of how the changes were impacting that block without looking elsewhere. This new option allows an inline preview as you edit, ensuring you’re able to see the impact of those changes without needing to leave the interface. This is especially useful for block themers and users alike. 

Visuals: inline preview in use video

Adoption approach: only available with block themes

Key Make Posts/GitHub/Trac Issue(s): display inline preview on per-block settings (42919). 

Rely on a zoomed out view when selecting a style variation [end user]

When switching between style variations bundled with a block theme, the interface of the Site Editor shifts, allowing for a more holistic view of the template at hand. While it doesn’t show the entire site, it does allow you to get a better look at how your changes will impact things more broadly. (Previously, you only were able to see part of the template, making it harder to see the full impact of a style variation selection.)

Visuals: change in view when selecting a style variation video

Adoption approach: only available with block themes

Key Make Posts/GitHub/Trac Issue(s): invoke zoomed-out view when selecting a style variation (44987).  

Style an individual block and apply it to all instances [end user] [theme author]

When creating a design or customizing individual blocks, there are moments when you want to apply what you just created to all instances of that same block. A new option in the Site Editor in the individual block settings allows you to do exactly that, saving time and ensuring consistency when you want it. 

This option is intentionally more hidden and you can find it in the Settings tab under Advanced.

Visuals: applying navigation block changes globally video

Adoption approach: only available with block themes or themes using the Site Editor. 

Key Make Posts/GitHub/Trac Issue(s): Add option to apply local changes to a block to your entire site (44361) with updated phrasing (46965). 

Use the Style Book to see your changes as you style your site [end user] [theme author]

When making changes to the Styles of your site, whether changing to a different style variation or tweaking an individual block, it’s imperative to see the cascading impact. With the addition of the Style Book, a view that you can toggle on and off as you’d like, you can see all of your blocks on your site as you make changes. Prior to this release, if a block wasn’t visible in the template you were editing, you weren’t able to see how your changes might land. Style Book takes a big step forward in offering an intuitive way to globally make changes to your site. 

There are a few limitations/refinements planned for the future that didn’t make it into this release:

Visuals: exploring the Style Book video 

Adoption approach: only available with block themes. This feature automatically works with third party blocks so no additional extension is required.

Key Make Posts/GitHub/Trac Issue(s): Offer a way to view a document containing all blocks and styles (44420). 

Copy/paste block styles [end user] [theme author]

With a growing number of design tools in each WordPress release, designs can have deeper personalization and flairA new option has been added to allow you to copy and paste block styles, making it easy to reuse designs you’ve created.

Visuals: copy/paste styles videos: option 1 and option 2

Key Make Posts/GitHub/Trac Issue(s): Make it easy to copy and paste styles (44418). 

Use Custom CSS globally or on a per block basis [theme author] [end user]

As part of the effort to create feature parity with the Customizer, Custom CSS—both on a global and per block basis—has been added to the Site Editor. Users and designers alike can quickly make CSS changes that won’t be overwritten by a theme update. 

The Custom CSS options are baked into Global Styles, selectable from the three dot menu for global changes, and placed as a top-level option for each individual block. Once Custom CSS has been added globally, it appears as an additional field in the top-level Styles interface. This ensures that it’s an available option without emphasizing it unnecessarily (such as when simpler alternatives exist); ideally, theme authors and end users should first try to add styling with the standard global and block design tools.

In the future, this feature will be built upon in a few additional ways: 

On a more technical note, for any hybrid themes, CSS added in the Site Editor will override CSS added in the Customizer. Specifically, CSS added in the Site Editor will be outputted after Style options and after any Customizer custom CSS.

Finally, these CSS options do not work or cover adding CSS in the post editor. You can see a greater discussion around this here

Visuals: video exploring where each CSS option is and how it’s displayed.

Adoption approach: only available with block themes and for users with edit-css permissions (important for multisite)

Key Make Posts/GitHub/Trac Issue(s):

  • Global Custom CSS in the Site Editor (30142). 
  • Custom CSS on a per block basis (44412). 
  • Move additional CSS input in Styles interface (47266). 
  • Move custom CSS to ellipsis menu if no custom CSS present yet. (47371)
  • Move custom css to its own inline style generation method and combine with customizer CSS. (47396)
  • Add a CSS style to theme.json to allow the setting of custom CSS strings. (46255)
  • Add validation message to custom CSS input. (47132)

Editing block style variations [theme author] [end user]

For blocks with style variations, you can edit those variations directly in the Site Editor’s Styles interface by going to Styles > Blocks, and picking a block with a variation. This includes core blocks like the Button, Image, and Site Logo blocks. For blocks without variations, there is not an option to create one just yet. 

Visuals: editing a block variation video.

Adoption approach: only available with block themes and blocks with variations.

Key Make Posts/GitHub/Trac Issue(s): Edit block style variations from Styles (46343

Improved tools panels for the Styles typography controls [theme author] [end user]

To provide another layer of consistency, the tools panel that’s currently in use in the block settings interface has been brought to the overall Styles experience when interacting with typography controls. For context, the tools panel offers a streamlined experience when it comes to tweaking design tools with easy to access reset options and the ability to quick add or remove visible controls. 

Visuals: using the tools panel within the Styles typography controls video.

Adoption approach: only available with block themes

Key Make Posts/GitHub/Trac Issue(s): use tools panel in Styles for typography controls (44180). 

Enjoy a distraction free writing experience [user]

A new visual mode creates a more focused writing experience by hiding various parts of the editor interface. When enabled, any open sidebars are closed and toolbars fade away, leaving your content to take center stage. You can toggle this mode on/off as you’d like.

Visuals: quick distraction free mode youtube video

Adoption approach: must intentionally turn on in preferences. 

Key Make Posts/GitHub/Trac Issue(s): introduce distraction free mode (41740).

Introducing Sticky Positioning for Fixed Position Items, like Headers [end user] [theme author] [site admin]

A new Position block support adds a “Sticky” option so that a block remains within the viewport and is stuck to the top of the page when the content is scrolled instead of scrolling with the rest of the content. This is useful if you need to ensure that a root level element, such as a header or a promotion banner, remains on screen regardless of the page’s scroll position. It works in the block editor as well as in the front-end,  leading to a true WYSIWYG experience. 

This only works with blocks at the root level, where a new “sticky” option appears. To have a template part, like a header, be sticky, wrap it in a Group block, and set that Group block’s position to sticky.

Visuals: using sticky positioning video.

Adoption approach: opt in via enabling the option. 

Key Make Posts/GitHub/Trac Issue(s): 

  • Add a Position block support (including sticky), decoupled from layout (46142).
  • Some future follow up tasks to this initial implementation in this issue.

Additional Items for 6.2

Query Loop block improvements 

Smarter suggestions for Query Loop block variations [theme author] [plugin author]

Block variations have been available in Gutenberg for a long time. They allow you to have  similar versions of the same block that share some common functionality. With WordPress 6.2, if you have an active variation of the Query Loop block on your site and that variation has registered some block patterns, only those patterns will be suggested in the inserter offering a more relevant experience. 

For example, you might have a Products List block that is a variation of the Query Loop block. That Products List can also have a registered block pattern. When inserting the Products List block, you will not see the default Query Loop block patterns but rather your own block pattern associated with the Products List. 

Key Make Posts/GitHub/Trac Issue(s):  Suggest active variation patterns for the Query Loop block (44197).

Improved setup experience for the Query Loop block [end user]

When adding a new Query Loop block, selecting available patterns has been updated to a consistent interface used when selecting from patterns elsewhere in the Site Editor. This both creates a more cohesive editing experience when working with patterns in general and resolves some consistent feedback about the modal for choosing patterns not clearly showing how best to select what you want. This stands in contrast to the modal that was used previously showing a nearly full screen view that led to some confusion around how the pattern would appear and how many were available. 

Visuals: Query pattern setup before video and after video

Key Make Posts/GitHub/Trac Issue(s): Query Loop block: improve setup state (33202).

New text focused Query Loop block patterns [theme author] [end user]

To get up to speed faster with the more advanced Query Loop block, patterns have been integrated into the set up state of the block since the beginning. These patterns have been refreshed with three additional text focused options to balance out the more visual options that have been present previously: 

Key Make Posts/GitHub/Trac Issue(s): bundle more text focused patterns (44140). 

Potential breaking change: Query Loop block color support removed [theme author]

“Potential breaking change: The Query Loop block no longer has color support. It is now purely a settings-only block without design-related options. WordPress will introduce a wrapping Group block over its nested blocks and should migrate existing colors settings to the Group. Developers should test this to make sure that this does not negatively affect existing uses of Query Loop blocks in their themes.”  – From “What’s new for Developers? February 2023”

Theme.json advancements

Use four shadow presets or define your own with theme.json [theme author] [end user]

While using a block theme, there are now four shadow presets folks can choose from by default, with the option for new and custom to be defined from the theme via theme.json. This system works similarly to colors, gradients, and other opt-in design tools. The following come by default for folks to use:

  • Natural
  • Crisp
  • Sharp
  • Soft

Visuals: focused video showing shadow preset options & longer video showing a more comprehensive flow of finding and using the options.

Adoption approach: Opt in with developer documentation to learn more. 

Key Make Posts/GitHub/Trac Issue(s): 

  • Add shadow presets support for theme.json (46813)
  • Developer documentation explaining how to use the feature for themes. 
  • Add shadow presets and UI tools to Styles (46502). 

Allow object type for theme.json schema [theme author]

This release includes support for objects, in addition to strings, for style properties in theme.json. This allows you to do things like the following, making it easier to have a cohesive design system with a set of values:

"elements": {

"button": {

"color": {

"background": {

"ref": "styles.color.text"


"text": {

"ref": "styles.color.background"





Key Make Posts/GitHub/Trac Issue(s): Allow object type on style properties. (45897)

Add configurable settings for minimum font size to theme.json [theme author]

“Following on from the fluid typography settings that were introduced in WordPress 6.1, WordPress 6.1.1 introduced a hard-coded minimum for the fluid typography rules of 14px, to ensure that the generated typography rules would not result in font sizes that were too smaller for readability in narrower viewports.

In WordPress 6.2, themes can define their own minimum font size for fluid typography rules. Depending on the theme’s requirements, sometimes the desired minimum font size value might be greater or less than the provided default of 14px. When used, the minimum font size will result in any font-sizes used that are equal to or less than the minimum being output directly as that font size. For font sizes larger than the minimum font size, the minimum font size will be used as the floor of the fluid typography calculated rule.” – excerpt from a dev note draft

Adoption approach: opt in, both for fluid typography and configurable settings. More information here for adoption steps.

Key Make Posts/GitHub/Trac Issue(s): add configurable settings for minimum font size to theme.json (42489).

Performance enhancements with theme.json

6.2 marks a big performance step forward with block themes thanks in large part to adding a cache to the high-level public method that consumers use to query the settings coming from theme.json APIs (WordPress, block, theme, and user data). Specifically, WP_Object_Cache was added to gutenberg_get_global_settings to cache the results of querying settings from theme.json. This work alone, outside of additional PRs, resulted in the following improvements:

  • 23% for themes with theme.json
  • 9% for themes without theme.json

See full dataset. Alongside this overall effort, additional caching was added elsewhere to iteratively improve performance.

Key Make Posts/GitHub/Trac Issue(s): 

  • wp_theme_has_theme_json: cache output (45543).
  • wp_get_global_settings: cache output (45372, 45971, 45969).
  • wp_get_global_stylesheet: migrate from transient to object cache (45679).
  • wp_get_global_styles_svg_filters : migrate from transient to object cache 47460 (done in core as the function was removed from Gutenberg).
  • Evolution of WordPress TTFB: 5.6 to 6.2 by a Core contributor working on these efforts.

Import widgets to block themes [site admin] [end user]

Prior to 6.2, when switching to a block theme, content in widgets were lost, requiring a site owner to copy/paste anything they wanted to keep over. To ease gradual adoption of block themes and prevent content loss, a pathway has been built that offers the option to import widgets from a classic theme, closing a big gap in experience. Here are the steps to do so:

  1. Open the Appearance > Editor after switching from a classic theme to a block theme. 
  2. Choose a template you’d like to import widgets into.
  3. Add a template part to that template.
  4. Open the sidebar settings, choose which widget area you’d like to import, and select “Import”. 

There are a few known issues at this time to be aware of:

For more context, this process seeks to transform widgets into blocks. If this fails, whether due to the fact that there isn’t a block counterpart or something else, they are skipped in the import process and a notice is displayed. You can see further discussion and details on this topic here

Visuals: importing widgets video.

Key Make Posts/GitHub/Trac Issue(s): Pathway to import widgets when switching to a block theme from a classic theme (39270)

Layout changes

Layout controls added to children of flex layout blocks for more design possibilities [theme author]

With new controls come new design possibilities–a new dimensions control (width for row, height for stack) is available for children Row and Stack blocks with an option to select between fit, fill and fixed:

  • Fit (Default): Block fits to fill its needed space.
  • Fill: Block stretches to fill any available space. This requires a fixed height for the Stack block to stretch at all.
  • Fixed: When selected, a specific unit-based width/height can be set for the block.

If the fixed option is selected, an `input` for a dimension will be shown, where the fixed size can be set. 

Adoption approach:  This feature can be added to the container block in its __experimentalLayout settings in block.json, like so:

"__experimentalLayout": {

"allowSizingOnChildren": true,

"default": {

"type": "flex"



You can learn more about layout controls in this Gutenberg Times Live Q&A.

Key Make Posts/GitHub/Trac Issue(s): Add Layout controls to children of Flex layout blocks (45364).

Add a Variation Picker to the Group Block Placeholder [end user]

When a new Group block gets inserted into the page, it will present you with a variation picker to instantly choose which type of layout you want to use. This helps both expose the built-in options and simplifies the setup process.

Visuals: image showing the new setup state for the Group block.

Key Make Posts/GitHub/Trac Issue(s): use a variation picker in the Group block (43496)

Continued Inserter updates

Outside of the Inserter redesign alongside pattern improvements, the following are also changing with the 6.2 release.  

Add media and Openverse images to your content directly from the Inserter [end user]

Media is an important part of site building and the Inserter is a key tool for adding various types of content to your site, from blocks to patterns. With WordPress 6.2, you will be able to both add media directly from your library from the Inserter and search/select images from Openverse, a search engine for openly-licensed media. Having images at your fingertips both carefully added to your media library and broadly available for use makes it even easier to create a compelling, visually appealing site. 

Visuals: searching through Openverse image and adding media video.

Adoption approach: opt out of Openverse integration via the new public block editor setting (enableOpenverseMediaCategory)

Key Make Posts/GitHub/Trac Issue(s): Inserter: Add Media tab and explore basic Openverse integration (44496).

Replace text in reusable tab with an icon [end user]

A minor change but one worth mentioning – the reusable tab in the Inserter has been replaced with the reusable block icon to save space. 

Key Make Posts/GitHub/Trac Issue(s):  Replace text with icon for the reusable blocks (45851). 

General interface changes

Access the list view and document information all from one panel [end user]

The Details popover and List View panel have now been combined into a single panel offering a more streamlined way to manage the current document. This new “Document Overview” panel is accessible by clicking on the original List View icon in the toolbar. 

Prior to this, there were separate icons in the Editor toolbar for “List View” and “Details.” The Details popover presented a document outline and information like the character and word count. The List View panel displayed a hierarchical view of all blocks in the document.

Visuals: video exploring the new change briefly.

Key Make Posts/GitHub/Trac Issue(s): Move document information and outline to list view panel (44193) & Move word count to the top of the outline (46648).

Add/remove caption for various blocks in the toolbar [end user]

Captions are baked into various blocks and, to make this common workflow more prominent and resolve a layout shifting problem, a add/remove caption button has been added to the toolbar of the Audio, Video, and Image blocks. 

Key Make Posts/GitHub/Trac Issue(s):  PRs for adding the functionality for the Audio (45112), Video (45113), and Image (44965) blocks. 

Use an updated Focal Point Handle in the Cover block [end user]

The Cover block allows you to precisely set where you want the focus to be. The handle that allows you to do this focal point positioning has been updated to a more modern experience. 

Visuals: before and after design update image.

Key Make Posts/GitHub/Trac Issue(s): Update design of focal point (45053)

Quality of life improvements


Outside of many of the big improvements to various blocks listed throughout the rest of this document, there are numerous smaller enhancements to the base block experience that continue to make blocks easier to use and more robust in their capabilities: 

  • Improved drag & drop with images by allowing you to drop an image onto an empty paragraph block to replace it with a new Image block.
  • Calendar: Set the background, link and text color (45643).
  • Columns: Add transform to unwrap the contents (45666).
  • Latest posts: Add color support (41874).
  • Latest posts and latest comments: Add spacing support (45110).
  • List/quote: Unwrap inner block when pressing Backspace at start. This results in the first inner block becoming a Paragraph that is separate from its previous parent List or Quote container (45075).
  • List Item: typography support added (43312). 
  • Page List: expand to see the hierarchy of pages in the List View (45776).
  • Page List: typography support added, including setting the font size, family, and more (43316). 
  • Page List: option to select the root page to build the Page List block from, allowing a subset of pages to be displayed (45861).
  • Post Author: Include option to link author archive. (42670)
  • Post Author: Make the Author selector display all users instead of just 10 (45640).
  • Post Terms: Add spacing support (43646).
  • Video: Update placeholder style (44215).



  • Transform Paragraph into Heading via Keyboard Shortcut using the new control + option + 1 – 6 keyboard shortcut, allowing you to set specific Heading levels. 
  • Added support for alt + arrow keyboard combinations to make navigating blocks of text easier (44081).
    • If your cursor is towards the end of a long paragraph, you can quickly press alt + up arrow to move to the beginning of that paragraph. 
    • If you are already at the beginning of a text block, you’ll move to the start of the previous paragraph. 
    • alt + down arrow will move you to the end of a block of text.

Visuals: Transforming paragraphs to headers via keyboard shortcuts video


  • Spacing Visualizers: Block toolbar is hidden as soon as you hover over the spacing setting allowing you to focus on the content while you adjust the spacing (45131).
  • Spacing Visualizers: Visualizers for block spacing are visible as soon as you hover over a spacing control rather than just when edited (44955).
  • Updated lock icon to make it an outline to be less visually heavy (45645).
  • Update the border icon (46264).
  • Min Height: Add height control component with slider (45875).
  • Selecting multiple blocks is now more visually consistent (44150).
  • The sibling and line inserters feature a more natural animation effect.
  • Block inserter is hidden when the user is typing, reducing visual clutter.


Developer specific updates

Update to experimental API process [plugin author] [theme author]

While more of an FYI than a release specific item, a new experimental API package has been introduced to better communicate to external consumers of various APIs what can be relied upon and how best to use them. For context, experimental and unstable APIs are temporary values exported from a module whose existence is either pending future revision or provides an immediate means to an end.

There is no support commitment for experimental and unstable APIs. They can and will be removed or changed without advance warning, including as part of a minor or patch release. As an external consumer, you should avoid these APIs.

Key Make Posts/GitHub/Trac Issue(s): developer documentation can be found here with the original discussion about this new experimental package here.  

Introducing a WP_HTML_Tag_Processor [plugin author] [theme author] 

WordPress 6.2 ships with WP_HTML_Tag_Processor – a tool to adjust HTML tag attributes in the block markup:

$p = new WP_HTML_Tag_Processor( '<a href="#"></a>' );

$p->next_tag( 'a' );

$p->remove_attribute( 'href' );

echo $p->get_updated_html();

// <a></a>

Before WordPress 6.2, the block markup was typically updated using regular expressions or the DOMDocument class. Both have downsides. The former is tedious and prone to security issues, while the latter uses libxml2, which does not support HTML5.

The Tag Processor attempts to be an HTML5-spec-compliant parser that provides the ability in PHP to find specific HTML tags and then add, remove, or update attributes on that tag. It provides a safe and reliable way to modify the attribute on HTML tags. 

Key Make Posts/GitHub/Trac Issue(s): introduce HTML processor (57575) and an early look at the dev note for this feature. 

Control the search columns for WP_Query [plugin author]

`WP_Query` now supports a new `search_columns` argument, which allows developers to control which database columns are included when performing a search query via the `s` argument. By default, the `post_title`, `post_content`, and `post_excerpt` columns are included. The new argument allows developers to fine-tune the search without filtering and manually adjusting the SQL query directly.

The change also introduced the `posts_search_columns` filter hook, which provides an array of columns to search.

Key Make Posts/GitHub/Trac Issue(s):  Introduce the ability to control which fields are searched in a search query (43867)

All custom attachment filenames for wp_mail() [plugin author]

Nine years after the ticket was first opened, the `wp_mail()` function allows developers to customize the email attachment filenames. The changeset adds support for passing an associative array named `$attachments` where string keys are used as the filenames. Previous to this change, attachment filenames in outgoing emails could only ever be derived from their paths (passed in as a numerically indexed array of `$attachments`.

Key Make Posts/GitHub/Trac Issue(s): Allow custom attachment filenames for wp_mail (55030)

Check if a theme has a theme.json [plugin author] 

As part of broader performance work, a new `wp_theme_has_theme_json()` function is being introduced, making it available to extenders for public consumption. It is a conditional for checking whether the currently active theme or its parent has a `theme.json` file.

Key Make Posts/GitHub/Trac Issue(s): Replace the internal `WP_Theme_JSON_Resolver::theme_has_support()` with a public function (56975

Pushed to 6.3

Important note

For more information about what’s planned for 6.3, it’s recommended to review the Phase 2, Finale post from Matías Ventura, project architect of Gutenberg. It shares in some detail a look at what will be focused on for 6.3, alongside the remaining items on the phase 2 tracking issue

Table of contents block

Details for exclusion found here: https://github.com/WordPress/gutenberg/issues/42229 

Fonts API 

Details for exclusion found here: https://github.com/WordPress/gutenberg/issues/41479#issuecomment-1412161043 

Exposed template revisions

Details for exclusion found here: https://core.trac.wordpress.org/ticket/57704#ticket 

Enable appearance tools for any theme, unlocking more creative control [theme author]

Details for exclusion found here: https://core.trac.wordpress.org/ticket/57649 

dd HTML anchor support for dynamic blocks [plugin author]

Details for exclusion found here: https://github.com/WordPress/gutenberg/issues/48232


12 responses to “WordPress 6.2 Source of Truth”

  1. Very useful information. In my opinion, a slightly concise version of this makes a great post in WordPress Developer Blog, for a wider dissemination.

    • Glad to hear it! I dig your thinking. The good news is that this resource is meant for those working on posts for the developer blog too. A condensed version could be exactly that.

  2. […] years later and I’ve stumbled into the very edge of where WordPress is going next, sharing resources and updates as I go. It feels amazing to give back to a software and community that’s given […]

  3. […] The first release candidate (RC1) for the WordPress 6.2 development cycle has been postponed two days, to Thursday, March 9, and an additional fifth Beta release came out on Tuesday, March 7. Additional time and testing were needed to deal with a regression that came to light last week. The project is still on track for the final release of WordPress 6.2 on March 28. You can get a preview of what’s coming in 6.2 thanks to Anne McCarthy and Rich Tabor, who hosted a live demo. Anne has also written a detailed overview. […]

  4. […] The first release candidate (RC1) for the WordPress 6.2 development cycle has been postponed two days, to Thursday, March 9, and an additional fifth Beta release came out on Tuesday, March 7. Additional time and testing were needed to deal with a regression that came to light last week. The project is still on track for the final release of WordPress 6.2 on March 28. You can get a preview of what’s coming in 6.2 thanks to Anne McCarthy and Rich Tabor, who hosted a live demo. Anne has also written a detailed overview. […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: