Editor chat summary: Wednesday, February 23 2022

This post summarizes the latest weekly Editor meeting (agenda, slack transcript), held in the #core-editor Slack channel, on Wednesday, February 23, 2022, 14:00 UTC.

General Updates

Gutenberg 12.7 RC1

Gutenberg 12.7 RC1 was released by @cbravobernal and is available to test.

WordPress 5.9.1

WordPress 5.9.1 was released yesterday. This maintenance release features 82 bug fixes in both Core and the block editor.

Async key project updates

We used to exchange key project updates synchronously during the chat. However, many of the key Gutenberg projects sustain a regular cadence of updates on their tracking issues on Github.

This week we tried async updates. The attendees are encouraged to read the latest updates directly from the following tracking issues at everyone’s leisure:

Task Coordination

@Mustaque Ahmed

@get_dave

Seeking more reviews on PRs that aim to make the Navigation block more internally consistent:

@Ciprian Popescu

Raised: Super broad selector for images max-width on WP 5.9.1 breaks image width to get some additional eyes on the issue.

@paaljoachim

  • Highlighted: Move post/page title to the top bar as a good issue that will help a lot of users on various levels. @vdwijngaert Koen worked on it but has not had the time to followup on it.
  • Is working on various issues that he gives design feedback to.

@kirtangajjar

Raised: Fixes pasting plaintext with HTML tags does not display them to get some 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.

Open Floor

@Zeb

Is looking for a final review of the work he has done on the Table of Contents block.

@mrwweb

Highlighted his Proposal to Standardized block markup, theme.json design tokens, and CSS classes to improve interoperability with the note:

There are a lot of people who work on custom themes who are struggling with some of the style and markup changes in 5.9 and don’t understand the roadmap for the future-compatible theme customization.I’m working on a proposal for one way to handle this that should be out later this week, but I want to just get it onto folks’ radar ASAP. In many ways, I don’t think there has to be a huge change in direction, but some new standards and an adjusted block approach to settings could go a really long way in supporting custom themes.

and later also added this follow up:

@luehrsen added to the above that any feedback on the discussion above would be very appreciated.

@bph

Raised awareness of the updates @get_dave has made to the GitHub releases of the Gutenberg plugin to highlight the contributed of each release.

@paaljoachim

Shared a discussion added by @jameskoster In relation to the Query Loop block.

@bph

Shared the recording from the second Gutenberg Developer Hours and announced that the next Developer Hours will be on March 8th, 2022 at 11am ET 16:00 UTC

@mamaduka

Raised an issue report on Twitter that needs some more testing on Windows.

Read complete transcript

#core-editor-summary, #summary

Proposal to Start a News blog on developer.WordPress.org

Staying on top of the new features coming to the WordPress open-source project is one of the main barriers expressed by developers.

The Make Core blog has a heavy emphasis on meeting notes for the various core teams, rather than highlighting new features. This makes it difficult for developers who are not contributors or who just occasionally contribute to find the relevant information among the team-related posts. 

To achieve one of the big-picture goals for 2022 (“Create a developer-focused communications site“), this is a proposal for creating a Developer News blog. The content focuses on updates for developers, extenders creating plugins and themes, and those who work with WordPress at an agency or as freelancers. 

Preliminary Timeline

  • Proposal and request for comment period: February 25 – March 18, 2022
  • Coordinate with Design and Meta Teams for theme (the News theme would be spectacular) 
  • Brainstorm meeting with team representatives: End of March
  • Content creation and first post: early April 2022 
  • Start-up phase: Through mid-July
  • Review and expansion to regular topics for developers: Fall 2022

Problem to be Solved 

The current developer.wordpress.org holds a ton of comprehensive documentation with examples, tutorials, getting started guides, and more. That being said, there are various improvements that could be made to make the site much more impactful. Some of these areas for improvement are outlined below. 

What’s missing: 

  • There is no changelog to signal various changes including when pages are updated or when new APIs appear or existing ones are augmented with new filters, hooks, and configuration. 
  • There is no mechanism to subscribe to updates. A blog would provide this feature. 
  • Outside #core-editor meetings and GitHub, there is no single place to keep up with  ongoing discussions. For example, to learn about the new styling engine, a developer needs to visit three sites: Discussion, Tracking Issues, and the first PR.

