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.
Scheduled 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 completed 😊 Thanks to everyone! Please continue testing 6.6 💪
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). Bug Scrubs will be conducted if needed.
For any folks who want to learn more about the release and help contribute back, I want to call attention to this post on Early opportunities to Test WordPress 6.6. Help the release and learn about it at the same time!
Discussion
Release Squad: A lengthy discussion ensued about the fact that 3 weeks from 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 the full release squad has not been filled. There were questions about why this release has been so hard to fill and what we could do to improve this in the future. Some questioned the size of the release squad making it difficult to fill and others questioned the length of the cycle. Suggestions were made to try to recruit a release squad earlier in the cycle, or even at the end of the previous cycle.
Canonical 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. plugins proposal: There is an initial issue and discussion here, and a follow-up Gutenberg PR is currently in progress to create a time to read block. Have folks had a chance to catch up here? Any questions or concerns?
@jeffpaul questioned what problem this would solve compared with either shipping these blocks in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. or allow them to be maintained as community plugins.
@jorbin expressed support for the idea, but identified that there were some questions that need to be answered in addition to what @grantmkin shared in this GitHub comment.
@annezazu shared that the difference is useful in that some blocks haven’t been a great fit for Core, for a variety of reasons. This separation allows the base experience to remain the same while offering strong, supported blocks provided by Core that folks can add on.
This was a lengthy discussion. Everyone is encouraged to provide feedback on the related issue.
Proposal: Server to client data sharing for Script Modules: This proposal is still looking for feedback.
Open Floor
@kkmuffme requested guidance on several tickets that have stalled, that he is hoping will get picked up in time for the 6.6 release. Following the meeting, @jeffpaul scrubbed the list and pinged relevant core developers who might be able to review and provide feedback.
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.
I’m glad to announce the WordPress 6.6 release squad is ready and the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.TriagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. and Documentation lead roles have been filled:
Release LeadRelease LeadThe community member ultimately responsible for the Release.: Matt Mullenweg
WordPress 6.5.3 was released on Tuesday, May 7. 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. features 12 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 in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. and 9 bug fixes for 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. You can review a summary of the maintenance updates in this release by reading the Release Candidate announcement.
Gutenberg 18.3 was released on Wednesday, May 8. The release highlights include a full page client-side navigation experiment, negative values for margin controls, and adding a publish flow to the editor.
Forthcoming Releases
We are currently in the WordPress 6.6 release cycle and 4 weeks away from 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. The latest update on the release squad is detailed in this post and there are a few TBD roles for Core triagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. and Docs leads. During the meeting, @OGlekler volunteered to be Core Triage Lead for 6.6. @priethor also followed up with a note to say:
Would the Core Triage role benefit from a second lead?
The Docs lead role is nearly ready too.
@jorbin confirmed that 6.5.3 came out on May 7. Thank you to everyone who helped. We now need to consider whether we should plan a 6.5.4. As of now, there is one potential regressionregressionA software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. that is being investigated, so @jorbin suggested that we give it one to two weeks before making a decision. The 6.5.4 milestone has already been added in tracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..
@annezazu noted that the only other feedback is around this: https://github.com/WordPress/gutenberg/issues/59511: There’s been some feedback from an enterprise client as they can no longer change titles easily. The problem is there’s not an intermediate solution in the works and it will be resolved by 6.6 when the site editor pattern experience comes to classic themes. This will be discussed further in #6-5-release-leads.
Discussion
Here are a couple of follow-ups from previous meetings:
New slack channels:#core-interactivity-api was created to help folks working there better organize and collaborate.
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/ commits: as a way to bring additional visibility to changes committed in the Gutenberg repo, we’ve started an experiment to show commits to the 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.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". (PR merges) in the #core channel.
We dedicated a lot of discussion time to the 6.6 roadmap and any updates about the major efforts listed on the Roadmap.
@afragen gave an update about Rollback Auto-Update: there have been zero reported issues with the PR. We’re currently just looking at making some of the comments a bit more descriptive. Hopefully Rollback Auto-Update will be committed in the next day or so.
@azaozzrequested for “more eyes” and reviews on https://github.com/WordPress/wordpress-develop/pull/6407#issuecomment-2101275000. This is a PR that properly fixes the infinite loopLoopThe Loop is PHP code used by WordPress to display posts. Using The Loop, WordPress processes each post to be displayed on the current page, and formats it according to how it matches specified criteria within The Loop tags. Any HTML or PHP code in the Loop will be processed on each post. https://codex.wordpress.org/The_Loop. as reported on #60652 (the current 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. just hides it, that PR removes the possibility for a loop to happen). It also fixes the possibility for a 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 to completely remove the new font_dirfilterFilterFilters 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. which is a pretty nasty thing to do and would break all other plugins that are using that filter.
@grantmkinalso noted: @vcanales and I have started exploring “canonical block plugins,” an idea to have more community developed blocks that are shipped as stand-alone block plugins, for blocks that aren’t a fit in the default block library shipped with Gutenberg/WordPress. The primary issue is at https://github.com/WordPress/gutenberg/issues/58773, in case you’d like to learn more about, follow, discuss, or contribute to the effort. There will likely be a follow-up on make/core to get more feedback.
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.
Almost 8 years ago the Preferred Languages feature project was kicked off in response to a feature requestfeature requestA feature request should generally begin the process in the ideas forum, on a mailing list, as a plugin, or brought to the attention of the core team, such as through scope meetings held for each major release. Unsolicited tickets of this variety are typically, therefore, discouraged. in #28197. Right now it is probably the oldest active feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.. Over time there were numerous updates, 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 even a complete refactor. Preferred Languages was always built and maintained with the goal in mind to merge it into coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. one day. Now the time is finally right to do so.
Purpose & Goals
As a quick reminder, Preferred Languages replaces the existing languages dropdown with a supercharged version that lets you select multiple preferred languages. WordPress then tries to load the translations for the first language that’s available, falling back to the next language in your list otherwise. Without this, WordPress would just fall back to English (US) in such cases, which is not a great experience. Such a UIUIUser interface is a pretty standard feature that can be seen for example also in operating system and browser settings.
Example of the Preferred Languages UI on the settings page
Note: Preferred Languages works for both the site language (can be set at Settings -> General) and the user language (can be set in the profile).
Project Background
You may wonder why it took such a long time. Since the project’s inception, a lot has changed in WordPress. For example, 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/ happened. That’s why Preferred Languages saw a complete rewrite using the same ReactReactReact is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. components that also power 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. With Gutenberg we also saw the introduction of JavaScript localization, which required further iterations to Preferred Languages. Then there was a need for merging incomplete translations, reducing the chances that you see missing strings in English. However, merging translations was very bad for performance, as it involves loading lots of translationtranslationThe process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. files. In WordPress 6.5 we finally completely replaced the localization library with a more performant solution that natively supports loading multiple files at once. So this last remaining blockerblockerA bug which is so severe that it blocks a release. is now finally resolved!
Internationalization and localization is a core part of WordPress and relevant for more than half of all users. That’s why this functionality belongs natively into WordPress core and not in a (canonical) plugin. Merging Preferred Languages into core would allow the fallback logic to run much closer to where translation loading happens, reducing the risk for bugs and 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 incompatibilities. Plus, the UI impact is minimal, as it simply expands an existing language dropdown with additional features.
Implementation Details
The UI is built using TypeScript and React and the @wordpress/* npm packages also used for Gutenberg. This makes for a consistent look & feel and will make it easy to integrate it into any revamped WordPress adminadmin(and super admin) UI. The back end parts were developed in such a way that merging them into core eventually is as straightforward as possible, so a 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. can be developed relatively quickly.
Preferred Languages has been tested in production websites over numerous years by thousands of users. It works in all major browsers supported by WordPress, follows 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) best practices, and gracefully falls back to the old single language dropdown if JavaScriptJavaScriptJavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. is disabled.
Contributors and Feedback
While I (@swissspidy) have been the lead developer of the plugin, valuable input and contributions have come from others in the community.
This is a proposal and is subject to revision based on your feedback. If you haven’t already tried out the plugin, please download and install it from WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ or the comfort of your WordPress admin. You can review the current code and leave feedback at the project’s GitHub repository or in #core-i18n on SlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
All feedback will be collected over the next couple of weeks. After that, the received feedback will be discussed and next steps determined. The goal is to work on and land a patch quickly to ensure that the feature gets plenty of testing in WordPress 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..
WordPress 6.6 is set to be released on July 16, 2024. With a slightly shorter cycle, this release heavily builds on the foundation of the last with some new items, like section styles and overrides in synced patterns, and loads of enhancements to features that landed in the last few releases, including the Font Library and 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.. Data Views, the first taste of the admin redesign work introduced in 6.5, continues to evolve with new layout options, a combined template part and pattern experience, and more readily accessible management sections. Finally, design tools take center stage with everything from grid layout support to section styles to more power baked into style variations out of the box.
As always, what’s shared here is being actively pursued, but doesn’t necessarily mean each will make it into the final release of WordPress 6.6.
For a more detailed look at the work related to 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, please refer to the 6.6 board and review the currently open Iteration issues. After a recent organization effort, Iteration issues are meant to reflect active work that’s been scoped down for a 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.. To get a sense of some of what’s being worked on both for this release and beyond, check out the demos shared in a recent hallway hangout.
Foundational experience
Advancing the new Data Views in the Site Editor
Building on an initial launch in 6.5, the new views in the Site Editor continue to be refined and advanced. This includes work to bring the various management pages forward (manage all templates, manage all template parts, manage all pages) so those options are immediately seen when visiting the respective sections, reducing the number of steps to access important information. For pages, a new side by side layout will be introduced so one can see both a list of all pages and a preview of the currently selected page. For patterns, template part management will be removed and integrated into the current overall patterns section. Interspersed within all of these larger changes are smaller enhancements in functionality and feel.
A few different initiatives are coming together to allow one to focus on building with patterns rather than granular block editing, including advancing contentOnly editing and zoomed out view. Key features planned include:
A zoomed out experience in the editor when inserting patterns to facilitate high level overview of the site.
Ability to shuffle top level patterns within a template in order to quickly explore alternative patterns.
Ability to manipulate patterns in the template via moving, deleting, etc while zoomed out.
Improvements to UXUXUser experience for dragging patterns (e.g. vertical displacement).
Taken together, this work aims to offer a first step towards a new way to interact with and build with patterns. Some questions remain including whether zooming out will be invoked in certain situations, like the patterns tab of the Inserter, or if it’s something that could be toggle on/off as one wants.
Knowing where a block’s style comes from is key to knowing where a change might need to be made. For 6.6, work is underway to show locally the value that a block inherits globally, when applicable. This means that, for example, if you set a paragraph to always have blue text in Styles, every paragraph you added will show blue text and the block settings will show the blue color as the chosen text color. This is in contrast to today’s confusing experience, where it shows a circle with a line through it, to indicate that no local color has been set despite the block inheriting it globally.
Unifying editor experiences, including publish flow
This is both a technical and design effort, consolidating shared code and creating a single, coherent flow across the post and site editors for common tasks. The more noticeable and big pieces will be seen in a unified publish flow and a new singular “summary” inspector panel, which will also be reused within the site editor when you are bulk editing.
Mix and match typography and color palettes from all styles variations
Style variations allow you to change the look and feel of your site, all while using the same theme. To build on the design possibilities of a block theme with style variations, 6.6 aims to add the ability to mix and match the color and typography styles of each individual style variations. This means the eight community created style variations baked into the Twenty Twenty-Four theme turns into 48 styling combinations, thanks to the six typography presets and eight color presets available. Add in more typography options thanks to the Font Library and the optionality available is immense, alongside all of the granular tinkering you want to do. This evolution in style variation possibilities will work out of the box with all block themes with style variations with no additional opting in or adjustments on the theme author’s end.
Syncing specific blocks and attributes of patterns
Building upon synced patterns, overrides in synced patterns would allow users to ensure a synced layout and style across patterns while allowing each instance of the pattern to have customized content. This allows for consistency in design across different pieces of content. For instance, consider a testimonial pattern in a grid. With the enhanced feature, someone can insert this testimonial pattern into multiple posts, ensuring that the layout and styling components, such as the overall design of the recipe card, remain consistent across instances. Meanwhile, the content, such as Name, Image, and Role, would be local to each instance allowing for individual customization. Additionally, folks would then be able to revisit and modify the design of the overall testimonial pattern without affecting the content in existing instances. To get a sense of the current work happening here, check out the “overrides in synced patterns” demo from a recent hallway hangout below:
Expanding block style variations for more styling options
Through work to extend the block style variations mechanism, 6.6 is set to introduce the ability for theme authors to define style options for sections of multiple blocks, including inner blocks. With just a few clicks, folks using block themes that add this functionality could quickly change just a section of a page or template to predefined styles that an author provided, like a light or dark version of a section. This feature is coming together thanks to work to expand the block style variations API. There are a few ways folks are aiming to offer this functionality:
Programmatically via gutenberg_register_block_style
By standalone 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. partials within a theme’s /block-styles subdirectory
Via theme style variations defining block style variations under styles.blocks.variations.
Grid is a new layout variation for the Group block that allows you to display the blocks within the group as a grid, offering new flexibility. There are two options for the Grid layout:
“Auto” generates the grid rows and columns automatically using a minimum width for each item.
“Manual” allows specifying the exact number of columns.
Outside of expanding functionality, including trying to implement drag and drop resizing, work is also underway to improve using layout tooling in general to make it simpler and clearer to accomplish what you want.
To build on its debut in 6.5, the Font Library will continue to see 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 enhancements based on incoming feedback. This work will be less about adding new functionality and more about refining what’s landed.
Bringing the Site Editor experience for Pattern management to Classic Themes
Thanks to some internal code changes, the path is set to enable Classic Themes to have access to the new Patterns experience that the Site Editor provides. This will provide an upgraded, modern experience of managing and creating patterns.
This release cycle, a variety of initiatives are focused on improved loading times, especially template loading with improved caching of theme.json, block templates and computed styles as well as optimizing autoload options. Research and initial work to address potential improvements to the INP (Interaction to next pain) metric is also continuing in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. and the Interactivity API. In addition, ongoing performance improvements for the editor for this release are being tracked in this iteration issue, including major improvements to template loading.
Outside of the above efforts, work continues to improve performance tooling, including our automated performance test actions running in both 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/ and core. The current effort is focused on making the performance tests more consistent, robust and reliable and on providing an easy-to-use GitHub action developers can leverage to implement the performance tests in their own 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 or theme.
API iterations
Various APIs recently introduced in the last few releases are all slated for continued upgrades.
Interactivity API
The Interactivity API provides a standard way to allow developers to add interactivity to the frontend of their blocks. After the release of the initial version of the Interactivity API in 6.5, this next round of work is focused solely on enhancing the developer experience with better test coverage and code quality, improved error reporting, debugging tools, and fixing reported bugs.
Block 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.
Introduced in WordPress 6.4 and iterated upon in 6.5, the Block Hooks API is an extensibility mechanism that allows you to dynamically insert blocks into block themes. At this stage of maturity, work is underway to help determine a proper UIUIUser interface for hooked blocks and continued improvements to the developer experience.
HTMLHTMLHyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. API
Building on the initial launch in 6.2, work continues to evolve the HTML API with a focus on two aims for 6.6:
Complete and rely on a custom and spec-compliant encoder/decoder.
Design how to communicate when an HTML document has retroactively changed, allow calling code to match on, stop at, and modify implicitly-created elements, including when elements are closed.
The Block Bindings API launched in 6.5 allows you to bind dynamic data to block attributes, solving many use cases for custom blocks and powering other features, like overrides in synced patterns. This next round of work is focused on allowing the editing of connected sources directly from the block. As showcased in a recent Hallway Hangout, users can update the value of a custom fieldCustom FieldCustom Field, also referred to as post meta, is a feature in WordPress. It allows users to add additional information when writing a post, eg contributors’ names, auth. WordPress stores this information as metadata. Users can display this meta data by using template tags in their WordPress themes. by editing the paragraph connected to it. As part of that, the existing editor implementation is being refactored, and the editor APIs are being defined with the goal of “potentially” making them public for 6.6. Outside of the broader technical work, initial explorations are underway around a UI to create bindings, but it’s unlikely to land for 6.6.
Dropping support for PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 7.0 and 7.1
Support for PHP 7.0 and 7.1 will be dropped in WordPress 6.6, scheduled for release in July 2024. The new minimum supported version of PHP will be 7.2.24. The recommended version of PHP remains at 7.4 or greater. Read more in the Dropping Support for PHP 7.1 Make Core post.
Add rollbacks to auto-updates
Since WordPress 6.3, when an administrator is manually updating plugins, the plugin will not be reactivated if the update causes a PHP fatal error. During an auto-update, this reactivation check does not occur and the next time the site runs users will see the white screen of death (WSOD). To further protect websites and increase confidence in automatic plugin updates, 6.6 aims to include the ability to perform rollbacks when fatal errors occur during attempted plugin auto-updates by default. To learn more, please review the merge proposal for this feature.
Find something missing? Want to help?
If you have something you’re working on that you don’t see reflected in this post, please share a comment below so we can all be aware! If you’re reading this and want to help, a great place to start is by looking through each issue associated with each area or by diving into the Polish board where a curated set of issues are in place that anyone can jump in on.
The WordPress 6.5 retrospective survey is now closed. Thank you to everyone who responded! Expect a follow-up post with collected, anonymized results once @priethor, @marybaum, and @akshayar have finished processing all of the feedback.
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.2 was released on April 24. Read about what’s new in this release.
We’re in the 6.6 release cycle. @annezazu shared that the roadmap draft is well underway, and @ella has already created this tracking issue to coordinate PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher backports.
@fabiankaegy noted that it is worth calling out that there are still a few roles that are looking for volunteers. @priethor added: in particular, the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.TriagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Lead role is the one with the most in need of volunteers. There are a few inexperienced volunteers for the docs lead role, but it would be great if somebody with experience in the role could participate, too. Please reach out to @priethor directly if you have any questions.
A quick update about the next maintenance release, WP 6.5.3. There are currently 3 open trac tickets and 1 Gutenberg ticket left to resolve. A 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). is planned for May 2 at 17:00 UTC, with a tentative release date planned for May 7. There is more information about this release in this post, including 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 schedule and how you can get involved.
A quick reminder that our next Gutenberg release (18.3) is in progress and the Release Candidate is scheduled for May 2.
Discussion
We dedicated the discussion time to revisiting the conversation that was kicked off last week during our announcements related to recent #core-editor conversations about how we can improve how contributors follow along with editor updates and improve communication within the project.
To kick things off, @joemcgill shared some suggestions that @youknowriad posted on the agenda:
I know a lot of Core contributorsCore ContributorsCore contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. follow core updates by following the commits that happen on the #core slack channel. I believe that we should be doing the same for editor commits. These commits are already shared on slack on #core-editor-commits channel. That would be IMO a great way for core contributors to keep up with what’s happening on the editor side and potentially interact (even on merged PRs like we do for closed tickets on tracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress.) without waiting for the code to reach Core through backports or anything.
I think we can also consider showing these commits directly in the #core channel in Slack like we do for Core commits because in the end, these are core commits too, they just happen on another repository. Today we have between 10 and 20 commits per day, I think that’s an acceptable number that won’t “flood” the channel that much and would bring more visibility.
We discussed that we could experiment with posting commit summaries to the #core channel for a short period of time, such as a few weeks, and evaluate how it works. We also discussed that the commits from Core provide more detailed summaries compared to the commits to trunk on the Gutenberg repo, so this is a potential improvement for the Gutenberg commits. @audrasjb noted the Core handbook link for Commit message best practices.
@joemcgill said that he will follow up on moving this forward this week.
There was another concern in that discussion: many contributors that cannot contribute very regularly are missing when development starts for (major) new features. That results in not being able to start contributing to them in time, or not providing timely feedback, ideas, being able to test different approaches, etc. One of the ideas how to fix this was to start announcing when new major features development starts in dev. chat (and in the summaries). Seems most/nearly all contributors follow make/core and that would benefit them.
@priethor noted that Dev chat time is not very EU-friendly, asking folks to announce features here can be a big ask depending on the project.
@joemcgill summarised that there are several things to unpack here, primarily:
How can we make it easier for people to contribute to new features
What is the right timing and method for communicating updates at key milestones for a feature (e.g., merges, etc.)
@hellofromtonya suggested: How about a Make/Core post with links to tickets or project board and/or the key labels for tracking?
Open Floor
@afragen gave an update on the Merge Proposal: Rollback Auto-Update, and noted that we haven’t received any issues with testing so @afragen believes that it’s going well and we’re on our way to commit in a week or so. Also, there are 6000+ active users of the feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.. Please read the proposal and test the feature plugin in the next week, ideally before the next dev chat.
An update for the 6.6 release squad has been posted, please note that the release squad is looking for one or two CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.TriagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Leads to focus on triaging TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and a Documentation Lead with previous experience for the role.
Also, a reminder that the WordPress 6.5 retrospective post has been published, please fill in the survey if you would like to leave feedback or suggestions for improvements to the release process. The form and comments will be open until April 26th, 2024
There was also a recent discussion in the #core-editor channel around several topics linked to how we can improve how contributors follow along with editor updates and improve communication within the project. There were several potential actions discussed, including:
Create more high-level tracking issues that are not tied to a 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..
Create Slack channels for high-level features, such as navigation (#feature-website-navigation) and the grid 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. (#feature-grid).
Create teams on 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/ for high-level features to create an easy point-of-contact and discussion space for these features.
@annezazu called out that she did some recent work cleaning up 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/ repo, which should help with this, including getting high-level overview issues in place for all phase 3 items.
@marybaum asked if we could get more support for Mission Control for this or future releases. @audrasjb has access and is willing to learn, with support from @davidbaumwald and @sergeybiryukov.
@priethor announced that WP 6.6. is not meant to be a maintenance only release. The reasons are summarized in this comment.
Next maintenance release: 6.5.3
There are currently 15 open tickets in the 6.5.3 release milestone. There is more information about this release in this post, including 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 schedule and how you can get involved.
6.5.3 is still on target for 7 May. Scrubs have been moving things forward. There are a couple of at risk tickets so if you see something towards the bottom of https://core.trac.wordpress.org/tickets/minor/workflow, it would be good to jump in to help.
@peterwilsoncc previously raised that we should consider syncing the editor packages earlier in the release cycle. Could this be attempted for 6.6? Slack reference.
This process is documented here, but @youknowriad warned that a lot of that work is also manual for the PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher part and not something that doesn’t have a clear workflow.
@johnbillion noted a related issue, #60967, which could help with this process.
@joemcgill suggested that we put some focus on reducing friction of the PHP syncing during this release and will follow up with @youknowriad and tech leads @ellatrix, @vcanales, and @audrasjb about some next steps.
The full list of posts from the last week in Core can be read on the agenda at this link.
Open floor
There was no time for the open floor section during this dev chat, but @drivingralle did mention a potential ticketticketCreated for both bug reports and feature development on the bug tracker. for 6.6 on the agenda post:
Would be great if ticket #55184 could be included in 6.6.
TriagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Leads: After some discussion and feedback, the proposal to experiment with merging the CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. Triage and Edito Triage lead roles has been reverted. As a result of this, @fabiankaegy and @colorful-tones will focus on triaging 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/ repository, and therefore, the release squad is looking for one or two Core Triage Leads to focus on triaging TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..
Documentation Leads: In WordPress 6.5 it became clear that this role does need a bit of experience to enable the rest of the team’s contributions. Let’s ensure we find a Documentation Lead with prior experience to ensure they are able to handle release-specific work.
Default Theme Wrangler: The Default Theme Wrangler role was introduced as an experiment for 6.5 with the hopes of ensuring all default themes fully support any new features. After checking in with @poena and without any additional incoming feedback in the still-open 6.5 Release Retrospective, our recommendation is to drop the role from the squad since having the role on the squad hasn’t meaningfully impacted the default theme queue. This can be revisited in the future.
Default Theme Leads: As pointed out in the previous post comments, work towards the new default theme included in 6.7 should start during the 6.6 cycle. Even if not part of the 6.6 squad, folks interested in leading the next default theme in 6.7 are invited to express interest in the comments below. In particular, the first step to kick off the new theme would be to identify the theme designer(s).
Release squad as of April 23nd
Release LeadRelease LeadThe community member ultimately responsible for the Release.: Matt Mullenweg
The biggest risk for a site owner when updating plugins is encountering a PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher fatal error that crashes their website. While CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. updates are protected by automatic rollbacks since WordPress 3.7 (#22704), no such protection for plugins was added. Although fatal error protection and recovery mode were added in WordPress 5.2, it requires manual intervention from an administrator, and ideally WordPress should be able to recover on its own in a similar way that Core does. The Upgrade/Install team began exploring rollbacks for 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 updates.
Rollbacks for plugin updates comprises three features:
When active plugins are updated, they are briefly deactivated before the new version is installed and reactivated immediately after. Since WordPress 6.3, when an administrator is manually updating plugins, the plugin will not be reactivated if the update causes a PHP fatal error. During an auto-update, this reactivation check does not occur and the next time the site runs users will see the white screen of death (WSOD).
To further protect websites and increase confidence in automatic plugin updates within WordPress, the Rollback Auto-Update feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. aims to detect PHP fatal errors during automatic plugin updates, and subsequently rolls back to the previously installed version.
This proposal is to merge the changes required to also perform rollbacks when fatal errors occur during attempted plugin auto-updates by default.
Implementation
Rollback Auto-Update performs a loopback request to the homepage to check for PHP fatal errors, using an approach similar to the Plugin or Theme File Editors. If a PHP fatal error is encountered, an error handler logs the specific message and the previously installed version of the plugin is restored. When a plugin rollback occurs, a notification will be sent to the site’s administration email (stored in the admin_email option) notifying them of the failed update and rollback.
The current implementation attempts to detect a PHP fatal error during an automatic update by using a loopback request to the homepage. If the loopback returns an error, a PHP fatal error in the active plugin is assumed and the update will be reverted for safety.
After the problematic plugin is rolled back, the auto-updating process will continue for any other core, plugin, or theme updates that were in queue. When the next check for auto-updates occurs, WordPress will attempt to update the same plugin again.
Previously, maintenance mode was only enabled during installation of an update. However, testing established that disabling maintenance mode during the rest of the process means that active visits to the site can trigger errors. This can have side effects, such as deactivating plugins, etc. Rollback Auto-Update enables maintenance mode for the duration of all automatic updates. While maintenance mode is enabled for longer, this is relative to the number of updates being performed at that given time – usually a very low number – and helps improve stability of automatic updates.
At the time of publishing, this code is being tested on 6,000+ sites running the Rollback Update Failure feature plugin, which has contained the related code since v7.0.0 was released on 10/12/2023.
For easier testing of the feature within wordpress-develop, a merge PR (Core-5287) has been created.
Due to limitations in the ability to modify wp_is_maintenance_mode() in the feature plugin, the PR is slightly different. The feature plugin is available for historical reference. All pre-merge testing should be done using the PR. Some contributors have also been running the PR on sites for a few months.
Example of email text sent to site’s administration email.
Howdy! Plugins failed to update on your site at https://test.xxxxx.net.
Please check your site now. It’s possible that everything is working. If there are updates available, you should update.
The following plugins failed to update. If there was a fatal error in the update, the previously installed version has been restored.
This Plugin Should Not Be Used (from version 0.1 to 0.2) : https://wordpress.org/plugins/this-plugin-should-not-be-used/
To manage plugins on your site, visit the Plugins page: https://test.xxxxx.net/wp-admin/plugins.php
If you experience any issues or need support, the volunteers in the WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ support forums may be able to help.
https://wordpress.org/support/forums/
The WordPress Team
Testing
There are no known issues directly related to Rollback Auto-Update that don’t currently exist in Core.
I (@afragen) have been testing using the test plugin. The plugin is on a test site, active, and set to auto-update. I have been running like this since the beginning of the year using the PR and on other sites for several years using the feature plugin.
Install the PR into WP 6.5.x or 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..
The WordPress.org update 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. will serve the version 0.2 version of the plugin, which will cause a PHP fatal error. To confirm a rollback is successful, data is written to the error.log at every point in the auto-update process, creating an audit trail the user can use to discern the flow and results of rolling back an auto-update. This logging is only intended for testing purposes.
FAQ
Stay up to date with development on the PR. Please comment on the GitHub PR if any problems are discovered.
What happens if loopback requests aren’t working?
As demonstrated by the Site Health message for loopback requests that aren’t working: “Loopback requests are used to run scheduled events, and are also used by the built-in editors for themes and plugins to verify code stability.”
Auto-updates shouldn’t run if loopback requests aren’t working. If a loopback request fails due to an HTTPHTTPHTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. error, Rollback Auto-Update will consider it as a PHP fatal error detected, and revert any plugin updates.
As a project, it’s important to continuously evaluate ways to make site management easier for the large majority of users and site owners. Providing safer plugin auto-updates is just one way for WordPress itself to handle problems that may require technical expertise seamlessly for end users.
All feedback will be collected and addressed over the next 2-3 weeks, with the goal of committing to trunk after all feedback is addressed to ensure that the feature gets plenty of testing through the nightly builds early in the WordPress 6.6 release cycle.
You must be logged in to post a comment.