A month with the WordPress core team – May 2024

In May the team prepared for WordPress 6.6. We have tested the data views feature and continue to help polish the user interface to improve the usability and accessibility of the editor.

In mid June, Andrea and Carolina plan to attend WordCamp Europe 2024 in Torino, Italy. We hope to see you there!

Our monthly updates


In May I missed out on a full week of work and I did not get as much done before 6.6 Beta 1 as I wanted.

In Gutenberg I have narrowed down the problems with the featured image setting for the Media & Text block and opened new issues. I have tried several solutions and have needed to request help from others because this has not been an easy task.
I created my first PHPUnit test for a block in Gutenberg and I’m curiously waiting for the code review so that I can learn more.

For themes, there was an important proposal published about the changes to the WordPress.org themes team.
The bundled theme task force has continued to hold Trac ticket triage meetings on Slack. Together we are moving tickets forward, but many new tickets are also being opened at the same speed.
This past Tuesday the Themes team also had the first meeting about the next default theme, and we have two tasks assigned that will help us brainstorm about the theme’s features and design.


In the last month, as usual, I focused on reporting and attempt to fix accessibility issues and improve user interface consistency in the Gutenberg editor. I reported a series of issues and submitted a few pull requests. Accessibility is not only about remediating existing issues though. It’s also about providing tools to prevent issues.

Contributors interested in development tools may want to have a look at a new Stylelint rule I added into the Gutenberg project. Stylelint is a CSS linter that helps prevent errors and enforce conventions in your CSS. It also allows to add custom linting rules to enforce best practices and rules for a specific project. For accessibility, the CSS order property is highly problematic. Content must be presented in a meaningful sequence and focusable components must receive focus in an order that preserves meaning and operability. Basically, that means that in most of the cases the visual, reading, and DOM order must match. As such, the CSS order property can only be used for ‘decorative’ purposes that don’t affect meaning and operability. In the editor, there have been several cases where the order property was used inappropriately. There’s now a new CSS linting rule to prevent such usages and to favor education. Contributors can still use this property but they’re now required to add a disable comment with a disable reason. The editor also uses CSS-in-JS and I still have to work on a JavaScript counterpart rule. Any help is very welcome.

On the community side, my task as Roma WordPress Meetup co-organizer is proceeding pretty well. At the last meetup we had the opportunity to connect with the WordPress community from Costa Rica thanks to Alfredo Navas Fernandini who gave a very interesting talk about the editor’s Patterns. The local meetups season is almost over. On June we’ll hold the last meetup for this season. It has been a pleasant experience to connect more directly with the WordPress community and I’m glad I’ve had this opportunity.


WordPress 6.6

I made thirty-four commits to WordPress core, mostly various bug fixes and enhancements. I also triaged new tickets incoming into Trac (the bug tracking system that WordPress uses).

In our weekly mob coding sessions with Carolina and Andrea, we continued looking into reorganizing the WordPress core unit test suite for compatibility with newer PHPUnit versions, specifically splitting existing test classes into multiple files and removing method-level @covers tags in favor of class-level @covers tags to allow for supporting PHPUnit 11 attributes instead of annotations. See ticket #53010 for more details.

Some other notable changes include:

  • Continuing with various coding standards fixes in core. See ticket #60700 for more details.
  • Reducing usage of assertEquals() in favor of assertSame() in unit tests. See ticket #60706 for more details.