Start-Up Phase

As a first step, the Developer News can tackle the above pain points by:

  • Surfacing updates to documentation, 
  • Highlighting new tutorials, and, 
  • Providing a way for developers to subscribe to stay up to date 

The Developer News blog can also be added to the Planet WordPress feed, so post titles also appear in the WordPress News Widget in the WP Admin Dashboard. 

This initiative requires cross-team collaboration among contributors from the Documentation, Core (core-css, core-js, core-editor etc.), Training, and Support teams. 

These teams could use an existing WP Slack channel for synchronous meetings, such as #docs or #core. During the meeting, team reps and other contributors can make editorial suggestions for topics and links that could be included in the next edition of an update post.

An editorial calendar can be an early agenda item for the meetings. 

After the initial start-up phase, the blog would be extended to regular topical posts relevant to developers. 

Possible Ideas for Future Expansion

  • Summaries from GitHub Discussions 
  • Excerpts from meeting discussions for distribution to a wider audience of developers
  • A post consisting of a summary of multiple dev updates 
  • Useful questions/solutions found on StackOverflow/StackExchange 
  • Reviews of existing documentation to identify gaps 

A possible future expansion would include a regular revision process to update content with new information and changelog recording. 

I recommend that contributors to this initiative comply with the Make Core Post and Comment Guidelines. Should the editorial group decide to also include highlights of example plugins or themes, all products must adhere to the Community Team’s guidelines regarding GPL compliance of the products, including premium products. 

As mentioned above, these are just some initial steps to get processes and contributors in place. Reader comments and discussion in the Slack channel will surface opportunities for further enhancements. 

What do you think? How could this proposal be improved?
Please share  your comments, your thoughts, and content ideas. If you’d like to contribute to the Developer News, mention this also in the comments. The comment period on this proposal will end on March 18, 2022. 

Props to Dion Hulse (@dd32), Destiny Fox Kanno (@piyopiyofox), Tara King (@sparklinerobots), Anne McCarthy (@annezazu), Tonya Mork (@hellofromtonya), Daisy Olsen (@daisyo), Dan Soschin (@dansoschin), and Anjana Vasan (@anjanavasan) for fruitful collaborating on this proposal. 
Props to Mary Baum (@marybaum) and Jean-Baptist Audras (@audrasjb) for final review

#developer-news, #proposal

Dev chat summary, February 23, 2022

@marybaum led the meeting on this agenda from @webcommsat.

1. Welcome and announcements

WordPress 5.9.1 is out! This is a maintenance release that fixed 82 bugs across Core and the block editor.

Our 5.9.x minors leads are @audrasjb and @mamaduka. @estelaris is drafting the release posts.

2. Blog posts of note

What’s new in Gutenberg 12.6?

A Week in Core, February 21, 2022

3. Upcoming releases

WordPress 6.0

@afragen asked the group for last-minute feedback on his post that outlines a feature to handle plugin dependencies. The feature is an early 6.0 candidate.

@annezazu caught the group up on a dizzying array of activity around FSE and the block editor. She recommended this summary post from the earlier Core Editor meeting and noted that other work is still following the preliminary roadmap.

See the transcript for more detail.

WordPress 5.9.2

@audrasjb laid out preliminary plans for a quick 5.9.2 to address 20 tickets in the milestone. A firm schedule will come shortly.

4. Open Floor

@bph announced there’s a raw recording of the second Gutenberg Developer Hours on YouTube. She also said a recap post is in the works.

The next session is March 8.

@annezazu announced a call for testing that revisits the headers workflow, which has changed a fair bit since the original call. Note also that her announcement marks the return of the project’s usual calls for testing in the FSE Outreach Program.

@joyously had a concern about the way block themes look in older browsers. @estelaris shared a link to the GitHub Documentation Tracker, where folks can request new support articles.

February 8th Gutenberg Developer Hours – Session Evaluation

Previous posts about the event series Gutenberg Developer hours. 

TL;DR 

