The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
In this dev notedev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase., you will find a collection of smaller changes to existing features and deprecated APIs and components.
Table of Contents
Fluid typography minimum font size
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.
How to use the minimum font size in your theme
With the minFontSize property set to 15px in the above example, the output of a paragraph blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. set to 15px font size will be as follows with no fluid rules applied:
<p style="font-size:15px">A paragraph at 15px</p>
The output for a paragraph block set to 16px will result in the fluid rules being applied, but with 15px as the minimum font-size:
A new Layout feature was added that allows the children of container blocks with Flex type layout to provide controls to change their relative size within their parent block. This feature can be added to the container block in its __experimentalLayout settings in block.json, like so:
The controls for the child blocks will then be displayed under the “Dimensions” panel in the block sidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.. If the parent’s orientation is horizontal the control will appear as “Width”, and if it’s vertical it will be “Height”.
Three options are available in this control:
“Fit” is the default, and means the block will take up only as much space as its intrinsic dimensions;
“Fill” makes the block stretch to take up all remaining available space within its parent;
“Fixed” allows for setting a fixed width or height (depending on the parent’s orientation) in px, %, em, rem, vw or vh units.
wp-block-heading CSSCSSCascading Style Sheets. class added to every Heading block
In WordPress 6.2, the h1-h6 elements added via the heading block have a brand new wp-block-heading CSS class.
This change enables styling the heading block differently from the regular h1-h6 elements. For example, the following theme.json would add a blue background to all h1 elements and a pink background to only the h1 elements added via the cover block:
WordPress 6.2 introduces a new method called wp_theme_has_theme_json() that returns whether the active theme or its parent has a theme.json file. The goal is to provide 3rd parties with a public APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. they can use to query the active theme for this information. It deprecates the private API WP_Theme_JSON_Resolver:theme_has_support(). Details are available in the PR #45168
Edit block style variations from theme.json
This new theme.json API allows existing coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. block style variations to be styled directly from the theme.json file. It does not currently allow adding new variations. Styles should be added as follows:
Each variation should be targeted by its name, which can be found in the block’s block.json file, under “styles”.
wp_get_global_settings => the result is now cached per request (also known as non-persistent cache), so it’s faster.
wp_get_global_stylesheet => the result is now cache per request (aka non-persistent) while it was cached using 1-minute transient. This caused bugs (the changes in the site editor were not reflected in the front until 1 minute later) that are fixed now.
wp_get_global_styles_svg_filters => the result is now cached per request (aka non-persistent cache) while it was cached using 1-minute transient. While this did not cause any known bugs, it was updated for due diligence.
More details are available in this tracking issue #45171
When users switch themes, the navigation on their site should stay the same, regardless of whether it is a block theme or a classic theme. To enable users to switch from classic themes to block themes, we have made some further refinements to the way that the navigation block imports menus from classic themes.
If a site has a classic menu, and has not yet created a navigation using the navigation block, then the navigation block will automatically import a classic menu to use. Many classic themes (for example TT1) use the primary name and slug as a convention for its main menu location. If a site has a classic menu defined at this location, then the navigation block will import this one. If not, then it will use the most recently created classic menu.
The conditions for deciding which classic menu to import are:
If no wp_navigation menus exist
If the theme has a menu defined at location called primary, use that otherwise
Use the most recently created classic menu
If these conditions are met, the navigation block will display the classic menu, automatically converting it to navigation menuNavigation MenuA theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site.. More details via the PR (#45976)
Disable Openverse categoryCategoryThe 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging. in new Media tab
In addition to Blocks and Patterns, with WordPress 6.2 the Inserter shows a new Media tab, giving the user fast access to the images, videos, and audio files in the Media library. It enables users to browse and search the Openverse catalog for Creative Commons licensed images. The Openverse media category can be controlled with a new public block editor setting(enableOpenverseMediaCategory). The default is to show this category, but it can be turned off by updating this setting’s value. (#47404)
In WordPress 6.2 the behavior of removeBlock() changed. Until then, when a block was removed, the previous block was selected and gained focus in the user interface. Occasionally, if there wasn’t any previous block available, it resulted in focus loss, which is a particularly difficult experience when using a screen reader.
With this update, the behavior of the removeBlock() action was changed to select the first parent instead. For a developer writing Custom Blocks or otherwise depending on the result of the removeBlock action, this might require an update to their code, to account for the possibility that sometimes the parent is selected on block removal. There is a way to opt-out of this behavior by passing false as the second argument to removeBlock() function.
Bug fix: Global Styles for adminadmin(and super admin) users on multi-site
In WordPress 6.1 the layout block support was refactored to output CSS values for block spacing, with additional layout controls within global styles being made available. This resulted in a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. for admin users without the unfiltered_html capability (e.g. admin users within a multisitemultisiteUsed to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site instance) where block spacing or layout content sizes were not saved when updated within the global styles interface. (#45520) The cause was that within the Theme JSON class, theme.json values are filtered for users without the unfiltered_html capability based on a lookup to a direct CSS property, e.g. margin or padding. For layout features, the styling rules are stored in indirect properties that don’t directly map to a real CSS property, e.g. blockGap and contentSize.
For WordPress 6.2 (and backported to WordPress 6.1.2) this issue is resolved by the Theme JSON class storing a list of indirect properties (INDIRECT_PROPERTIES_METADATA), with a mapping between a CSS property to use for validation, and the path to the indirect property as stored in theme.json. In this way, blockGap will be validated against the CSS gap property, and contentSize against the CSS max-width property, etc.
For themes using layout features, no changes are required, as the bug fix is an internal implementation detail of how Theme JSON styles are validated and output.
The formatting prop have been deprecated in WordPress 5.4 release and is not available anymore starting from WordPress 6.2. If you want to define the available formats when using the RichText component, use the allowedFormats prop instead. (#46106)
The deprecated useAnchorRef hook from the @wordpress/rich-text package will not be deleted in WordPress 6.3, as initially planned. (#45302)
DateTimePicker deprecated prop removal postponed to 6.3
The removal of the __nextRemoveHelpButton and __nextRemoveResetButton props on the DateTimePicker component in @wordpress/components, initially scheduled for GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ 14.6, has been postponed to the Gutenberg 15.8 release. (#46006)
In WordPress 6.2, non-strings as block descriptions have been deprecated.
While there could be niche edge cases that found non-string descriptions useful, contributors discovered that this could cause unexpected bugs and thus have decided to deprecate it. This makes it clearer that the recommended type for block descriptions should be of type string only.
Removal of the Navigation Editor screen and associated package
The Navigation Editor screen was an experimental feature of the Gutenberg PluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party that contributors worked on as a potential replacement for the classic Menus screen using a block-based paradigm. The code for this feature existed within a dedicated @wordpress/edit-navigation package.
As the Navigation project has evolved, however, the requirement for a dedicated screen has become less pronounced, with features originally proposed for/included within the screen being incorporated into the Navigation block itself.
During the 6.1 cycle, due to lack of contributions, the experiment was informally deprecated in the Plugin by being removed from the Experiments screen in the Gutenberg Plugin settings page.
With the arrival of list view editing for the Navigation block in WordPress 6.2, menus can now be edited away from the editor canvas, and therefore it is finally time to formally remove the experiment from the codebase.
The @wordpress/edit-navigation package has now been removed from the Gutenberg repository and then associated package unpublished from npm. (#47055)