WordPress 6.3 source of truth on a blue background in white writing.

Building off of my public 6.2 Source of Truth, I’m offering up the next edition for WordPress 6.3, set to launch August 8th, 2023. This is an early look — come back on July 25th, 2023 if you want a confirmed finalized version. I like to share early and often both to find areas of improvement, get feedback, and put power in the hands of those involved in helping get the wider WordPress community up to speed on what’s coming. In particular, I’d recommend staying up to date on the dev notes as those are coming out on a rolling basis at this point.

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.

Changelog

July 17th: initial public launch.

Overview 

WordPress 6.3 is set to launch on August 8th, 2023 bringing with it cohesive site editing thanks to expanded functionality, richer interfaces, and a focus on a polished experience. The culmination of this work enables you to build and launch your entire website seamlessly within the Site Editor. Create and edit pages or patterns, style every detail, manage your menus in isolation or within the context of templates, and navigate it all with the Command Palette. 

Taken together with WordPress 6.2, this marks the wrap of Gutenberg Phase 2 (Customization) and the beginnings of Phase 3, which will focus on collaborative workflows. As before, a new phase doesn’t mean work is done, and we will continue to make improvements to this powerful experience. 

To help set the stage visually, here are a few graphics to keep in mind to better explain some of the updated interfaces:

Annotated visual showing a separation between document title and command palette in the WordPress editor.
Annotated visual showing the difference between the Site and Detail Views in the Site Editor.
Annotated visual showing the difference between the Site and Edit View in the Site Editor.

Important links:

6.3 assets:

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

Tags

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.3

Complete Site Editing: new capabilities for Navigation, Pages, Styles, and Patterns

The Site Editor offers a more cohesive and feature-complete site editing experience with the ability to create and publish pages, switch style variations, create and manage patterns, see all your menus at a glance, and more, all without leaving the Site Editor. This is thanks to four new top-level items exposed in the Site View, building on what was started in WordPress 6.2:

  • Navigation: view all your menus and edit in a dedicated mode as you see fit without needing to find your individual menu in a specific template. 
  • Pages: view pages, publish new pages, switch between editing individual pages and the template powering the same page, and see all the important details of each. 
  • Styles: use the Style Book, explore style variations, and get quick access to open all styling options. 
  • Patterns: view, manage, and create patterns and template parts. 

Each of these top-level items is visible when in the Site View (dark gray sidebar), and, as you drill down into each section, you’ll notice each has a curated view of different details. For example, when viewing individual pages, you’ll see important details in that same sidebar, like publish status (example).

For Navigation, this release allows you to be able to view, manage, and modify your menus without having to find them in a specific template in the site editor. If you have a single menu, you’ll see it displayed directly in the sidebar. If there are multiple menus, they will all be listed with the option to drill into each as you want. For each, you’ll be able to edit in isolation to make the changes you’d like and have those changes propagate to all the places where that menu is used. Lastly, if you’re editing a template part that contains a Navigation Menu, that menu will be displayed in the sidebar for quick editing. Here’s a rundown of what to expect depending on the complexity and count of the menus:

  • Access all your Navigation Menus from the Site View.
  • Rename, Duplicate, and Delete Navigation Menus.
  • Make simple modifications to menu items, including reordering and deleting.
  • Edit your entire Navigation Menu in focus mode and have changes propagate to all instances. Note: you cannot add/edit existing items in the Site View itself.

For Pages, this marks an introduction to true content editing in the Site Editor, including a strong distinction between editing the template and the page, while allowing you to view either as you’d like within context. Just like with the Page editor, you can set status, publish date, and password all within the Site Editor. This new feature set adds helpful interface nudges, a navigation system that allows you to go back to editing a page from editing a template, and the additional context in the block settings sidebar to provide clarity while creating. This includes listing out dynamic pages, like Search or 404, which are powered by templates, to reduce confusion. 

For Styles, you’ll be able to browse style variations, use the style book, and get easy access to open the overall Style system from within the sidebar.

For the Patterns section, all your patterns, synced or not, along with your template parts, are available to manage, edit, and create. 

Visuals: Overview YouTube video, video of the library section, video of the pages section, image of the pages section, content vs. template split video, video overview of navigation changes.

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

  • Add the pages menu to the site editor (50463)
  • Site editor sidebar: add page details (50767)
  • Navigation on browse mode (50396) with individual issues linked within including add focus mode for Navigation Menus. (39286)
  • Try/publish in site editor (50767).
  • Add ability to set status, publish date and password in site editor. (51408)
  • Rename Library to Patterns (52102).

Track changes with revisions for Styles

With numerous options to make changes to your site’s styles, revisions have been added to the experience, allowing you to have a visual way to see what your site looked like at different points in time. The saved changes are displayed in a timeline showing when they occurred and who made the changes.

In the Styles interface of the Site Editor, you can now navigate through any revisions and browse how the site looked at that point in time. Any saved changes get shown in a timeline with when they occurred and who made the changes. 

Visuals: video demo, an image describing the feature.

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

Work faster with the Command Palette (and create your own commands) [plugin author] [end user] [site admin]