The first Gutenberg Developer Hours was a great success! Huge thank you to Tammie, Fabian, and Nick!  86.7% of survey takers rated it as Excellent. All 15 responders would place their recommendation into the likely half with 80% rating it a 10 (very likely)

These answers to open questions stood out: 

What did you like: 

  • Interesting topics, knowledgeable participants
  • Conversation. The different points of view.
  • Best practices, expert advice, very relevant to work we’re doing

What didn’t you like: 

  • Too Short
  • Probably a challenge to have different experience levels at once, but that was well handled.
  • If any of these Meetups should have been recorded of the dozen or more I’ve attended, it was this one. The live transcript is very valuable, and its absence a noteworthy lack of planning.
  • When there are many topics, it becomes a bit too diluted, and it felt like maybe not everything was said before continuing to the next question.

How did you hear about the event? 

  • 53% Meetup 
  • 33% Gutenberg Times
  • 13% Make Blog
  • 6% Twitter
  • 6% WPVIP

Below are topic suggestions for more Social Learning spaces.  

Based on your feedback, the producers have already enabled live captions for future events. They will record the sessions, too, so you can revisit them or catch up if you have to miss one. FOMO is real. 

Here are the details.  

Of 38 participants, 15 filled out the survey

What did you like about the event?

  • Direct and honest interaction with those in the know
  • Best practices, expert advice, very relevant to work we’re doing
  • The knowledge of the panel members. So much info!
  • Knowledge of the panel and their easy-to-understand explanations
  • My question was answered after I joined, I was quite late in joining and I was worried my question might already have been covered, but you waited till I joined and I’m very thankful you did. And of course it was great to get my question answered by several of the people in the meeting, and I also got a very useful link from Fabian which was great.
  • The panelists were the most knowledgeable group thus far on the Social Learning Meetups. Fabian and Nick were excellent.
  • The way the three panelists answered the questions.
  • Experts opinions
  • I got lots of links and advice on gutenberg
  • Interesting topics, knowledgeable participants
  • Conversation. The different points of view.
  • Discussion on Block-based themes.
  • Knowledgeable answers to questions. Good links. Good chat comments.
  • Learning new things about block themes.
  • All doubts were cleared

What did you dislike about the event?

  • It would be nice to have more questions & participation
  • I loved the event
  • too short! Not clear where the copied code is pasted when Nick said to “copy and paste.”
  • Not recorded so that we can go back and review information presented
  • I was late in joining so I didn’t get the full experience, but I think it might be good if future events can be recorded in case anyone misses it, or in case people who did view it live wish to watch some of it again.
  • If any of these Meetups should have been recorded of the dozen or more I’ve attended, it was this one. The live transcript is very valuable and its absence a noteworthy lack of planning.
  • Not really a dislike, for the first installment it was a great event. I think I’d prefer to have the Developer Hours be focused on a specific topic, so either block development, block theme development, or specific new functions, for example template locking.
  • Recording not available but it’s been discussed and hopefully from next Meetup
  • too short
  • When there are many topics, it becomes a bit too diluted and it felt like maybe not everything was said before continuing to the next question.
  • Nothing to report here.
  • Timing (just kidding :D)
  • Nothing I disliked. Probably a challenge to have different experience levels at once, but that was well handled.
  • Nothing in particular. Not a Zoom fan.
  • Nothing 🙂

How did you hear about this event?

  • Email from Meetup
  • from Brett Harris at VIP
  • email from Meetup (I go to other WP social meetups)
  • meetup notice of upcoming events
  • Gutenberg Times newsletter
  • I’ve been a member of the Meetup group since it started.
  • Twitter / Make Blog
  • Searching Gutenberg meet-ups
  • WordPress meetup
  • On WordPress.org and from Birgit
  • Gutenberg times, podcasts, meetup
  • From wp.org
  • Gutenberg Times
  • Your newsletter.
  • Through meetup.com

