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.
Please leave your feedback about the schedule and release squad size in the comments by July 19th.
If you are interested in participating in WordPress 6.7’s release squad as a lead, please show interest in the comments below, clearly specifying the role.
With WordPress 6.6 almost ready, it’s time to start planning WordPress 6.7 so that the release leads can participate from the start of the release cycle.
The timeline for the third release of 2024 takes into consideration WordCampWordCampWordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. US in mid-September. To avoid having major milestones (Beta1, RC1) conflictconflictA conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. with flagship events, this proposal suggests having WordPress 6.7 BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 after WordCamp US with a small buffer in between.
According to the schedule proposed below and the GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ release cadence, WordPress 6.7 would include up to Gutenberg 19.3 for a total of 8 Gutenberg releases.
Proposed WordPress 6.7 Schedule
Milestone
Date
Alpha (trunktrunkA directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. open for 6.7 release)
June 25, 2024
Last Gutenberg RCrelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). before Beta 1
September 18, 2024
Beta 1
October 1, 2024
Beta 2
October 8, 2024
Beta 3
October 15, 2024
Release Candidaterelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1
October 22, 2024
Release Candidate 2
October 29, 2024
Release Candidate 3
November 5, 2024
Dry Run
November 11, 2024
WordPress 6.7 General Release
November 12, 2024
Please leave your feedback about the schedule in the comments by July 19th.
Release Leads call for volunteers
With the recent switch to using the microsite as the base for the About page, some of the Marcomms lead’s responsibilities increasingly overlap with the Design Lead. Considering recurring feedback about the excessive number of release roles, we propose experimenting with combining the Marcomms and Release Coordination roles. This new consolidated role would absorb the duties of the Marcomms lead, streamline communication, and enhance collaboration, addressing the feedback on role complexity and redundancy while improving overall efficiency.
Leads in the squad should have proven experience and availability during the release cycle. Less experienced folks and newcomers are still welcome to followalong the process in preparation for future releases.
Some roles have already been filled by volunteers from the previous call, while others remain open. The TBDs in the list below indicate the number of spots that still need to be filled.
Release LeadRelease LeadThe community member ultimately responsible for the Release.: Matt Mullenweg
Release Coordination and Communications: TBD
CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Tech Leads: Peter Wilson, Kira Schroder
TriagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Leads: TBD
Documentation Leads: TBD
Test Lead: TBD
Design Lead: TBD
Performance Lead: TBD
Default Themes Lead: TBD
All release decisions will ultimately be this release team’s to make and communicate while gathering input from the community.
As a reminder, if you are interested in participating in WordPress 6.7’s release squad as a lead or as a cohort, please show interest in the comments below, specifying the desired role and level of involvement (lead/cohort).
The most recent default theme, Twenty Twenty-Four, has been praised for its design and flexibility. It is time to start thinking about Twenty Twenty-Five, which will be released with WordPress 6.7 in November 2024. Twenty Twenty-Five will be a block theme showcasing new Site Editing features introduced this year.
Share your ideas
What types of sites do you want to create with the theme?
What problems do you need the theme to solve to be able to create these sites?
Is there an existing feature that you want the theme to support?
Please add your comments below. Feedback and ideas will be collected continuously. You are also welcome to participate in the discussions on the GitHub repository and in the #core-themes channel on WordPress SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
Note: Ideas won’t necessarily guarantee inclusion in Twenty Twenty-Five but might be considered when creating other community themes.
More information will be provided later for those who would like to contribute to the theme with design, code, testing, or documentation.
The weekly WordPress Dev Chat meeting is a tradition that dates back to the days when WordPress contributors primarily communicated via IRC. Since that time, these meetings have continued to serve as a regular time each week where contributors working on CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. releases could gather to have synchronous conversations about important matters related to the upcoming releases or to discuss general team processes.
Given the global nature of the WordPress community, the current time for these Dev Chats are not inclusive to everyone to attend. We experimented with a second APAC Dev Chat starting in 2020 as a way of creating opportunities for folks who could not attend the current time to still participate in a weekly Dev Chat. However, those were not well attended and were eventually abandoned.
Scheduling Dev Chats for WordPress 6.7
Given that the primary purpose of Dev Chats is to have a time for synchronous conversations about the upcoming release, holding them at a time where the majority of named the release squad members for 6.7 are unable to attend isn’t ideal. Let’s consider moving them to a more APAC friendly time during this release.
If we’re trying to find a time that is inclusive to folks from India Standard Time (UTC +5:30) to Australian Eastern Standard Time (UTC +10) then the best times for rescheduling seem to be between 3–10 UTC. The early part of that range could cover some folks in the Americas but not folks in EMEA. Likewise, the latter part of this range could work for a majority of folks from EMEA, but is not ideal for folks in the Americas. Moving the time range earlier, to 0:00 UTC would allow participation from more folks in the Americas, but would exclude folks from EMEA and folks around IST as well. With that in mind, I’m proposing a few options for consideration to gather feedback.
Proposed time options
Wednesdays at 3:00 UTC (Ex: Wednesday, August 7, 3:00 UTC): India, Japan, Australia with some late Americas overlap (no EMEA)
Feedback Deadline: July 31, 2024 Please provide feedback to this proposal before Wed., July 31. In your feedback, let us know if you regularly attend Dev Chats and if you have a role for 6.7 that would be impacted (positively or negatively) by your preferred time. We’ll collect responses and plan to announce an updated schedule before Aug. 7, 2024.
Changing the time following the 6.7 release
Currently, WordPress 6.7 is scheduled for release on Nov 12, 2024. Following this release, we will maintain the updated Dev Chat time to address any post-release wrap up, including confirming another time change for the 6.8 release based on the success of this experiment and the needs of the release squad for that release.
WordPress 6.6.1 is scheduled to be the first maintenance release for the 6.6 version. This is a quick cycle release to fix a few high impact bugs. It is expected that there will be additional maintenance releases during this cycle.
Its release will follow the following preliminary schedule:
July 18, 2024 – Release Candidaterelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). made available and announced here on the make/coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. site.
July 23, 2024 – Final release made available.
Specific times will be decided in advance and adjustments to the schedule may be made. All adjustments will be noted in this post.
Minor or Maintenance releases of WordPress are intended as 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.-fix releases. If you have a TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.ticketticketCreated for both bug reports and feature development on the bug tracker. that you think should be considered, please put it in the 6.6.1 milestone. If you have a GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issue, please add it to the 6.6.x Editor Tasks board. If you lack bug gardening capabilities and have a ticket or issue you wish to highlight for 6.6.1, please add a comment here.
Note: except in extreme situations, only bug fixes will be considered and generally only bugs that have been introduced during the 6.6 cycle.
General coordination for the release will happen in the #6-6-release-leads channel and decisions around code for the release will be made in the #core room.
This minor releaseMinor ReleaseA set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. will be led by @ellatrix and myself (@hellofromtonya).
Allowed disabling autosave support for individual post types
[58201] added a way to allow disabling autosave support for individual post types. Not all post types support autosaving. By making autosave a post type feature, support can be more granularly handled without any workarounds or hardcoded allowlists. For backward compatibility reasons, adding editor support implies autosave support, so one would need to explicitly use remove_post_type_support() to remove it.
Twenty Sixteen: Fixed mismatch of visual and DOM order of elements
Starting in Twenty Sixteen’s version 3.3 (released with WordPress 6.6), the site information links remain below the social navigation at any screen size. Before that, the social navigation had displayed after the site information on larger screens, which created a mismatch between the visual order and the Document Object Model (DOM) order.
The two footer elements are stacked, now at screen widths larger than 910 pixels.
If you would like to have the two elements side-by-side, with the social navigation first, you could paste styles in a child themeChild themeA Child Theme is a customized theme based upon a Parent Theme. It’s considered best practice to create a child theme if you want to modify the CSS of your theme. https://developer.wordpress.org/themes/advanced-topics/child-themes/. or in the Customizer’s Additional CSS panel.
Check the instructions on how to do this
@media screen and (min-width: 56.875em) {
/*
1. Reset the social navigation width.
2. Adjust margins to place site info along the right edge.
*/
.site-footer .social-navigation {
width: auto;
margin: 0.538461538em auto 0.538461538em 0;
}
.site-info {
margin: 0;
}
/* Reverse the margins for right-to-left languages. */
.rtl .site-footer .social-navigation {
margin: 0;
}
.rtl .site-info {
margin: 0.538461538em auto 0.538461538em 0;
}
}
Custom CSSCSSCascading Style Sheets. could place the site information links on the right side.
Default length of time for comment author cookies has changed
[58401] changed the default length of time for comment author cookies from 0.95129375951 of a year to 1 year by taking advantage of the YEAR_IN_SECONDS constant. The comment_cookie_lifetimefilterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. can still be used to change this value.
#61109 now directs a classic theme’s Appearance > Patterns menu to the site editor Patterns view (/wp-admin/site-editor.php?path=/patterns), providing a consistent pattern and template management experience regardless of theme type. For themes with block-template-parts support, the Appearance > Template Parts menu has been removed, with template parts now accessible under the site editor’s Patterns > Template Parts view.
Fluid Typography
Some theme.json presets require custom logic to generate their values, for example, when converting font size preset values to clamp() values.
The custom logic is handled by callback functions defined against the value_func key in WP_Theme_JSON::PRESETS_METADATA. The callback functions are invoked in WP_Theme_JSON::get_settings_values_by_slug().
In WordPress 6.6, settings of the current WP_Theme_JSON instance, are now passed to these callback functions. The permits callback functions to return values that rely on other settings in the theme.jsonJSONJSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. tree.
In the case of font sizes presets, it fixes a bug whereby the callback function — wp_get_typography_font_size_value() — was not taking into account settings values passed directly to the WP_Theme_JSON class.
External libraries
jQuery UIUIUser interface library update
The jQuery UI library was updated to version 1.13.3. For more information on the changes included, see jQuery UI 1.13.3 release notes.
Login and Registration
New array arguments for wp_login_form
The wp_login_form() function has two new array arguments: required_username and required_password. Passing true to these arguments adds the ‘required’ attribute to the input fields.
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
Custom ports for multisite site addresses
#21077 made it possible to install and operate a Multisite installation on a host name that includes a port number, and the corresponding #52088 added full support for this to the local development environment. This means it’s now possible to run Multisite on an address such as localhost:8889.
Update enabled mime types for new multisite installs
In #53167, the list of mime types that are enabled for upload were aligned to those enabled by regular sites by switching from a hard-coded list of types (that had become outdated) to using coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.’s get_allowed_mime_types function. This ensures that new multisite installs are up to date with the current mime types supported in core, including the recently enabled image/webp and image/avif types.
Note that, since this is only used to populate the schema for new networks, it will only affect newly created multisite networks – it does not change the allowed mime types for existing networks. To adjust the mime types allowed for existing sites, developers can continue to use an approach as follows for filtering the upload_filetypes option:
Script Loader
Obsolete polyfills dependencies have been removed
In [57981], now obsolete polyfills such as wp-polyfill, wp-polyfill-inert and regenerator-runtime were removed from the react script dependency in WordPress, as they are no longer needed in modern browsers supported by WordPress. Developers relying on wp-polyfill need to manually add it as a dependency to their scripts.
Script modules can now be used in the WordPress adminadmin(and super admin)
With #61086, script modules can now be used in the WordPress admin. Before WordPress 6.6, script modules were only available on the front end.
Toolbar
Search has a much later priority
In [58215], the search input on the front-end admin bar is added at a different priority. It was previously inserted at priority 4 and then floated to appear at the end of the admin bar. It is now inserted at priority 9999 to load at the end of the admin bar without CSS manipulation.
Extenders placing admin bar nodes after the search or replacing core search should take the new priority into consideration.
Example: Assign different priority based on WordPress version
Below you find a table that lists all coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. blocks available in the inserter marks in the grid the feature they support in the blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. It’s a basic lookup table that helps developers to find the information quickly.
While this post is released as part of 6.6, the content summarizes changes between 6.1 and 6.6. This is an update of the post published for the 6.1 release and provides a cumulative list of design supports added with the last five WordPress releases.
The features covered are:
Align
Typography,
Color,
Dimension,
Border,
Layout,
Gradient,
Duotone,
Shadow,
Background image*
Pattern overrides / Block Bindings (PO/BB)
*Note: In WordPress 6.6, the background image tools are only available for Group, Pull quote, Site Logo blocks and as side-wide feature. For Quote, Verse and Post content blocks, it’s only in GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party 18.6 and slated for WordPress 6.7.
Updated on July 3 with the list tracking issues to add various design tools to core blocks, so one can follow along the progress.
AvatarAvatarAn avatar is an image or illustration that specifically refers to a character that represents an online user. It’s usually a square box that appears next to the user’s name.
✅
–
✅
✅
–
✅
Button
✅
✅
✅
✅
–
✅
–
✅
✅
Buttons
✅
✅
–
✅
–
✅
–
✅
Calendar
✅
✅
✅
–
–
–
–
Categories
✅
✅
–
✅
–
–
–
Code
✅
✅
✅
✅
✅
–
–
Column
✅
✅
✅
✅
✅
✅
–
✅
Columns
✅
✅
✅
✅
✅
✅
✅
–
✅
Comment Author Avatar
–
✅
✅
✅
–
–
Comment Author Name
✅
✅
✅
–
–
✅
–
Comment Content
✅
✅
✅
–
–
✅
–
Comment Date
✅
✅
✅
–
–
–
Comment Edit Link
✅
✅
✅
–
–
–
Comment Reply Link
✅
✅
✅
–
–
–
Comment Template
✅
✅
–
✅
–
–
–
Comments
✅
✅
✅
✅
✅
–
Comments Pagination
✅
✅
✅
–
–
✅
–
Comments Pagination Next
✅
✅
–
–
–
✅
–
Comments Pagination Numbers
✅
✅
–
–
–
✅
–
Comments Pagination Previous
✅
✅
–
–
–
✅
–
Comments Title
✅
✅
✅
✅
✅
–
✅
–
Cover
✅
✅
✅
✅
–
–
✅
✅
Details
✅
✅
✅
✅
✅
✅
Embed
✅
–
✅
–
–
–
File
✅
–
✅
✅
–
–
–
Footnotes
✅
✅
✅
✅
Gallery
✅
✅
✅
✅
✅
–
Group
✅
✅
✅
✅
✅
✅
✅
–
✅
Heading
✅
✅
✅
✅
–
–
✅
Home Link – Navigation
✅
–
–
–
–
–
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers.
–
–
–
–
–
–
Image
✅
–
–
✅
–
✅
✅
✅
Latest Comments
✅
✅
–
✅
–
–
–
Latest Posts
✅
✅
✅
–
✅
–
✅
✅
List
✅
✅
✅
–
–
–
List Item
✅
–
✅
–
–
–
Login/logout
–
–
–
–
–
–
Media & Text
✅
✅
✅
✅
–
–
✅
–
More (Read More)
–
–
–
–
–
–
Navigation
✅
–
✅
–
✅
–
Navigation Link
✅
–
–
–
–
–
Navigation Submenu
–
–
–
–
–
–
Next Page (Page Break)
–
–
–
–
–
–
Page List
✅
–
–
–
–
–
Paragraph
✅
✅
✅
–
–
✅
–
✅
Post Author
✅
✅
✅
–
–
✅
–
Post Author Biography
✅
✅
✅
–
–
✅
–
Post Author Name
✅
✅
✅
–
–
✅
–
Post Comments Count
✅
✅
✅
–
–
✅
–
Post Comments Form
✅
✅
✅
–
–
✅
Post Comments Link
✅
✅
✅
–
–
✅
Post Content
✅
✅
✅
✅
✅
✅
✅
✅ 18.6
Post Date
✅
✅
✅
–
–
✅
–
Post ExcerptExcerptAn excerpt is the description of the blog post or page that will by default show on the blog archive page, in search results (SERPs), and on social media. With an SEO plugin, the excerpt may also be in that plugin’s metabox.
✅
✅
✅
–
–
✅
–
Post Featured ImageFeatured imageA featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts.
The Crowdstrike disaster is a good opportunity for us to brainstorm and review our “defense in depth” around updates. If I committed a die(); to coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., what happens? What if I modify the file on the server directly? What automated fail-stops can we build in? How can WordPress clients also protect themselves? (We do some decent stuff here already for failed updates.)
It’s our ethical duty as engineers to make sure these systems fail gracefully when something goes wrong, because it’s guaranteed that it will at some point.
This guide outlines major developer features and breaking changes in 6.6 and is published in the Release Candidaterelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). cycle to help inform WordPress extending developers, CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. developers, and others.
This release includes 392 enhancements, 462 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. fixes, and 46 accessibilityAccessibilityAccessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) improvements for the Block Editor (a.k.a. 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/).
Below is the breakdown of the most important developer-related changes included in WordPress 6.6.
BlockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor
WordPress 6.6 brings 8 Gutenberg releases into core – 17.8, 17.9, 18.0, 18.1, 18.2, 18.3, 18.4, and 18.5. The Block Editor receives several improvements related to the ReactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. library, the Block 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., Themes, and more.
React
A new version of React and the new JSX transform is available in WordPress 6.6.
WordPress 6.6 includes updates for the Interactivity API, such as new async directives, support for derived state props from PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher, integration with Preact Devtools, and new warning messages available when the SCRIPT_DEBUG configuration constant is enabled.
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. API
WordPress 6.6 includes a helpful maintenance release to the HTML API. This work includes a few new features and a major improvement to the HTML Processor’s usability. This continues the fast-paced development since WordPress 6.5.
There’s also a new data structure coming in WordPress 6.6 for the HTML API: the WP_Token_Map.
Several changes have been made to the Options API to support an optimization for the autoloading behavior, and to create a way to apply further optimizations going forward.
I18Ni18nInternationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill.
One of the highlight features included in WordPress 6.6 is the automatic rollback of 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 auto-updates upon detecting PHP fatal errors.
New/Modified HooksHooksIn WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.
Modified FilterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. Hooks
The theme.jsonJSONJSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. version is incremented whenever a breaking change would need to be made to the 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.. This allows consumers to opt-in to the breaking change by updating the version. Older theme.json versions will always be supported in the latest versions of WordPress.
Updating to version 3 is recommended when your minimum supported WordPress version reaches 6.6. See theme.json version 3 frequently asked questions for more information on when to update. Then check out the theme.json reference for migrationMigrationMoving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. instructions when you are ready to update.
Breaking changes in version 3
Starting with theme.json version 3 the default behavior for using the same slugs as the default fontSizes and spacingSizes presets has been changed to match how other theme.json presets work: from always overriding the default presets to requiring defaultFontSizes or defaultSpacingSizes to be false in order to override the default presets.
Default font sizes
settings.typography.defaultFontSizes is a new option in theme.json v3. It controls whether the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. provided default settings.typography.fontSizes presets are shown and used.
The default fontSizes presets’ slugs are: small, medium, large, and x-large.
When defaultFontSizes is true it will show the default font sizes in the editor and prevent the theme from creating presets using the default slugs.
When defaultFontSizes is false it will hide the default font sizes in the editor and allow the theme to use the default slugs.
For 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. themes defaultFontSizes is true by default. This is consistent with how other default* options work such as settings.color.defaultPalette.
For classic themes there is a new theme support default-font-sizes which is also true by default. However, unlike block themes, it is set to false when editor-font-sizes theme support is defined.
In theme.json v2, the default font sizes were only shown when theme sizes were not defined. A theme providing font sizes with the same slugs as the defaults would always override the defaults.
To keep behavior similar to v2 with a v3 theme.json:
If you do not have any fontSizes defined, defaultFontSizes can be left out or set to true.
If you have some fontSizes defined, set defaultFontSizes to false.
settings.spacing.defaultSpacingSizes is a new option in theme.json v3. It controls whether the core provided default settings.spacing.spacingSizes presets are shown and used.
The default spacingSizes presets’ slugs are: 20, 30, 40, 50, 60, 70, and 80.
When defaultSpacingSizes is true it will show the default spacing sizes in the editor and prevent the theme from creating presets using the default slugs.
When defaultSpacingSizes is false it will hide the default spacing sizes in the editor and allow the theme to use the default slugs.
defaultSpacingSizes is true by default. This is consistent with how other default* options work such as settings.color.defaultPalette.
For classic themes there is a new theme support default-spacing-sizes which is also true by default. However, unlike block themes, it is set to false when editor-spacing-sizes theme support is defined.
In theme.json v2, the default spacing sizes were only shown when theme sizes were not defined. A theme providing spacing sizes with the same slugs as the defaults would always override the defaults.
Furthermore, there are two settings that can be used to set theme level spacing sizes: spacingSizes and spacingScale. With theme.json v3, presets from both will be merged together and sorted numerically by slug. Presets defined in spacingSizes will override those generated by spacingScale if the slugs match.
In theme.json v2, setting both spacingSizesandspacingScale would only use the values from spacingSizes.
To keep behavior similar to v2 with a v3 theme.json:
If you do not have any spacingSizes presets or spacingScale config defined, defaultSpacingSizes can be left out or set to true.
If you disabled default spacing sizes by setting spacingScale to { "steps": 0 }, remove the spacingScale config and set defaultSpacingSizes to false.
If you defined only one of either spacingScale or spacingSizes for your presets, set defaultSpacingSizes to false.
If you defined both spacingScale and spacingSizes, remove the spacingSizes config and set defaultSpacingSizes to false.
One of the goals of WordPress 6.6 is to simplify the process for theme authors to override coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. styles while also maintaining support for Global Styles.
Historically, high CSSCSSCascading Style Sheets. specificity in core styles has made customization challenging and unpredictable, often requiring complex CSS rules to achieve desired outcomes. Development of the new section styles feature also highlighted a need for uniform CSS specificity to support nesting such styles, facilitating the creation of sophisticated, layered designs.
Uniform 0-1-0 Specificity
WordPress 6.6 introduces several changes aimed at broadly reducing CSS specificity and making it more uniform. These changes generally fall into two categories:
Core 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. Styles
Theme.jsonJSONJSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. / Global Styles:
Where adjustments to CSS specificity were required, they were achieved by wrapping the existing selector within :root :where(...).
Core Block Styles
The choice of 0-1-0 specificity greatly reduced the changes required to existing core block styles as blocks targeting their default .wp-block- class already have the desired specificity.
Any blocks with Global Styles support using higher specificity selectors had those selectors wrapped in :root :where(...). This also applied to Block Styles (aka block style variations) and their default styles e.g., .wp-block-image.is-style-rounded img was updated to :root :where(.wp-block-image.is-style-rounded img).
Theme.json / Global Styles:
All block styles, including block style variation styles, output by theme.json and Global Styles are now limited to 0-1-0 specificity. Layout styles, e.g., constrained, flex, flow` etc., have also been limited however depending on the specific layout type and definition the final specificity varies slightly from 0-1-0 so they apply correctly.
Usage
The alignment of 0-1-0 specificity for Global Styles to default block selectors, e.g. .wp-block-, greatly reduces the need for updates. It’s recommended for theme and block authors to double-check their designs if they rely on custom CSS using more complex selectors.
Custom blocks
Authors of custom blocks that opt into global styles and apply default styling via a selector with greater than 0-1-0 specificity, should update those selectors wrapping them in :root :where().
An example could be a custom list block that opts into padding block support but defines default padding via:
ul.wp-block-custom-list {
padding: 0;
}
Without adjusting the specificity of this rule, any customizations of the block type’s padding in Global Styles would be overridden. Wrapping the selector in :root :where() here would allow the style load order to determine which rule takes precedence.
// Block's stylesheet
:root :where(ul.wp-block-custom-list) { // This is a contrived example and could simply be `.wp-block-custom-list`
padding: 0;
}
// Global Styles - Loaded after the block styles
:root :where(.wp-block-custom-list) {
padding: 1em;
}
Block Styles (aka Block Style Variations)
Theme authors customizing Block Styles for a core block will need to limit their style’s specificity, so the block style continues to be configurable via Global Styles.
For example, take a theme that tweaks the border radius for the Image block’s rounded block style:
Without adjustment, this style would override any customizations made to the Rounded block style within Global Styles.
In this case, the theme can tweak its rounded image style to the following:
//. Theme style
:root :where(.wp-block-image.is-style-rounded img) {
border-radius: 2em;
}
// Global Styles - Loaded after the block styles
:root :where(.wp-block-image.is-style-rounded img) {
border-radius: 4px;
}
Zero-Specificity, CSS Layers, and the future
Reducing all core styles to zero specificity was explored before settling on 0-1-0 specificity. Zero specificity unfortunately wasn’t robust in the face of common reset stylesheets and required more widespread changes.
CSS Layers were also evaluated but fell short due to not being able to enforce all styles belonged to a layer. This will change in the future at which point a combination of CSS Layers and zero-specificity can be revisited to further the benefits gained in this initial reduction of CSS specificity.