With the growing complexity and possibility of the Site Editor, a new tool was created to streamline the experience and help you get where you want to go: the Command Palette. When invoked either through a keyboard shortcut or in the interface in two places, you are presented with a list of possible actions to take, including things like:

  • Open Styles to open the Style editing interface.
  • View template parts to see a list of all template parts.
  • Add Custom CSS to directly open the CSS field in Styles.
  • Add a new page to quickly create just that – a new page. 

To access it, simply open the Site Editor and use the keyboard shortcut Cmd+k on Mac or Ctrl+k on Windows. You will also find it available when in the Site View in the sidebar by clicking on the search icon or in Edit View in the Title Bar. Here’s a list of all available commands:

  • Edit Template when editing a page.
  • Back to page to return to editing a page from a template.
  • Reset template
  • Reset template part
  • Reset styles to default
  • Delete template
  • Delete template part
  • Toggle settings sidebar
  • Toggle block inspector
  • Toggle spotlight mode
  • Toggle top toolbar
  • Toggle code editor
  • Toggle list view
  • Toggle fullscreen mode
  • Open editor preferences
  • Open keyboard shortcuts
  • Open CSS
  • Open styles revisions
  • Open styles
  • Learn about styles to trigger the welcome guide for Styles
  • View site
  • View templates
  • View template parts
  • Open Navigation Menus
  • Manage all custom patterns

To see the most up-to-date list, please view the files here. Of note, there is a current conflict as this keyboard shortcut is already in use so, depending on what’s in focus, the Command Palette may not be invoked. 

For any developers, keep in mind that the API is public, so you can explore adding your own commands to the interface. See the adoption approach for more information below.

Visuals: image, video demo.

Adoption approach: You can add your own commands to the interface with documentation available here.

Key Make Posts/GitHub/Trac Issue(s): Discussion on “Command Center” naming (50925), Command Center: Quick search for jumping to other pages or templates in the editor (48457), Mapping contextual commands (50407), Developer Note for 6.3

Block themes previews, powered by the Site Editor [end user] [site admin]

Previewing block themes is now available, allowing folks to experience what their site might look like before switching. It also offers a taste of the Site Editor, as upon previewing, you’re taken to a preview experience powered by the Site Editor. This work addresses a major adoption pain point, with folks now able to test out the world of block themes before considering switching. 

Visuals: video demo.

Key Make Posts/GitHub/Trac Issue(s): Add theme previews for block themes (50030)

Create your own patterns with optional syncing (& renaming reusable blocks) [theme author] [end user] [site admin]

The power of patterns continues to grow, and, with 6.3, you can now create your own with the ability to decide whether you want each instance to stay in sync with all other instances or not. Introducing the ability to create your own patterns and set sync status means that Reusable blocks as a concept are now known as Synced Patterns. These options are available whether you’re using the Site Editor or not! This is a big step forward in reducing the number of concepts folks need to keep on top of and unlocking functionality for folks to create their own patterns:

  • For any unsynced patterns, they are included in the Inserter with other patterns. Any edits to these patterns will only update for that specific instance after you insert it.
  • For any synced patterns, they will be listed under a new tab for synced patterns in the Inserter. Any edits to these patterns will update anywhere the pattern is used. 
  • Custom pattern categories are not currently possible but are being considered for a future release. You can read more here
  • You can edit, rename, duplicate, and delete patterns all from within the Patterns section.
  • Once you’ve set the sync status, you cannot change it after the fact. You will need to duplicate the pattern and create it again to change the sync status.
  • For block themes, all patterns are listed alongside template parts in the Site Editor > Patterns section, where you can enter an isolated editing mode to make changes.
  • For classic themes, the prior reusable block management page has been reused to house patterns in a list, similar to the Posts > All Posts view. 

Nudges are baked in throughout the experience to help guide folks to change in reusable block functionality. Technically speaking, these changes are mainly UI related, with the functionality of a reusable block working the same way. For an unsynced pattern, it’s the same collection of unwrapped blocks in wp_block CPT as a reusable block, the only difference being that the post meta entry identifies the sync type as unsynced. In terms of Template parts, keep in mind that themes can bundle “patterns” alongside “template parts,” while template parts are now just a special class of patterns for most practical purposes.

Finally, it’s worth calling out that a current restriction with reusable blocks now applies to synced patterns overall: if you apply alignment to a container block and convert it to a pattern, that alignment will be lost. This means if you set something as full width and convert it to a pattern, you’ll then need to add a Group block around the pattern after insertion to have access to change the width. You can see a broader discussion about this problem here.

Visuals: Pattern creation and insertion in the Site Editor demo.

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

  • Reusable blocks: Rename to ‘Patterns’ and add the option to also add a non-synced Pattern (51144)
  • Patterns: Add renaming, duplication, and deletion options (52270)

Edit your site without distractions [end user] [theme author] [site admin]

In WordPress 6.2, the distraction-free mode was introduced to the Post Editor. Building on this experience, this tool has now been added to the Site Editor, offering a more frictionless site-wide editing experience as well as delivering feature parity with other Editors. As with the Distraction Free Mode in the Post Editor, this works 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. This offers a nearly 1:1 preview of your site, a long requested piece of feedback. You can toggle this mode on/off as you’d like.