What topics should we cover in future Gutenberg Developer Hours?

  • I halfway answered this in the “what did you dislike” question, continuing from there: 
    • For these, maybe some demo time would be nice, so one of the panelists can explain things via screen sharing and then attendees can ask questions around that topic. 
    • So like best practices, how to work with theme.json, what part of the theme.json has which effect in the editor, block development (static vs dynamic blocks). 
    • In general I’d like to see some deeper going content, however I believe that squeezing this into one hour will be quite challenging.
  • Creating custom Gutenberg blocks
  • More gutenberg
  • I think it may help if the topics were limited to maybe 3?
  • Developer centric topics and case studies of unique site
  • FSE related topics
  • Multiple Answers:
    • How to monitor tracking issues. 
    • How to find up-to-date information on plugin development (much is very old, every course and book seems out of date). 
    • How to get the most out of reading the Gutenberg code. Ryan Welcher seems to be almost the only regularly updated source of current developer-level info, so this is an underserved area. 
    • Gutenberg best practices. 
    • Font loading in block themes. 
    • Building child themes for block themes. 
    • FSE theme best practices — color naming and style conventions. 
    • Code walkthroughs of block themes.
  • As of 5.9, when to use or develop plugins.
  • May be show some demo live sites using Gutenberg

Huge Thank you to the panel contributors

The second event took place February 22, 2022. A recording is now available on YouTube and a follow-up post will be available next week. This time we didn’t close the event and 100 people registered of which 47 attended, 40% repeat participants.

The next Gutenberg Developer Hours will take place on March 8th, 2022 at 11 am ET / 16:00 UTC

Thank you, also to @marybaum for her review of this post.

#developer-hours, #online-events

Feature Project: Plugin Dependencies

Problem

This feature project began as part of Outcome 4 of Updating the Updaters.

Any plugin that requires another plugin (i.e., a dependency) is on its own to make sure admins install the dependency. After all, the plugin will not work without it. But with more than 55,000 plugins in the repository, that means there are potentially 55,000 plugins capable of resolving the dependency.

It would be a lot simpler for users and admins, and plugin developers, if there were a consistent way to handle dependencies in Core. Among other things, that approach would entail a clear method of determining when a plugin needs a dependency and what that dependency is.

Improving the plugin experience.

There’s a whole category of plugins that are designed from the ground up to add new abilities to other plugins. Think of shipping and other add-ons for commerce plugins, and one-click checkout for event plugins that sell tickets.

The situation there is a lot like the relationship between parent and child themes. Without their relationships to the bigger plugin, those dependent plugins can do very little. As noted above, every plugin developer is on their own to code a solution to resolve the issue. And, as noted above, the single most common example is WooCommerce, which is a dependency for hundreds, if not thousands, of WooCommerce add-on plugins. 

What’s more, this is not a new problem. Across the WordPress ecosystem, people have been looking at it for at least nine years—starting with #22316.

The original scope listed in #22136 was the following.

  • Plugins list WP.org slugs of their dependencies in their readme.txt, or perhaps better their plugin’s header.
  • When you go to install a plugin via the plugin directory UI in the admin area, the WP.org API returns a list of dependencies along with the data about the plugin being installed. WP would say like “these following dependencies will also be installed”. This means it’s seamless to the user — they install a plugin and the other plugin(s) that are needed get installed too.
  • No versioning support. It’s too complicated and what if one plugin wants an older version of a dependency than another plugin does? If your plugin is listing another as a dependency, then it’s your job to make sure it stays compatible with the latest version of the dependency. On the flip side, hopefully plugins that get listed as dependencies are made to be forwards and backwards compatible.
  • Probably not allowing the disabling of plugins that are dependencies while their dependents are active. This seems better than disabling the dependents when the dependency is disabled (“why did Foo get disabled? I only disabled Bar!”).
  • On plugin re-activation or on activation of a plugin uploaded via FTP, make sure it’s dependencies are already installed. If not, offer to install them. If installed but disabled, just enable them for the user.

The last bullet point implies automatic installation and/or activation, after previous discussions, it was thought this should be discouraged in the name of preventing a very jarring user experience.

Fundamentally there should be a simple, clear method for identifying and installing plugin dependencies. Any plugin that requires a dependency should degrade gracefully if that dependency is not present. This is the responsibility of the plugin developer.

Design/Discovery

