Bug Scrub Schedule for WordPress 6.6

Scheduled bugbug A 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 candidate One 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.

Continue reading

#6-6, #bug-scrub, #core

Summary, Dev Chat, May 15, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @annezazu. 🔗 Agenda post.

Announcements

A reminder that the WordPress 6.6 roadmap has been published. Please also read and leave feedback on the Server to client data sharing for Script Modules proposal. Feel free to leave feedback either during Dev Chat or on the proposal post.

Forthcoming Releases

We’re currently in the WordPress 6.6 release cycle. You can find out more about the release squad in this post.

@annezazu noted that after a discussion in the public #6-6-release-leads channel, there is an update underway for the remaining roles yet to be filled. This has now been posted here.

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 BetaBeta A 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.

Note: Since the meeting, the WordPress 6.6 release squad is ready.

Canonical blockBlock Block 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 CoreCore Core 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.

Props to @mikachan for proofreading.

#6-6, #core, #dev-chat, #summary

WordPress 6.6 release squad ready

This post is a follow-up to the WordPress 6.6 call for volunteers update.

I’m glad to announce the WordPress 6.6 release squad is ready and the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. and Documentation lead roles have been filled:

Big thanks to everybody who volunteered to the release squad or to mentor and support!


Thanks to @chanthaboune for reviewing this post.

#6-6 #planning

Summary, Dev Chat, May 8, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @joemcgill. 🔗 Agenda post.

Announcements

The WordPress 6.6 roadmap has been published.

WordPress 6.5.3 was released on Tuesday, May 7. This minor releaseMinor Release A 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 bugbug A 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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and 9 bug fixes for the blockBlock Block 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 BetaBeta A 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 triagetriage The 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 regressionregression A 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 tracTrac An 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.
  • GutenbergGutenberg The 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 trunktrunk A 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. branchbranch A 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.

@johnbillion raised #61173: if anyone wants to help with that workflow that would be great.

Open Floor

@azaozz requested 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 loopLoop The 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 patchpatch A 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 pluginPlugin A 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_dir filterFilter Filters 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.

@kkmuffme requested some final reviews on the following PRs:

@grantmkin also 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.

Props to @joemcgill for proofreading.

#6-6, #core, #dev-chat, #summary

Merge Proposal: Preferred Languages

Almost 8 years ago the Preferred Languages feature project was kicked off in response to a feature requestfeature request A 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 Plugin A 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, bugbug A 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 coreCore Core 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 UIUI User interface is a pretty standard feature that can be seen for example also in operating system and browser settings.