Visuals: video demo, youtube video demoing with the Command Palette. 

Key Make Posts/GitHub/Trac Issue(s): add distraction-free mode to the Site Editor (49175)

Prepare for dropping support for PHP 5 [site admin] [plugin author] [theme author]

Summary from the Dropping support for PHP 5 Make Core post: “Support for PHP 5 will be dropped in WordPress 6.3, scheduled for release on August 8th 2023. The new minimum supported version of PHP will be 7.0.0. The recommended version of PHP remains at 7.4 or greater.”

Adoption approach: If you need more information about PHP or how to update it, check out this support article that explains more and guides you through the process

Key Make Posts/GitHub/Trac Issue(s): Dropping support for PHP 5 Make Core post.

Additional Items for 6.3

General improvements and polish

Providing polish to the experience was a major focus of the 6.3 cycle, resulting in many of the items listed below and many more pulled out as individual highlights. Taken together, the aim is to level up intuitiveness and optionality across the entire editing experience. 

  • Site Logo: set, replace and reset directly from the sidebar to simplify the process of managing a site’s brand directly (49992).
  • Patterns: choose from a masonry layout in a new full screen modal that offers larger previews (49958, 49894). 
  • Site Editor: add hover animation to site editor canvas to indicate editability (48575).
  • Site Editor: simplify the template revert snackbar (50626)
  • Site Editor: remove screen flash when deleting templates or template parts for a calmer experience (48449).
  • Site Editor > Pages: add Paragraph prompt to Post Content when empty to orient folks on where to write. (50623)
  • Site Editor > Templates: redesign the table view for templates (50766).
  • Site Editor > Templates: update template titles balancing for clarity and brevity (51428).
  • Site Editor > Templates: update “Home” template name to “Blog home” (52048).
  • Featured Image block: add aspect ratio, giving you more precise control over how templates display images, including when building grid layouts where you want the featured images to be consistent (47854).
  • Featured Image block: new design for Replace and Remove buttons. (50269)
  • Post Template block: added block spacing and layout controls, making it possible to control the space between posts which was previously handled by Custom CSS (49050). 
  • Navigation block: enable Loginout block to have the option in a site’s menu (49160).
  • Image block: Display custom borders on placeholder, making it more obvious the impact of the colors involved when setting a featured image (49569).
  • Image block: allow dragging-and-dropping images from the inserter to image blocks (49673).
  • Image related blocks: replace “Image size” with “Resolution” in image size controls. (49112)
  • General interface: display device icon on “preview” and “view” buttons. (50218).
  • General interface: redesigned dimension controls that take up less space (50660).
  • General interface: add <ViewLink> component so you can quickly open any published content in a new tab. (50260)
  • Block editor: improve “switch to draft” placement. (50217)
  • Block editor: add prepublish nudge to upload external images (46014). 
  • Media and Video blocks: update media and video icons. (49523)
  • Block settings: rearrange items to highlight more common actions (50453).
  • Post Date block: addition of a Post Modified Date variation for the Post Date block that allows users to display the post’s most recent updated date (49111).
  • Spacker block: adapt flex child controls for Spacer (49362).
  • Optimize and condense unlinked padding / margin controls (49264).
  • Block variations added to block switcher, providing another option to switch from one variation to another (50139)
  • Group block: show visual cue when dragging a block over an empty Group block to better indicate where something might be placed (50826).
  • Post content block: removed from inserter in the Post Editor to prevent confusion (50620).
  • Embed block: margin support added (39384).
  • Columns/Column block: added support for blockGap allowing you to control block spacing (49526)
  • Post Excerpt block: Add excerpt length control (44964)
  • Block Supports: Add text columns (column count) to typography supports (33587)
  • Color palette component: updated to improve readability (50450).
  • oEmbed: Anghami support added (49850)
  • oEmbed: Add support for TikTok creator profiles (55784).
  • Sticky Position: enabling non-root sticky position (49321).
  • Writing Flow: allow Escape key to deselect blocks and selection during multiselection. (48904)

Introducing the Details block

This new block allows you to hide content until a reader chooses to engage with it with a simple open/close arrow icon. This covers a wide variety of use cases, from spoiler content in a movie review to the transcript of a podcast episode. 

Visuals: image.

Key Make Posts/GitHub/Trac Issue(s): Add details/summary block (45055)

Introducing Footnotes

After first being suggested in 2017 as a block, Footnotes are available, allowing you to add comments, citations, etc., to your content with ease at the bottom of your post or page. This works for both pages and posts. 

Visuals: video demo

Key Make Posts/GitHub/Trac Issue(s): Footnotes: try with post meta (51201), Footnotes: register meta field for pages (52024)

Patterns as template starters [theme author] [site admin]

After prior releases added template types support to the Patterns API, a new modal was added in the Site Editor for users when adding a new template. This modal allows users to build a new template from theme-registered template patterns, easing creation and offering another way for theme authors or site owners to delight users. This means theme authors can register custom patterns meant for specific template types (e.g., single post, 404, etc.), and they will appear in the start modal for users to benefit from. 

Visuals: selecting a custom pattern from the template creation flow video.