There are hundreds of comments, ideas, and decisions that have been discussed on #22316 and on some of the PRs below. I will attempt to summarize.

  • This is not an attempt to create a plugin package manager.
  • This is not an attempt to integrate Composer into WordPress or use Composer.
  • The agreed upon interface is via a plugin header, Requires Plugins, containing a comma-separated list of plugin slugs.
  • The most agreed upon UI for notifying users of a missing dependency requirement is via an admin notice.
  • There is no attempt at version control. The current plugin version in the dot org repository will be used.
  • There is no automatic installation or activation of the dependent plugin.
  • If the dependency requirements are not met, the requiring plugin cannot be activated.
  • Dependencies outside of the dot org repository are not supported. Out of scope at this time.
  • This is only for plugin dependencies that are required not recommended.
  • Plugin dependencies for themes is out of scope at this time.

Current Suggested Solutions

There are currently two approaches to handling plugin dependencies.

Similarities

  • Both use a plugin header, Requires Plugins, that contains the plugin dependencies within a comma-separated list of dot org plugin slugs.
  • Both show the user an admin notice if there are plugin dependencies should be installed.
  • Users must actively install and activate the dependencies.
  • Users will find they cannot delete or deactivate installed and activated plugin dependencies without deleting or deactivating the plugin that requires the dependency.
  • Relevant messaging in the dependency plugin row of the plugins page. (Formatting differs between approaches)
  • Neither approach makes any attempt at dependency version control. Most recent version of dependency from dot org is used.

Differences

The differences in the two approaches are subtle, but they do exist.

Current PRs

Approach 1

https://github.com/WordPress/wordpress-develop/pull/1547

  • Shows an admin notice for each plugin dependency to both inform the user of the dependency and lets the user install/activate with a click.
  • Plugins with unmet dependencies do not get activated; they go into an activation queue. Once dependencies are met the plugin is activated. 
  • Users can cancel activation requests for plugins with dependencies. Messaging added as an additional element to the plugin row.

Screenshots from PR

I hope the screenshots are representative of the PR. If not, it is entirely my fault (@afragen)

Approach 2

https://github.com/WordPress/wordpress-develop/pull/1724

  • A single admin notice alerts the user to unmet dependencies in any plugin. If multiple plugins have dependency problems, the notice compiles all the notices in one place. This notice persists until all dependencies have been installed. 
  • Adds dependencies using a new view/tab/filter on the plugins-install.php page.
  • On the plugin card, shows which plugins require which dependencies.
  • Once a particular dependency is installed, shows a list of plugins that require it at the end of the plugin’s description in the plugin row.
  • Adds relevant messaging to the plugin’s description.
  • Automatically deactivates any plugin that has unmet dependencies and informs the user in an admin notice. 
  • Lets the user deactivate or delete a dependency if the requiring plugin is not active.
  • Install the Plugin Dependencies Tab plugin as a possible feature plugin.

Some of the screenshots below may be slightly outdated.

Screenshots from PR

When attempting to activate a plugin with unmet dependencies.
Dependencies tab info

Further Discussion

Pertinent discussions about the best way to implement this are still needed. It doesn’t have to be one of the above approaches, but they are certainly starting points.

Thanks to @peterwilsoncc, @aristath, @audrasjb, @karmatosed, @costdev for assistance along the way. Thanks @marybaum, @bph for editing assistance.

Special thanks to @francina for the initial nudge.

#core, #feature-plugins, #feature-projects

Dev Chat agenda, February 23, 2022

The weekly developers chat takes place in the Make WordPress core channel on Slack at 20:00 UTC every Wednesday. Everyone is welcome to follow along and take part.

1. Announcements

Dev chat summary from last week (February 16, 2022). Thanks to @estelaris, @webcommsat and @marybaum for the notes. Could you volunteer to draft the summary from this week’s meeting?

The WordPress 5.9.1 maintenance release came out on February 22, 2022! Download and install for your website.

For more background: WordPress 5.9.x release team and 5.9.1 schedule – thanks to @audrasjb and @mamaduka for leading this, and to everyone who contributed.

2. Blog posts of note