Preferred Languages UI, showing the list of selected languages on the settings page.
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, GutenbergGutenberg The 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 ReactReact React 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 blockBlock Block 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 translationtranslation The 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 blockerblocker A 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 pluginPlugin A 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 patchpatch A 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 accessibilityAccessibility Accessibility (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 JavaScriptJavaScript JavaScript 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.org The 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 SlackSlack Slack 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 trunktrunk A 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..

Props to @ocean90 for reviewing this post.

#6-6, #feature-plugins, #feature-projects, #i18n, #merge-proposals, #polyglots, #preferred-languages

Roadmap to 6.6

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 APIAPI An 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 blockBlock Block 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 release A 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. 

Manage template screen showcasing the side by side layout with navigation on the far left, a list of templates in the middle, and a larger preview window on the right showing the current template.

Follow this tracking issue for more information. 

Zoom out to compose with patterns

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 UXUX User 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. 

Pattern inserter open to Banner patterns with the content of the site zoomed out, showing more of the template that the pattern is going to be added to.

Follow this iteration issue for more information. 

View inherited style values

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. 

Follow this issue for more information. 

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. 

Follow this iteration issue for aligning features and this tracking issue for the inspector controls for more information. 

Design tools

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. 

Follow this iteration issue for more information. 

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:

Follow this iteration issue for more information 

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.jsonJSON JSON, 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.

To see a very early look at this work, check out the “Section Styles” demo from a recent hallway hangout.

Follow this iteration issue for more information. 

Improvements to Grid Layout

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.

Follow this tracking issue for more information and/or join the dedicated #feature-grid slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel. 

Refining the Font Library 

To build on its debut in 6.5, the Font Library will continue to see bugbug A 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. 

Follow this iteration issue for more information. 

Additional supports

A selection of smaller efforts come together to provide more design options directly in the editor:

Adoption pathways

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.

Follow this iteration issue for more information. 

Continued performance improvements

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 coreCore Core 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 GutenbergGutenberg The 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 pluginPlugin A 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.

Follow this iteration issue for more information and/or join the dedicated #core-interactivity-api slack channel. 

Block HooksHooks In 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 UIUI User interface for hooked blocks and continued improvements to the developer experience. 

Follow this tracking issue for more information. 

HTMLHTML HyperText 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.

Follow this iteration issue for more information. 

Custom Fields & Block Bindings API

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 Field Custom 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.

Follow this iteration issue for more information.  

Dropping support for PHPPHP The 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.

Thank you to @adamsilverstein @joemcgill @fabiankaegy @get_dave @ellatrix for reviewing and contributing to this post!

#6-6, #release-roadmap

Summary, Dev Chat, May 1, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @joemcgill. 🔗 Agenda post.

Announcements

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.

GutenbergGutenberg The 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.

The remaining Phase 3 related overview issues were created for folks to join Phase 3: Block LibraryPhase 3: WorkflowsPhase 3: Revisions, and Phase 3: Collaboration index. Thanks to everyone who worked on creating and updating these Phase 3 issues!

Forthcoming Releases

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 PHPPHP The 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 CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Triagetriage The 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 candidate One 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 bugbug A 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 Contributors Core 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 tracTrac An 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.

@azaozz noted:

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:

  1. How can we make it easier for people to contribute to new features
  2. 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 Plugin A 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.

#6-6, #dev-chat, #summary

Summary, Dev Chat, April 24, 2024

Start of the meeting in SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., facilitated by @mikachan.
🔗 Agenda post

Announcements

An update for the 6.6 release squad has been posted, please note that the release squad is looking for one or two CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Leads to focus on triaging TracTrac An 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 release A 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 blockBlock Block 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 GitHubGitHub GitHub 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 GutenbergGutenberg The 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.

Tied to this, 6.6 is the start of having set iteration labeled issues that are targeted for the release and should make it easier to follow release-specific, in-progress work: https://github.com/WordPress/gutenberg/labels/%5BType%5D%20Iteration

@jorbin suggested a make/core post outlining more specifics about the intended process for the iteration issues, to make sure things stay up to date.

@mikachan believes that a summary post is being written to help summarize the next steps from the discussion that happened over in #core-editor.

@johnbillion and @priethor both expressed concerns about potential siloing if we experiment with adding more feature channels.

Forthcoming releases

Next major release: 6.6

We are currently in the WordPress 6.6 release cycle.

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 bugbug A 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.

@jorbin gave the following update:

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.

There are also a few tickets on GitHub so look towards the left there to see tickets you can help move forward https://github.com/orgs/WordPress/projects/186

Next Gutenberg release: 18.2

Gutenberg 18.2 is scheduled for April 24 and will include these issues. During the meeting, @colorful-tones asked for support with a problem encountered while publishing.

Discussion

@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 PHPPHP The 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.

@afragen published the Merge Proposal for Rollback Auto-Update and asked for more testing and feedback in order to commit this early during the cycle.

Highlighted posts

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 ticketticket Created 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.

Props to @mikachan for reviewing.

#6-6, #dev-chat, #summary

WordPress 6.6 call for volunteers update

This post is a follow-up to the initial WP 6.6 call for volunteers.

Relevant Updates

  • Triagetriage The 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 CoreCore Core 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 GutenbergGutenberg The 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 TracTrac An 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


Thanks to @annezazu, @chanthaboune and @poena for reviewing this post.

#6-6 #planning

Merge Proposal: Rollback Auto-Update

Background

The biggest risk for a site owner when updating plugins is encountering a PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher fatal error that crashes their website. While CoreCore Core 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 pluginPlugin A 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:

  1. move_dir() – Introduced in WordPress 6.2 (#57375)
  2. Rollback for plugin/theme update failures when updating manually – Introduced in WordPress 6.3 (#51857)
  3. Rollback for plugin auto-updates when failures are encountered – Covered by this proposal (#58281)

Some background references

Overview

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 Plugin A 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.org The 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.

  1. Install the PR into WP 6.5.x or trunktrunk A 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..
  2. Install version 0.1 of the test plugin.
  3. Activate the test plugin and enable auto-updates.

The WordPress.org update APIAPI An 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 HTTPHTTP HTTP 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.

Props: @costdev and @desrosj for review and editing.

#6-6, #feature-projects, #feature-autoupdates, #merge-proposals, #rollback