Adoption approach:  404 pattern registered for the 404 template would then enable that pattern to appear as an option to select from. 

Key Make Posts/GitHub/Trac Issue(s): Add: Patterns to the template start modal (47322)

Aspect ratio added to Images, allowing patterns to set and keep original dimensions [end user] [theme author]

With this control added you can set aspect ratio when creating patterns, allowing users to replace images while keeping the original dimensions and original design. This ensures the design integrity of the pattern while still offering users the ability to customize it to their liking with their own images. 

Visuals: video showing aspect ratio set and replacing images in a pattern.

Key Make Posts/GitHub/Trac Issue(s): Add image block aspect ratio control (51545)

List View enhancements: delete blocks, drag to all levels, updated drop indicator, and more [end user]

List View continues to be a powerful tool for navigating complex content, and this release brings some necessary polish to the experience. To make the improvements easier to get a sense of at a glance, they have been marked as UX, Bug Fix, and Feature. 

  • [UX] Blocks being dragged are now still visible as they are being dragged to better indicate what’s being acted upon. 
  • [UX] Update drop indicator line to be thicker and with a white border to make it easier to see and use. 
  • [Bug Fix] Allow drag and drop into collapsed container blocks.
  • [Bug Fix] Allow blocks to be dragged into empty Group blocks. 
  • [Bug Fix] Update drop indicator to support RTL languages. 
  • [Bug Fix] Drag to every layer of content.
  • [Bug Fix] Refactor to improve accessibility for assistive technologies. 
  • [Feature] Delete blocks using your keyboard while selecting in List View. 

Visuals: quick demos of a few new changes

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

  • List View: Try showing blocks that are dragged (no longer hide them) (51724)
  • List View: Update drop indicator line positioning to support rtl languages (51284)
  • List View: Allow deleting blocks using keyboard (50422)
  • Group Block: Allow blocks to be dragged onto it in its placeholder state (49361)
  • List View: Append when dragging into collapsed blocks (50936)
  • List View: Allow dragging outside the immediate area by passing down a dropZoneElement (50726)
  • List View: Allow dragging to all levels of the block hierarchy (49742)
  • List View / Block Draggable: Fix scroll to top issue when dragging the second last block in the list (50119)
  • List View: Update drop indicator width to be aware of scroll containers (49786)
  • List View: Update drop indicator line to be 4px high with a white border (49462)
  • List View: Allow dragging underneath collapsed non-empty container blocks (49390)
  • Group Block: Allow blocks to be dragged onto it in its placeholder state (49361)
  • Refactor ARIA attributes to improve accessibility for assistive technologies. (48461)

Top toolbar enhancements [end user]

Top toolbar is an option in settings that, when enabled, allows you to access all block and document tools in one place at the top of the editor. This option was enhanced to add parent selectors for nested blocks, options when selecting multiple blocks, and a new interface embedded into the title bar complete with new functionality in mind. 

Visuals: before and after demo comparing 6.2 and 6.3

Key Make Posts/GitHub/Trac Issue(s): Updates the behavior of the top toolbar fixed setting (49634)

Enjoy deep linking to the exact Styles > Blocks screen [end user] [theme author]

When using the Styles > Blocks section, if you click on an individual block in the editor, you’ll automatically be taken to those specific block settings in the Styles interface. When combined with the Style Book feature from 6.2, this makes for faster and more intuitive editing. 

Visuals: video demo.

Adoption approach: read about how you can use the Style Book for styling block themes.

Key Make Posts/GitHub/Trac Issue(s): Global Styles: Enable deep linking to the selected block only in the Blocks screen. (50708)

Resize the Site Editor to preview how your site will appear at different sizes [end user]

You now have the ability to resize your site editor, allowing you to preview how it will appear on smaller screens, such as mobile devices. If you resize to engage the full screen, you’ll automatically be placed in Edit View to begin editing. 

Visuals: video demo 

Key Make Posts/GitHub/Trac Issue(s):  Update frame resizing (49910)

Open to the current template when selecting “Edit Site” [end user]

When viewing the front end of your site while using a block theme, you can now select “Edit Site” and the current template powering the content you’re viewing will be opened. Previously, this edit option would open the overall Site Editor. This change offers a big workflow gain and solves a longstanding pain point. 

Key Make Posts/GitHub/Trac Issue(s): Admin bar: Edit site link should open the current template (37850)

Warning added to prevent removal of critical blocks in the Site Editor [end user] [site admin]

Certain blocks in the Site Editor are more critical than others to ensure the editing experience works as expected. While lots of work has gone into improving placeholders and adding things like welcome guides to better onboard folks, mistakes still happen. To aid folks and ensure that if they do want to remove a block, they understand the potential impact, warnings have been put in place for both the Post Content and Query blocks upon initial removal. Folks are still able to proceed if they’d like after confirming. 

Visuals: video demoing the warning and the ability to still remove

Key Make Posts/GitHub/Trac Issue(s): Warn users prior to block removal site editor (51145)

Streamlined link editing [end user]

