A month with the WordPress core team – February 2024

In February the team worked on various tasks including coding standards and accessibility fixes. In the past month, WordPress released beta 1, 2, and 3 of version 6.5. The next update is the first release candidate for 6.5, planned for March 4 2024.

Our monthly updates

Sergey

WordPress 6.5

For the past two months I continued triaging and reviewing tickets for the next major release, WordPress 6.5, as part of my duties as a Core Committer.

I made thirty-nine 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).

Some notable changes include:

• Updating PHPCS to version 3.8.1. See ticket #60279 for more details.
• Reducing usage of assertEquals() in favor of assertSame() in unit tests. See ticket #59655 for more details.
• Continuing with various coding standards fixes in core. See ticket #59650 for more details.

Carolina

Core & themes

As part of the release squad for 6.5, I have triaged new bug reports, worked on patches, and made decisions about postponing tickets to future releases. Most of all I have tested bugs and enhancements.

To make testing easier, I created a new XML file for the Theme Test Data repository. The new file contains blocks with different settings, and no “classic” content. Then I used the file as a way to generate content for basic visual regression testing with Playwright. I plan to improve the tests over time as I learn more about Playwright and the existing WordPress testing tools.

I helped move the bundled theme changelogs from the WordPress Codex to new documentation articles. Stephen Bernhardt did most of the work and I just copy pasted ?. I also refreshed some of the existing theme documentation pages to replace broken links and images.

Evaluating the theme wrangler role in the release squad

We are less than a month away from the release of WordPress 6.5, and I want to start evaluating my role in the release squad.
TLDR: I think it is important to keep the bundled themes up to date. It is beneficial for the person who is working on the bundled themes to stay informed about the active discussions about a release. But I’m not sure if or in what way the role is beneficial for the squad. I think that wether this role should be part of the squad or not, should depend on if there are major changes planned for themes.

Difficulties with implementing new features in the same release as they are introduced

One of the responsibilities for the theme wrangler is implementing features that are added in the current release. In reality, the bundled themes will always be at least one release behind. Because there is not enough information early on, and not enough time for implementation and testing before the feature freeze and code freeze.

Guarantee that all default themes fully support any new features added in the current release (as deemed appropriate)

Core Handbook

I think it’s important for one or more people to dedicate time and effort to ensure that the bundled themes are compatible with new editor features. This means that they need to be informed of changes that affect themes. And I think we as contributors can do better here.

• It can be difficult to learn about editor changes early enough to take action
  • If a change that effects themes is not announced until a Dev note is published, it is too late for the people working on the themes to implement changes.
  • This could be improved with better communication and better labelling of editor issues in the Gutenberg GitHub repository.
• Changes are merged into core late in the beta releases
  • If a change that effects themes is merged late, it can also be too late for the people working on the themes to implement changes.
  • This could be improved by merging changes earlier.

Reflecting over classic themes and block settings

I have been focused on block themes for the past few years. And I have learnt that making block settings work with the classic bundled themes is very time consuming. A bundled theme is required to be backwards compatible, and some of them support versions below 5.0. Over the years there has been changes to the blocks and the editor that has lead to two types of issues:

• Either the block settings do not work because of the theme’s CSS, or;
• The themes design breaks because of the block’s CSS and block settings.

When you create a bug fix, it needs to be tested across multiple WordPress versions to ensure that there are no (or not too many!) unexpected changes for the theme users.

There are a couple of things that we could do in Gutenberg to make this process easier. And that is to use class names for the block supports and avoid adding inline styles to the style attributes.
These are changes that have been proposed for years, but I want to remain hopeful that it can be improved.

Andrea

As usual, in the last month I’ve been focusing on testing, reporting, and attempting to fix accessibility issues in the WordPress admin and editor interface. Besides specific accessibility fixes, it appears there is an emerging trend of increased user interface inconsistencies across the editor that, in my opinion, don’t help the editor be perceived from users as an easy to use tool.
Historically, one of the WordPress’s strength has always been ease of use. However, the WordPress 2023 Annual Survey highlighted a pretty significant drop of the users feeling regarding the user interface. In 2022 32% of users cited ease of use as one of the three best things about WordPress. In 2023 that number dropped to 21.7%. I do believe all WordPress contributors should really focus on this data and start a collective effort to improve the editor user interface. On my side, I’ll try to focus more and more on this in the next future hoping to make things better and improve the general perception of the WordPress editor.