What’s new in Gutenberg 12.6? (published February 16, 2022)

A Week in Core (published 21/2/22) 

3. Update on upcoming releases

(Updated 22:16 UTC by @webcommsat)

WordPress 6.0 Development Cycle

4. Open Floor

If you are a component maintainer and have an issue to highlight or would like some help, please add a comment.

For other blog posts relevant to core’s dev chat, please add them in comments for the team reps @marybaum and @audrasjb to pick up for the meeting.

Thanks to @marybaum for reviewing the agenda and @webcommsat for finding relevant links.

#5-9-1, #agenda, #dev-chat

Performance team meeting summary 22 February 2022

Meeting agenda here and the full chat log is available beginning here on Slack.

Focus group updates

Announcements

@shetheliving

  • Database optimization focus area
    • Want to reassess the interest for this as a focus group
    • Please re-vote on the focus group spreadsheet here by adding/removing your WP.org username from the groups that you want to work on in Column D, Contributors wordpress.org username
    • Please only enter your name on two or fewer groups. If you’ve already voted and want to revise, remove your name from other areas.

Images

@adamsilverstein @mikeschroder

GitHub project

Feedback requested

Object Cache

@tillkruess @spacedmonkey

GitHub project

Feedback requested

Site Health

N/A

GitHub project

  • We’re seeking 1-2 POCs for this group; if you’re interested, please comment here or ping in Slack
  • No updates

Feedback requested

Measurement

@wp-source @josephscott

GitHub project

Feedback requested

JavaScript

@aristath @sergiomdgomes

GitHub project

  • @sergiomdgomes: Continued discussion around embeds and how we could avoid the performance impact some of the larger ones, like YouTube, through façades or other approaches in the context of blocks; welcome thoughts and feedback

Feedback requested

Infrastructure

@flixos90

GitHub project

Feedback requested

Open Floor

  • @pbearne: Suggest that we work on taking care of some low-hanging fruit outside of the main focus areas
    • @tweetythierry: A prioritization exercise of those items would be helpful
    • @flixos90: Always okay to bring those up here and ask for feedback, but be sure that we’re paying the most attention to focus area items to keep them moving, since we decided that they were the most important. Let’s be conscious of the performance impact, especially.
    • @adamsilverstein: One idea would be to run a bug scrub for existing Trac issues tagged with performance as an ongoing effort

Help wanted

#core-js, #core-media, #performance, #performance-chat, #summary

A Week in Core – February 21, 2022

Welcome back to a new issue of Week in Core. Let’s take a look at what changed on Trac between February 14 and February 21, 2022.

  • 33 commits
  • 48 contributors
  • 57 tickets created
  • 20 tickets reopened
  • 70 tickets closed

The Core team is currently working on the next minor release, WP 5.9.1, and on the next major, WP 6.0 🛠

Ticket numbers are based on the Trac timeline for the period above. The following is a summary of commits, organized by component and/or focus.

Code changes

Administration

  • Fix a CSS issue on the Welcome Panel when the “Dashboard” heading is missing – #54977

Bundled Themes

  • Twenty Seventeen: Remove bottom border (box-shadow) from linked images – #55141
  • Twenty Twenty-One: Allow editor styles to control block margins – #54250
  • Twenty Twenty-Two: Bump theme version to 1.1 – #55056

Cache API

  • Add wp_cache_flush_runtime function – #55080

Coding Standards

  • Rename some variables in iis7_add_rewrite_rule() for consistency – #54728

Docs

  • Correct parameter types for data_wp_validate_boolean()#54725, #54729
  • Fix typo in TracTickets::isTracTicketClosed() description – #54729
  • Improve some DocBlocks in wp_validate_boolean() tests for consistency – #54725, #54729
  • Use third-person singular verbs in some test descriptions in phpunit/tests/functions/#54725

Editor

  • Adds an additional check to guard against incompete presets – #55161
  • Automatically apply global styles duotone filters to render in post editor – #55190
  • Backport Duotone fixes for 5.9.1 – #55179
  • Grant only admins access to the “Navigation Menus” UI for block and non-block themes – #54889
  • Prevent front-end assets of a block from being enqueued in the block editor – #55151
  • Update block editor packages for WordPress 5.9.1 – #55179
  • Fix PHP warning in WP_REST_Global_Styles_Controller if no styles exist – #54900
  • Load the global styles before the theme styles in the editor – #55188