Various enhancements to link editing coalesce to offer a more streamlined experience from smaller details, like adding a checkbox rather than a toggle for opening a new link in a tab, to larger changes, like simplifying the flow of editing links. This included an accessibility review to ensure best practices and is part of broader work to ultimately improve the Navigation block experience.

Visuals: link editing before with 6.2 video and link editing after video for comparison. Image of new flows.

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

  • Use checkbox for Open in new tab within Link Control (50961
  • Reinstate Text control outside of settings in Link Control (50957)
  • Link Control require user to manually submit any changes (50668)
  • LinkControl: Improve Edit State (50890

Cover block updates: text color, layout, and border support [end user] [theme author]

The Cover block has added support for text colors, all border-related design tools, and flow layout. Adding these options to this well loved and used block will help reduce the need for custom block styling and make it simpler to customize overall. For example, just by adding text color support, it will only take quick changes to a single setting to customize the colors of all inner blocks. With layout controls, the Cover block now works the same as the Group block with its layout handling. For 6.3, it will only support the flow layout and is set to a constrained width by default.

Visuals: image of text color controls, image of layout controls.

Adoption approach: Theme authors should test their themes against these changes. In the past, some have had to work around the layout limitations of the Cover block, and the block’s support of the standard layout system may override custom implementations.

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

  • Add text color controls and borders support (41153).
  • Add text color controls (41572).
  • Simplify cover block description. (50355).
  • Add constrained/flow layout to Cover block (45326).

Layout updates, including stabilizing block support for layout, grid layout, and more [theme author] [plugin author]

This was pulled and summarized from a dev note of these changes.

  • Block support for layout has now graduated from experimental to stable. Everything works the same; the only difference is that when adding block support for layout in block.json, its name is now layout instead of __experimentalLayout.
  • The CSS output for the margin styles of children of constrained and flow (default) layout containers has changed. The generic rules used to have a specificity of 0,1,0 for all blocks; they have now changed to 0,0,0 for all blocks with an extra 0,2,0 rule applied only to the first and last blocks in the container.
  • A new classname is added to the inner wrapper of all blocks with layout, comprised of block classname + layout classname, e.g.: .wp-block-cover-is-layout-constrained.
  • The layout definitions object, which stores base styles for the layout block support, has been removed from the core theme.json (settings.layout.definitions) and moved into the internal layout support files. 
  • A new grid layout type is available, based on CSS Grid, and defaulting to an auto-fill approach with configurable column width. To create a block with a grid layout, the following needs to be added in the supports object of the block’s block.json.

Adoption approach: Please review the dev note for more details.

Key Make Posts/GitHub/Trac Issue(s): Layout updates in the editor for 6.3

Duotone updates, including global control within Styles and controls in block sidebar [end user] [theme author]

Previously, you could only set a duotone filter globally by manually making changes within the theme.json file. Now, you can use the Styles interface to control blocks that support this feature, giving design control over every instance. When editing individual blocks, Duotone controls will be listed in the block sidebar settings, along with the block toolbar, to better surface the options available. 

Duotone presets are now stored as slug values, instead of hard-coded color values (i.e. #FFFFFF). The result is that using the preset means that Duotone options are no longer locked to a specific theme or theme variation. If you apply a Duotone option and then later change a theme to another that uses the same slug value, the new theme’s Duotone will now take effect. 

Finally, Duotone styles are now generated using the WordPress Style Engine, meaning that CSS is generated as part of the block supports CSS — rather than inline. 

Visuals: image of Duotone Styles interface

Key Make Posts/GitHub/Trac Issue(s): Add Global Styles controls for blocks that support duotone (48255), Use Duotone presets in block duotone attributes (48318), Use the style engine to generate CSS for Duotone (48281), Duotone controls in the block sidebar (49838)

New Core patterns, with a Curated vs. Community category in the pattern directory 

In line with this major release, a set of new Core patterns are available automatically for all to use from the Inserter. These include new banner, text, and image based options: 

To make it easier to find the curated patterns provided by Core, a new filter was also added to the Pattern Directory so you can easily search for Curated (Core provided) or Community patterns. 

Visuals: curated vs. community filter image

Adoption approach: To fully remove patterns bundled with WordPress core from being accessed in the Inserter, the following can be added to your functions.php file: remove_theme_support( 'core-block-patterns' );

Key Make Posts/GitHub/Trac Issue(s): Add select for filtering the pattern directory (580)

More visual and detailed template selection [end user]

The add new template flow was updated with a larger modal selection process to better accommodate more verbose descriptions of templates. This more visual experience helps distinguish the different template options and the subsequent steps, depending on selection. 

Visuals: GIF of the new experience

Key Make Posts/GitHub/Trac Issue(s):  Update the add template menu. (50595, 51806)

Standardize the experience of editing individual blocks with global block options [end user] [theme author]


When editing Styles for an individual block, the various options used to be listed in various drill-down options, creating a very different editing experience than when you’re editing an individual block of the same type. To provide consistency in the experience so, whether you’re editing all blocks of the same type or an individual instance, the individual block editing experience was brought to the Styles section. 

Visuals: Image of the panel before vs. image of the panel after

Key Make Posts/GitHub/Trac Issue(s):   Unify the global block styles panel with the block inspector panels (49428)

Style captions via the Styles interface [end user] [theme author]

For a while now, theme authors have been able to create custom styles for <caption> elements directly via theme.json. The latest Gutenberg update brings those design options to the Styles interface, allowing creators and users to customize captions without touching code.

Visuals: image

Key Make Posts/GitHub/Trac Issue(s): Global Styles: Caption element UI controls for color and typography (49141)

Implement spacing presets with the Spacer block [theme author]

Building on spacing presets being added to Dimension controls in WordPress 6.1 allowing theme developers to employ fluid spacing, spacing presets were added to the Spacer block’s height control. This provides an added layer of flexibility over how spacing is applied thorughout a site and enables fluid Spacer blocks. 

Adoption approach: You can learn more about fluid spacing and typography in the article Intrinsic design, theming, and rethinking how to design with WordPress over on the WordPress Developer Blog.

Key Make Posts/GitHub/Trac Issue(s): Add spacing presets to the spacer block (44002)

Loading state improvements and animations for the Site Editor

Rather than loading the Site Editor in parts, the Site Editor is now loaded behind the scenes and displayed once it’s finished loading. While subtle to some, these improvements help make entering the Site Editor less jarring and more cohesive, showing a fully loaded state before you start interacting with your content. Alongside the improvements to the loading state, additional animation related changes and general fixes, like removing a screen flash upon deleting templates and template parts, offer a refined, calmer workflow. 

Visuals: before video and after video with these changes. 

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

Choose which blocks are prioritized within container blocks [plugin author] [site admin]

With the introduction of a new API, container-type blocks can prioritize which nested blocks appear at the top of the Inserter as well as when using the slash inserter (/). This added control provides another way to curate the experience of those using your blocks. For example, you might have a container block for a Form with specific nested blocks that add additional functionality and make the most sense when used within the overall container. This ensures those blocks are prioritized for ease of use and discovery. 

Adoption approach: You can use this feature by passing an array of block or block variation names via the inserterPriority parameter of the <InnerBlocks> component. For example, you can add this: prioritizedInserterBlocks: [ 'core/site-logo' ] to the Group block here.

Key Make Posts/GitHub/Trac Issue(s):  Add new API to allow inserter items to be prioritized (50510), Integrate prioritizedInserterBlocks API to slash inserter (50658)

Performance enhancements, including image performance enhancements 

At a high level, this release includes more than 170 performance-related updates, including adding defer and async support to the WP Scripts API and fetchpriority support for images. Optimizations were made to block template resolution (with a 15% load time reduction for block themes), image lazy-loading, and the emoji loader, all of which benefit LCP performance. Support for PHP versions 8.0, 8.1, and 8.2 has continued to improve. 

Specifically for images enhancements, several changes improve load time performance for content with images. This impacts the Largest Contentful Paint metric (aka “LCP”). At a high level, the changes are as follows summarized from a dev note on the topic:

  • WordPress now automatically adds the fetchpriority attribute with a value of “high” to the image it determines most likely to be the “LCP image”, i.e. the image that is the largest content element in the viewport. The attribute tells the browser to prioritize this image, even before it has computed the layout, which typically improves LCP by 5-10%. See the original proposal post for additional context.
  • Changes have been done to improve the automatic handling of lazy-loading via the loading attribute to more reliably detect when to omit the attribute from some images. This builds on efforts starting in WordPress 5.9 with the remaining issues fixed for 6.3. 

From the same dev note, please note that a new function wp_get_loading_optimization_attributes( string $tag_name, array $attr, string $context ) is introduced in WordPress 6.3, which returns an associative array of additional attributes and their values. This provides a central place to get HTML attributes that potentially improve the load time performance of images. For now, the function can only return a fetchpriority or loading attribute (or neither if not applicable), though this may be enhanced with other performance-related attributes in the future. With the new function being used consistently anywhere images are rendered in WordPress core, support for customizing is also improved. As a result of this work too, a few existing functions are being deprecated as part of the WordPress 6.3 release:

  • wp_get_loading_attr_default() is superseded by the new function and should not be used anymore. 
  • wp_img_tag_add_loading_attr(), as this function is superseded by a new wp_img_tag_add_loading_optimization_attrs(), which also encompasses the fetchpriority enhancement. 

Adoption approach: Read more in this dev note on image related performance improvements

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

  • Conditionally skip lazy-loading on images before the loop in classic themes (58211)
  • Improve clunky logic to inject `loading` attribute in the get_the_post_thumbnail() function (58212)
  • Increase default for wp_omit_loading_attr_threshold to 3 (58213)
  • WordPress puts “loading=lazy” on first image on archive page – wp_get_loading_attr_default bug (56588)
  • Featured images within post content cause lazy-loading logic to apply incorrectly (58089)
  • Images before main query loop are not counted towards lazy-loading threshold (58635)
  • Emoji loader script causes ~100ms long task (58472)
  • Improve get_block_templates performance (4097)

Fluid typography enhancements [theme author]

Improved minimum font size calculations

A more refined handling of fluid typography arrives with 6.3 thanks to using a logarithmic scale factor to calculate a minimum font size for smaller screens. Essentially, the scale tapers out as the font size increases. With reliable scaling calculations, designers have more typographical freedom and can better rely on the built-in responsiveness of their designs. 

For any theme authors, you should test your theme designs to ensure that this update doesn’t negatively impact its typography. Of note, there is still some work to do on how particularly large font sizes are rendered (see this comment for context), but the majority of use cases should benefit. 

Leveraging the theme-defined “wide” size

An enhancement to the fluid typography system now uses the layout.wideSize defined in theme.json to set the max viewport width. Essentially, this defines the point where fonts will stop growing larger. Before, it was set at 1600px, which is generally much wider than the wide size a theme will define.

Visuals: demo showing large fonts scaling down.

Adoption approach: must have opted into fluid typography in a block theme. 

Key Make Posts/GitHub/Trac Issue(s): Fluid typography: use logarithmic scale factor to calculate a min font size (49707), Fluid typography: use layout.wideSize as max viewport width (49815).

Add allowedBlocks attribute for Group and Media & Text [plugin author] [theme author] 

This is pulled from What’s New for Developers May 2023.

Support for an allowedBlocks attribute now allows you to limit inner blocks for both the Group and Media & Text blocks. With this change, you can further curate the editing experience for your users via custom implementations or patterns.

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

  • Group: Add allowedBlocks attribute and pass it to innerBlockProps. (49128)
  • Media & Text: Add allowedBlocks attribute and pass it to innerBlock. (49981)

Customize CSS selectors with the Selectors API [plugin author]

This is pulled from What’s New for Developers May 2023.

The Selectors API allows you to customize the CSS selectors used when your block styles are generated. This change means fewer workarounds and more fine-grained control over your block. You can now define your block’s selectors in block.json by setting the selectors object. By default, the root selector is your block’s generated class. You can target the root, specific features (e.g., color), and even sub-features (e.g., typography > text-decoration). Here is a block.json example of using the Selectors API:

{

"selectors": {

"root": ".your-block-selector",

"color": ".your-block-selector > div",

"typography": {

"root": ".your-block-selector h2",

"text-decoration": ".your-block-selector h2 span"

}

}

}

Defining custom selectors allows WordPress to automatically generate the appropriate CSS for the block, as shown below:

.your-block-selector > div {

color: var( --wp--preset--color--contrast );

background: var( --wp--preset--color--base );

}

.your-block-selector h2 {

font-family: var( --wp--preset--font-family--primary );

}

.your-block-selector h2 span {

text-decoration: underline;

}

Adoption approach: For a full overview, visit the Selectors API documentation in the Block Editor Handbook.

Key Make Posts/GitHub/Trac Issue(s): Block.json: Refactor and stabilize selectors API (46496), What’s New for Developers May 2023

Post Editor iframed for blocks with version 3+ [plugin author]

Building on prior work, for 6.3, the Post Editor will be iframed if all registered blocks have a Block API version 3 or higher. Adding version 3 support means that the block should work inside an iframe, though the block may still be rendered outside the iframe if not all blocks support version 3. It is worth noting that the Site Editor and Page Template Editor have always been iframed, alongside with block and pattern previews, and will continue to be iframed regardless of Block API version.

In order to make adoption easier, all assets (styles and scripts) added through the enqueue_block_assets PHP filter will now also be enqueued for the iframe. 

Please try to make your blocks compatible and report any bugs/issues you have. In a future version of WordPress, the editor content will load within an iframe regardless of the Block API version.

Adoption approach: See this PR for more information.

Key Make Posts/GitHub/Trac Issue(s): For more information about why we are iframing the editor content, see this prior Make post.

Add the style variations filter to your block theme to be found in a new variations filter in the Theme Directory [theme author]

To help folks find block themes with style variations, the style-variations tag has been added as a filter to the Theme Directory. There aren’t many themes with the tag yet, so please consider both adding style variations and this tag! 

Adoption approach: Ensure your theme has at least one style variation, and then add a style-variations tag in your block theme’s style.css file header.

Key Make Posts/GitHub/Trac Issue(s): What’s New for Developers May 2023.

New slot for the Template sidebar [plugin author]

A new PluginTemplateSettingsPanel slot lets you add custom controls to the Template sidebar in the editor. This can be helpful if you want to do things like add some instructional text to a template, like a link to a support doc. 

Adoption approach: Below is a very simple code example that adds “Hello, World”:

import { MyTemplateSettingTest } from '@wordpress/edit-site';

const MyTemplateSettingTest = () => (

<PluginTemplateSettingPanel>

<p>Hello, World!</p>

</PluginTemplateSettingPanel>

);

Here’s a more complex example from WooCommerce that adds a way to convert back to a classic template.

Key Make Posts/GitHub/Trac Issue(s): Introduce new PluginTemplateSettingPanel slot (50257)

Set language and text direction options as part of RichText formatting [end user]

Sometimes, when writing, folks might make parts of their text in different languages, whether to offer an online version of a menu in a few different languages or specific instructions. To help assistive technologies like screen-readers properly understand what language the text is in and use the proper pronunciation when reading the text, attribute options have been added for both. This is a big win to help folks write more accessible content. 

Visuals: video demo of setting attributes.

Key Make Posts/GitHub/Trac Issue(s): Add lang and dir attributes to text-formatting tools (49985)

Script Loader: Add support for HTML 5 “async” and “defer” attributes

From trac ticket 12009:

“This allows developers to register scripts with an intended loading strategy by changing the $in_footer parameter of wp_register_script and wp_enqueue_script to an array that accepts both an in_footer and strategy argument. If present, the loading strategy attribute will be added to the script tag when that script is printed to the page as long as it is not a dependency of any blocking scripts, including any inline scripts attached to the script or any of its dependents.”

Key Make Posts/GitHub/Trac Issue(s): Add support for HTML 5 “async” and “defer” attribute (12009).

Improvements to the Caching API [plugin author]

This was pulled and summarized from a draft dev note of these changes.

Change cache groups for all query caches

“In previous versions, the query results were stored in the same cache group as the corresponding object. For instance, post query data would be stored in the posts group. However, starting from WordPress 6.3, this approach has been modified. The update introduces new cache groups with a prefix, offering developers greater control over the handling of objects within these groups. Core functionality now enables developers to specify the expiration time for a cache group, allowing them to set a duration of, for instance, one day.”

New utility function wp_cache_set_last_changed()

“A new utility function, `wp_cache_set_last_changed()`, has been introduced in the WordPress core. This function is utilized to update the last updated value in the cache. It complements the existing wp_cache_get_last_changed() function, which was added in WordPress 4.7. In the core codebase, all instances where the last changed value was updated have been replaced with calls to this new function.”

Validation added to `_get_non_cached_ids()` for with invalid ids

“The _get_non_cached_ids() function has been updated to perform validation, ensuring that only an array of unique integers are passed as input. In the previous version, no validation was conducted on the input, leading to potential validation errors and even PHP fatal errors.”

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

  • Dev note draft
  • WP_Query cache memory leak (57625)
  • Warn about calling `_get_non_cached_ids()` with invalid ids (57593)
  • Avoid reaching inside the object cache object in tests (31463

Improved Caching for Database Queries in WP_User_Query [plugin author]

This was pulled and summarized from a draft dev note of these changes.

“In WordPress 6.3, significant enhancements have been made to the WP_User_Query class, specifically regarding caching of database queries. The implementation of query caching in WP_User_Query aligns with that of other query classes. Once a query is executed, the resulting database queries are cached, and subsequent queries with the same parameters will retrieve the data from the cache. This caching behavior, when combined with persistent object caching, ensures that the database query won’t be executed again until the caches are invalidated, leading to a substantial reduction in overall database queries.It’s important to note that starting from this version onward, all calls to WP_User_Query will be automatically cached by default. However, if you wish to disable query caching for specific queries, you can simply set the cache_results parameter to false, as demonstrated in the following example:

$args = array(

   'number' => 50,

   'cache_results' => false

);

$query = new WP_User_Query( $args );

Alternatively, you can globally disable caching by using a filter, as shown below:

function disable_caching( $wp_user_query ) {

   $wp_user_query->query_vars['cache_results'] = false;

}

add_action( 'pre_get_users', 'disable_caching' );

It’s worth noting that caching will be disabled for user queries that utilize the field parameter and request more than 3 fields. This decision is made to prevent cache values from becoming excessively large and to avoid filling up caches with data unlikely to be reused.”

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

Improvements to the metadata API in WordPress 6.3 [plugin author]

Summarized from this Dev note:

“WordPress 6.3 brings significant improvements to the metadata API, enhancing the lazy loading capabilities for term, comment, and site metadata. These enhancements aim to improve performance, optimize code readability, and ensure a consistent developer experience across different metadata types.”

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

Rollback for failed manual plugin and theme updates [plugin author] [site admin] [theme author]

Summarized from this Dev note:

“Should the manual plugin or theme update process fail, the rollback feature will automatically restore the previously installed version to ensure the website remains available to its users. hen updating a plugin or theme, the old version of the plugin or theme is moved to a wp-content/upgrade-temp-backup/plugins/PLUGINNAME or wp-content/upgrade-temp-backup/themes/THEMENAME folder. When a rollback occurs, the user should simply see that there is an update pending and their site should still be working.”

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

5 responses

  1. […] all the WordPress News outlets, Anne McCarthy provided a Source of Truth for WordPress 6.3 document, actually it’s more like a book with over 8,000 words. In it, they list every single […]

  2. […] of a release into a single document, and have begun sharing it publicly the last few releases (6.3 Source of Truth). I’m not going to go into detail around how those resources are created but suffice it to say […]

  3. […] WordPress 6.3 Source of Truthhttps://nomad.blog/2023/07/17/wordpress-6-3-source-of-truth/ […]

  4. […] off of both the public 6.2 Source of Truth and 6.3 Source of Truth, I’m offering up the next edition for WordPress 6.4, set to launch November 7th, 2023. This […]

  5. […] off of both the public 6.2 Source of Truth, 6.3 Source of Truth, and 6.4 Source of Truth, I’m offering up the next edition for WordPress 6.5, set to launch March […]

Leave a comment

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

More details

Expect to read about travel, mental health, community, WordPress, surrogacy, and more.