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.
WordPress automatically loads multiple options with a single query on each page request in order to be more efficient—a technique called “autoloading”. Prior to [57920], developers could control whether their option should be autoloaded by passing either "yes"/true or "no"/false to the third parameter of add_option() or update_option(). However, the decision to make that parameter optional, with a default value of "yes" has led to many options being loaded on every page unnecessarily (see #42441).
Autoloading a large amount of data that is not used negatively impacts website performance, particularly when an option containing a large amount of data is not used.
[57920] introduces several changes to the Options 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. to optimize autoloading behavior.
Changes to the options API
To support this optimization for autoloading behavior, and to create a way to apply further optimizations going forward, the following changes to the Options API have been made.
New default $autoload value
The default value for the $autoload parameter of add_option() and update_option() is being changed from "yes" to null, to allow WordPress to differentiate between an option with an autoload value that is explicitly set, and one where it can dynamically determine whether an option should be autoloaded. As a result, there are now three recommended values for the autoload parameter:
true: always autoload; Use this when an option should load on every page to avoid an additional DB query.
false: never autoload; Use this when an option is rarely used to avoid wasted data being loaded on every page.
null: maybe autoload; Allow the autoload value to be dynamically determined. By default, WordPress will still autoload options using the default value unless they contain large values (described below).
For backwards compatibility, the previous values of "yes" and "no" are still supported and mapped to true and false, respectively.
Updated database autoload values
Previously, all options were stored in the database with an autoload value of either “yes” or “no”. Starting with this change, the autoload value for newly updated options will now be one of the following values:
‘on’: Added with an explicit true value and MUST be autoloaded (needed on EVERY page).
‘off‘:‘ Added with an explicit false value and MUST not be autoloaded (e.g. only used on a single adminadmin(and super admin) page) .
‘auto’: Added without an explicit value and will rely on WP default autoloading behavior. In WordPress 6.6 these SHOULD autoload, but the default may change in the future.
‘auto-on’: Added with a dynamically set to true value and SHOULD be autoloaded.
‘auto-off’: Added with a dynamically set to false value and SHOULD NOT be autoloaded.
No upgrade routine is planned for this change, so previously added options will still be stored with “yes” or “no” values, which will be treated like “on” and “off”, respectively. If you have implemented any custom SQL to read or write autoload values, you should update them to use the new values.
Newly introduced public functions and filters
Several new functions and filters are available to make working with the new autoload values easier.
New Function
wp_autoload_values_to_autoload() – Returns all database values that should be autoloaded. Defaults to an array containing 'yes', 'on', 'auto-on', and 'auto'.
New Filters
wp_autoload_values_to_autoload – Edit the list of autoload values stored in the database values that should be autoloaded. At this time, the 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. only allows values to be removed.
wp_default_autoload_value – Determine the default autoload value for an option where no explicit value is passed. Return a boolean false value to disable autoloading.
wp_max_autoloaded_option_size – Modify the size threshold above which options will not be autoloaded by default. Defaults to 150000, i.e., 150k bytes.
Disabling autoload for large options
To address the issue of autoloading excessively large options, when an option is added via add_option() or an option’s value is changed via update_option(), WordPress will now dynamically disable the autoload behavior by checking the size of the value before updating the database. For any options that do not explicitly pass true to the $autoload parameter, a value that is greater than 150k bytes will no longer be set to autoload.
Preparing for this update
To prepare for this update, developers should update calls to add_option() and update_option() in their code to explicitly set an autoload value using the new preferred true or false values in order to control the autoload behavior for your options. Otherwise, continue using the default value to allow for autoload optimizations to be dynamically applied.
Ensuring a large option is still autoloaded
If you need to ensure a specific large option is autoloaded after this change and cannot directly change the code where that option is saved, you can make use of the new wp_default_autoload_value filter.
Note: Do this with care, and only for options that are needed on every page.
If you want to change the size threshold for when options should no longer be autoloaded, you can use the new wp_max_autoloaded_option_size filter. Increasing this value is not recommended, as it could lead to slower performance.
add_filter( 'wp_max_autoloaded_option_size', 'my_max_autoload_option_size' );
function my_max_autoload_option_size( $size ) {
// Reduce the threshold for large sizes to 100K (Default is 150K).
return 100000;
}
Auditing your site for large options
WordPress 6.6 will include a new Site Health check, which will display a critical issue that says “Autoloaded options could affect performance” if the total size of your autoloaded options exceeds 800 KB.
To audit your site for large options that are currently being autoloaded, you can run an enhanced version of this same Site Health check by installing the Performance Lab plugin from the WordPress Performance Team. Once activated, the 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 will add additional information to the Site Health check so you can review and disable any options that do not need to be autoloaded in the Site Health check.
Screenshot of the advanced table shown by the Performance Lab plugin
Other changes to the Options API in WordPress 6.6
Introduce wp_prime_network_option_caches() to load multiple networknetwork(versus site, blog) options with a single database request (#61053)
Prime transient and transient timeout options in the transient and site transient APIs (#61193, #61053)
Update default autoload values used in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. (#61045)
Add 'label' argument to register_setting() (#61023)
WordPress 6.6 includes improvements to how a block variation is detected as active for a given 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. via the variation’s isActive property. This property can be either a function (that compares block and variation attributes), or a string[] shorthand that specifies which of the variation’s attributes to consider when comparing them to the block’s. The following changes affect only the string[] shorthand, which is now generally recommended over the function version.
Dot notation
Block variations can now use dot notation for “object paths” to specify “nested” attributes in their isActive property. For example, if a block’s query attribute is an object, it is now possible to use the following shorthand notation for isActive to determine if a variation is active based on the query object’s postType property:
If multiple variations have an isActive string array property that matches a given block, getActiveBlockVariation() will now return the one with the highest specificity. For example, take two variations of the same block, one with
Now if a block instance has attributes textColor: vivid-red and backgroundColor: cyan-bluish-gray, both variations’ isActive criterion will match that block instance. In this case, the specificity of each match will be calculated as the length of each isActive array, and the matching variation with the highest specificity will be returned — in this example, the second one.
Comparison of objects
If an isActive array item is an object, it was previously compared by reference. This has been fixed such that a block is considered to match a variation if it contains all the properties that the variation specifies for that object and if the properties have the same values. For example, the following variation
as the orderBy property that’s specified by the variation is missing.
Comparison of RichText
Finally, rich-text attributes are now compared correctly when used in a block variation’s isActive array. For example:
<pre class="wp-block-syntaxhighlighter-code">attributes: {
content: 'This is a <strong>warning</strong> message.',
},
isActive: [ 'content' ]</pre>
Conclusion
We hope that these improvements will make developers’ lives easier when working with block variations. They’re also meant to lay the foundations for some other enhancements we’re planning to make to block variations during the next cycle (e.g., automatically added class names for variations, or variation aliases).
The grid layout type for blocks has been in core since 6.3 but 6.6 adds some new features to it:
Toggle between grid modes
Adding grid layout to a block.json without specifying any further attributes, like so:
"layout": {
"default": {
"type": "grid"
}
}
will now by default display a toggle 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.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. layout section, allowing users to toggle between “Auto” and “Manual” modes:
It is still possible to configure the block to default to “Manual” mode and add a specific column count, by using the columnCount attribute:
Blocks that opt into grid layout can also allow their child blocks to span across multiple grid columns and/or rows. This can be enabled with the allowSizingOnChildren attribute:
WordPress 6.6 unified the different slots and extensibility APIs between the post and site editors. 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 authors do not need to integrate their extensions twice (once using wp.editPost and once using wp.editSite). Instead, the following slots are now available under the wp.editor global variable (@wordpress/editor package or wp-editor script handle).
The above script registers a panel in the document 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. for all post types in both the post and site editor. The script can be enqueued in PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher with the right script dependencies:
The wp.editPost and wp.editSite slots will continue to work without changes, but the old slot locations will be deprecated. To avoid triggering console warnings, you can support both the new and old slots at the same time.
To support previous versions in the example above, the Slot import must be updated as shown in the following code:
Once you are ready to make WP 6.6 the minimum required version for your plugin, you should be able to drop the fallbacks and restore the initial code.
Limiting your extensions per post types
It is important to note that when switching from editPost or editSite slots to editor, your plugin will now load and render in both contexts.
Both editors (post and site editors) have the possibility to render and edit pages, templates, patterns… This means that most plugins probably need to load in both contexts. But you might not want to load your plugin for templates, patterns, or you may only want load your plugin for pages but not posts…
To perform these checks, plugin authors have access to a range of selectors in the coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress./editor data store that allow them to hide or disable their behavior/UIUIUser interface as they wish.
Some extensions might only make sense to publicly viewable post types (post types that render in the frontend). You can use the postType’s viewable property to check for this.
Or you can use the name of the post type to only render for a limited set of post types.
Let’s update the initial example to only render the slot for publicly viewable post types:
// my-file.js
import { registerPlugin } from '@wordpress/plugins';
import { PluginDocumentSettingPanel, store as editorStore } from '@wordpress/editor';
import { store as coreStore } from '@wordpress/core-data';
const PluginDocumentSettingPanelDemo = () => {
const isViewable = useSelect( ( select ) => {
const postTypeName = select( editorStore ).getCurrentPostType();
const postTypeObject = select( coreStore ).getPostType( postTypeName );
return postTypeObject?.viewable;
}, [] );
// If the post type is not viewable, do not render my plugin.
if ( ! isViewable ) {
return null;
}
return (
Custom Panel Contents
);
}
registerPlugin( 'plugin-document-setting-panel-demo', {
render: PluginDocumentSettingPanelDemo,
icon: 'palmtree',
} );
WordPress 6.6 Beta 2 was released on June 11. Thanks to everyone who was involved in getting that release. Please keep testing!
Forthcoming Releases
Next major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.: 6.6
WordPress 6.6 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. 3 is scheduled for next Tuesday, June 18, and is the last scheduled beta before 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). 1. See the release schedule here.
@marybaum noted that the About page is currently in progress.
@joemcgill reminded everyone that we should be working on getting dev notesdev 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. published in the next 2 weeks before the field guideField guideThe field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. is finalized.
Next 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: 18.6
Gutenberg 18.6 is scheduled for June 19 and will include these issues. This version will NOT be included in the WordPress 6.6 release.
Discussion
We didn’t have anything specific for discussion for this chat, as many folks were at WCEU.
We discussed how best to stay up to date with UIUIUser interface changes in the Editor. @joemcgill noted that changes to the editor UI happen in the gutenberg repo, and are released first in 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 so they can be tested before being included in a WordPress major release. Discussion about those changes generally happen in issues and PRs on that repo.
Additionally, plans for WordPress 6.6 were summarized in this Roadmap post, which may be a good way to see what else is changing so you can test and provide feedback before the final release.
@hellofromtonya also mentioned the #core-editor channel, which is helpful for when you’re looking for where to start and if a feature or change is in the works.
@colorful-tones added: Another means to keep up to date on the latest updates is to check out (and consider subscribing to updates in the 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.) the WordPress Developer Blog. For example, the latest post: What’s new for developers? (June 2024) mentions this newer feature here.
@joemcgill also raised @dmsnell‘s excellently written proposal — Proposal: Bits as dynamic tokens — and recommended taking time to read it and provide feedback or ask questions in the comments of that post.
We also discussed not pinning the 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. scrub post, since it’s so long, and instead just link to it from the release page.
@ironprogrammer suggested posting a short signpost message pointing to the scrub, close comments, pin it. Or a sidebar update.
@joemcgill suggested exploring the 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. feature on the Make team blogs.
Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.
WordPress 6.5.4 was released on June 5 and is now available for download. Thanks to all the contributors who worked on this release too! @jorbin noted that there is now a 6.5.5 milestone in tracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress., but suggests that we enter a holding pattern for ~2 weeks before deciding if it’s necessary.
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/ 18.5 was scheduled for release on June 5 (completed after the meeting). This is the final release going into WordPress 6.6, and from this point only 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 will be cherry-picked into the 6.6 branchbranchA directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch"..
Forthcoming Releases
Next major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.: 6.6
As we’re in the middle of the 6.6 cycle, we used the discussion time to check in on priority items for this release. Noting that an early look of the 6.6 source of truth has been published recently by @annezazu. This is usually particularly helpful for marketing, training, and docs at this stage. Feedback, questions, comments welcomed! Expect a finalized version in line with 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). 2 on July 2nd.
@colorful-tones raised concern about whether pattern shuffling is suitable for 6.6 and identified a few items that came up right after 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 that are on the WordPress 6.6 Editor Tasks board:
@joemcgill advised that if these are bugs, it is fine to fix during the beta period, but that they will need to be prioritized:
“…folks basically have the next 3 weeks do decide if these bugs should be fixed, if the feature should be removed, or if these are minor issues that don’t need to make the release. But punting the bugs is essentially committing to shipping the feature with known issues, so I would try to avoid punting them without discussion with folks closest to the features.”
@joemcgill also raised concern about the fact that we only have 3 weeks until RC1, which overlaps time that many contributors will be traveling and attending WCEU.
@marybaum requested that if we drop a feature, it would be fabulous to know that a week or so before RC 1 in order to update the About page prior to the RC 1 string freeze.
Open Floor
@apedog asked for someone to review #58932, which @joemcgill followed up on after the meeting.
@kkmuffme requested more attention to the following issues:
@joemcgill had reviewed these ahead of the meeting and mentioned that several were already too late to make this release. Specifically, the enhancementenhancementEnhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature. tickets and one marked early. @hellofromtonya noticed that at least one needs deeper review because of a potential back-compat break.
Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.
WordPress 6.6 will ship with version 18.3 of the React library, which is identical to 18.2 but adds warnings for deprecations and other changes to help developers prepare for the ReactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. 19 upgrade once it becomes stable.
It’s recommended to stop using the deprecated features to ensure better compatibility with React 19 when it ships with WordPress. Keeping deprecations unchecked may lead to bugs or unintended behavior in your plugins. Addressing them is important to ensure smooth and reliable functionality.
Removed: defaultProps for function components
When searching the 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 and theme repo for the use of deprecations in React 19, this one was found to be common.
React 19 will remove defaultProps for function components in favor of ES6 default parameters. This change can cause unexpected side effects when a component relies on default values provided by defaultProps.
// Before.
function Welcome( { text } ) {
return <p>{ text }</p>;
}
Welcome.defaultProps = {
text: 'Howdy!',
};
// After.
function Welcome( { text = 'Howdy!' } ) {
return <p>{ text }</p>;
}
Please refer to the official React 19 upgrade guide for a full list of deprecations and changes.
WordPress 6.6 introduces the possibility for developers to use the new React JSX transform that was first released in ReactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. 17.
How to use the new JSX in WordPress 6.6
Your build scripts need to apply the following changes in the built files:
Add the react-jsx-runtime to your script dependencies.
Use ReactJSXRuntime.jsx global as the output of your JSX calls.
In general, this is not something you do manually in your code base. Instead, you’ll use a build tool. The @wordpress/scripts, @wordpress/babel-preset-default and @wordpress/dependency-extraction-webpack-plugin npm packages have been upgraded to apply these transformations automatically.
Build Tools Compatibility and upgrade path
If you’re using the JSX syntax in your code base, and as long as you don’t update your dev dependencies (including @wordpress/scripts, @wordpress/babel-preset-default or @wordpress/dependency-extraction-webpack-plugin), you will continue to use the old JSX transform. This will allow your 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 and built files to be compatible with WordPress 6.5, earlier versions and WordPress 6.6 as well.
When you’re ready to make WordPress 6.6 the minimum supported version of your plugin, you can update the following dependencies to use the new JSX transform.
@wordpress/scripts from version 28.
@wordpress/babel-preset-default from version 8.
@wordpress/dependency-extraction-webpack-plugin from version 6.
Going forward
The new JSX transform comes with performance improvements and optimization.
Note that the React team will deprecate the old JSX transform in the upcoming React v19 release (currently in RC).
The scheduled date for WordPress 6.6 Beta 1 is June 4. From this point on, we will focus on testing and fixing bugs discovered during 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. testing. Begin writing Dev Notesdev 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. and the About page.
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/ 18.4 was released on May 22. Read more about what was included in this release here.
Forthcoming Releases
Next major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.: 6.6
We are currently in the WordPress 6.6 release cycle. See the Roadmap Post for details about what is planned for this release. Gutenberg 18.5 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). is scheduled for May 31, which is the final RC before WordPress 6.6 Beta 1. It will include these issues and PRs.
Next maintenance release: 6.5.4
@jorbin has confirmed that there will be a 6.5.4 release scheduled for June 5, to accommodate #61269. An RC is scheduled for May 30.
@hellofromtonya shared that an alternate approach to #61269 is being considered for 6.5.4 and requested more feedback:
This could have an impact on the planned RC schedule for 6.5.4 depending on consensus on what approach to ship.
Discussion
With the Beta 1 deadline quickly approaching, we used the discussion time to check in on priority items for this release. Please review the list of Editor Updates from this week’s agenda for a list of updates of several key features related to this release.
@fabiankaegy has flagged that there are a number of commits that still need to be synced from the Gutenberg repo as part of this tracking issue. He also is tracking related PRs in this table on the WP 6.6 Editor Tasks board. Support from folks to review and commit these PRs is appreciated as we approach the 6.6 beta 1 deadline.
@joemcgill asked if the Release Squad needed any support to be ready for the 6.6 Beta 1 release next week.
@meher shared that all teams have reported a 🟢 status in the last check-in. Waiting for the Design and Performance to add their status. The documentation team has got help from folks.
Currently trying to decide whether the time to start Beta 1 should be 14:00 UTC or 16:00 UTC. Conversation about this continued after the meeting in the #6-6-release-squad channel.
Open Floor
Nothing was raised during Open Floor this week
Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.
The scheduled date for WordPress 6.6 Beta 1 is June 4, which is less than 2 weeks away. From this point on, we will focus on testing and fixing bugs discovered during 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. testing. Begin writing Dev Notesdev 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. and the About page.
@ellatrixrecently announced that the last 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 to go into WP 6.6 will have an 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). next Friday, May 31.
Forthcoming Releases
Our next major releasemajor releaseA release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. is WordPress 6.6. See the Roadmap Post for details about what is planned. Also, see the Bug Scrub post for more details on when the 6.6 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. scrubs are happening.
@jorbinrequested that we discuss the potential of doing a 6.5.4 release to accommodate #61269, and noted:
@hellofromtonya, @costdev and myself have been working through some options to help solve some issues that cropped up from 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 dependencies and are proposing #61269 as a solution that we would like to get in the hands of users as soon as possible.
Our suggestion is that we do a very small focused 6.5.4 on 5 June with an RC on 30 May. I am not currently aware of any other issues but would be open to including other fixes. I know it’s not much time for feedback, but am open to it as far as the schedule goes and also open to other tickets folks want to raise for inclusion.
The feedback that would be most helpful:
Testing and review of the proposed patchpatchA special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing.
feedback on the schedule,
proposal of additional issues that should be considered for the release if any
@jorbin also highlighted that we will need someone with MC access, someone with a metaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. sandbox, someone who can create a helphub page. Please reach out if you can help with any of these tasks.
The next GB release, Gutenberg 18.4, is going out soon and includes these issues. As mentioned during the announcements section of this chat, that means the following GB release (18.5) will be the last one planned to be included in WP 6.6. Now’s a very important time to be testing and reviewing PRs that are being synced from that repo to 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..
Discussion
Ahead of the meeting, @annezazu highlighted the following updates on features for 6.6 – please help review and provide feedback as you can!
About a 10 minute long video demo of zoomed out view and where things stand, including current challenges with adding it to the pattern insertion experience. As it stands today, it looks like the zoomed out experience to build with patterns won’t be ready but will be an experiment in the plugin.
Section styling has a new discussion around CSS specificity which is necessary to resolve for the feature to land. There is potential breakage that might happen with the zero specificity styles and an alternative plan presented to preserve backwards compatibility.
@dmsnell mentioned the HTML API: we’re getting nervously close to the deadline but still on task for our two main updates:
adding a spec-compliant text decoder
refactoring the HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. Processor so that it always presents a normalized “perfect” view of the HTML it’s parsing
@dmsnell mentioned that the best way to support this project is to review the work or share thoughts about how it’s all structured. The WP_Token_Map (Core-60324) is the biggest general thing in view and everyone is invited to share input on it or on the dev note I’ve prepared.
#61009 allows storing the proposed “Bits” syntax, making it possible for experimentation inside Gutenberg.
#61052 allows storing custom data attributes containing dashes, which is what the Interactivity 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. relies on.
The first one opens up the ability for Gutenberg to start experimenting with Bits, which are “Shortcodes, 2.0”, or dynamic tokens for externally-sourced data. This could use security review and scrutiny but is quite small in scope. The idea is that these can appear with a name and attributes which denote that something will replace it when rendered, but where Blocks are big, Bits are small, for example:
The second ticketticketCreated for both bug reports and feature development on the bug tracker. is about aligning kses with the needs of the Interactivity API. There is more information in this ticket. It would also be helpful to have more eyes and scrutiny on the way that this has been implemented.
For more information about both of these tickets, please read @dmsnell‘s messages during the dev chat from here.
Note: Anyone reading this summary outside of the meeting, please drop a comment in the post summary, if you can/want to help with something.
You must be logged in to post a comment.