External Libraries

  • Update random_compat to version 2.0.21 – #55181
  • Upgrade PHPMailer to version 6.5.4 – #55187

Filesystem API

  • Use a temp folder for Content-Disposition files – #55109

Networks and Sites

  • Remove unnecessary commented code from remove_user_from_blog()#55170

Script Loader

  • Improvements to the load block support styles mechanism – #55148
  • Load block support styles in the head for block themes – #55148
  • Load block themes styles in the head section – #55148
  • Prevent normalizing data URIs in _wp_normalize_relative_css_links()#54243, #55177

Tests

  • Convert _wp_to_kebab_case() tests to use a data provider – #54725
  • Correct the @ticket reference in a download_url() test with the Content-Disposition header#55109
  • Correct the order of expected and actual values in get_status_header_desc() tests – #54725
  • Correct the order of expected and actual values in wp_array_slice_assoc() tests – #54725
  • Correct the order of expected and actual values in wp_validate_boolean() tests – #54725

Themes

  • Allow extending WP_Theme_JSON and WP_Theme_JSON_Resolver classes – #55178, #55179

Widgets

  • Missing markup from Widgets Group block – #55072

Props

Thanks to the 41 people who contributed to WordPress Core on Trac last week: @oandregal (6), @azouamauriac (4), @jrf (3), @SergeyBiryukov (3), @ironprogrammer (3), @Mamaduka (3), @sabernhardt (2), @nidhidhandhukiya (2), @swissspidy (2), @aristath (2), @ntsekouras (2), @noisysocks (2), @scruffian (2), @audrasjb (2), @wpsoul (1), @youknowriad (1), @paragoninitiativeenterprises (1), @hellofromtonya (1), @mikachan (1), @peterwilsoncc (1), @kapilpaul (1), @Faison (1), @critterverse (1), @rolfsiebers (1), @antonynz (1), @gziolo (1), @ocean90 (1), @stacimc (1), @mukesh27 (1), @hellofromTonya (1), @Synchro (1), @ajlende (1), @rafiahmedd (1), @Spacedmonkey (1), @tillkruess (1), @flixos90 (1), @adamsilverstein (1), @barryhughes (1), @abhanonstopnewsuk (1), @staatic (1), @jeherve (1), @sergeybiryukov (1), @costdev (1), @talldanwp (1), @petaryoast (1), @manfcarlo (1), @pyrobd (1), and @Boniu91 (1).

Congrats and welcome to our 5 new contributors of the week: @rolfsiebers, @antonynz, @barryhughes, @staatic, @pyrobd ♥️

Core committers: @sergeybiryukov (13), @audrasjb (9), @jorgefilipecosta (4), @hellofromtonya (3), @ocean90 (2), @spacedmonkey (1), and @clorith (1).

#5-9-1, #6-0, #core, #week-in-core

Performance Chat Agenda: 22 February 2022

Here is the agenda for this week’s performance team meeting scheduled for Tuesday, February 22, 2022 at 04:00 PM UTC.


This meeting happens in the #performance channel. To join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #meeting, #performance, #performance-chat

Editor Chat Agenda: February 23rd 2022

Facilitator and notetaker: @fabiankaegy.

This is the agenda for the weekly editor chat scheduled for Wednesday, February 23rd 2022, 15:00 CET. It follows the proposed new format with more emphasis on the Open Floor discussion.

This meeting is held in the #core-editor channel in the Making WordPress Slack.

If you are not able to attend the meeting, you are encouraged to share anything relevant for the discussion:

  • If you have an update for the main site editing projects, please feel free to share as a comment or come prepared for the meeting itself.
  • If you have anything to share for the Task Coordination section, please leave it as a comment on this post.
  • If you have anything to propose for the agenda or other specific items related to those listed above, please leave a comment below.

#agenda, #core-editor, #core-editor-agenda, #meeting