Another month came and went, and we left 2022 behind. Our team was very productive this year! In fact, we were the most active company in the WordPress project after Automattic. In December, most of our team took some well-deserved and needed time off. As a result, the update for December will be a bit shorter.
Our monthly updates
In December, my focus remained on some long-standing projects:
SQLite in WordPress
After many months, we finally managed to merge the SQLite implementation in the Performance Lab plugin, and it is available to test. Following some comments in the call-for-testing blog post, we decided to release it as a stand-alone plugin as well. The stand-alone plugin is now available in the WordPress plugin repository as “SQLite database integration“.
Forms in Gutenberg
I continued working on the implementation of the forms blocks in Gutenberg. The pull-request needs some testing, but I feel it is at a point where we can easily merge it in the plugin. The fact that it’s marked as an experiment will also make it easier to merge the implementation without worrying about its experimental nature. Users will need to opt-in to use it. For more information and testing you can head on to #44214.
In December, I have been focusing on some internal projects, and I haven’t had much time for WordPress core or Gutenberg.
To give a picture of the latest accessibility issues I’ve been focusing on, it’s best to take into consideration the work done in the last couple of months. I spent a good amount of time investigating new issues and some regressions. Most of them were related to managing focus, constraining tabbing, and the new ‘Browse mode’ for the Site editor.
Amongst these issues, the most interesting ones are #45903 and #46041 about constraining tabbing within some components, typically but not limited to modal dialogs. These issues proved once again, that when it comes to accessibility, it is very important to test with all browsers. Not all modern browsers behave exactly the same. Their behavior differs, especially when it comes to things like keyboard focus, handling focus losses, and the like. It’s also important to note that all unit tests or E2E tests that are related to accessibility should run with all browsers.
Playwright provides the ability to run tests with various browsers, for example, Chromium, Webkit, and Firefox. These should be the browsers to test accessibility issues with, at the very least. Worth noting: Some of these bugs surfaced only when extending some tests to run with Webkit and Firefox, in addition to the default Chromium.
The discovered bugs (some of them were actual regressions) are now partially fixed. A more comprehensive fix is in the works. For a full fix, I’d like to draw some attention to #45809.
There are a few places in Gutenberg where components use a scrollable div element. Firefox is the only browser that makes scrollable elements focusable. All other browsers don’t. This has an impact on the user experience, accessibility, and also on testing. To reliably test with all browsers, the ‘focusability’ of scrollable elements should be standardized by means of a dedicated component.
As it turns out, Gutenberg has a
Scrollable component. It needs to be improved though, and its usage extended to replace all occurrences of hardcoded scrollable elements. Any help and feedback is very welcome on the related issue #45809.
For the past month, I continued triaging and reviewing tickets for the next major release, WordPress 6.2, as part of my duties as a Core Committer.
I made fifty-two commits to WordPress core, mostly various bug fixes and enhancements. I also led two meetings for new core contributors and triaged new tickets incoming into Trac (the bug tracking system that WordPress uses).
Some notable changes include:
- Continuing with various unit test improvements in core. See ticket #56793 for more details.
- Renaming function parameters that use reserved PHP keywords. While using reserved PHP keywords as parameter name labels is allowed, in the context of function calls using named parameters in PHP 8.0+, this will easily lead to confusion. To avoid that, it is recommended not to use reserved keywords as function parameter names. See ticket #56788 for more details.
- Upgrading PHPMailer to version 6.7. This is a bug fix release which also contains some PHP 8.1 related improvements. See ticket #57281 for more details.
In December I had some time off for Christmas and New Years, but here is what I worked on:
For Gutenberg I made two improvements for handling the size of the featured image block, which has been merged.
I still have three open pull requests related to featured images that needs testing. Here I am working towards making the featured image block settings match the image block settings better, to make the blocks easier to use.
I am looking at solutions for displaying the image caption field from the media library, because users have reported that this is something they need before they can switch to using blocks instead of the classic editor.
I have also continued the work on the details and summary block and the post excerpt length option.
The feature I am most excited about it is the per block custom CSS option in the Styles sidebar in the Site Editor. It makes it easier to add custom CSS to specific blocks since you don’t need to know the block selector.
My most challenging work lately has been to explore if we could edit the navigation overlay; the mobile menu, separately from the navigation block. By using a new type of template part for the overlay, we should be able to add almost any block to the mobile menu. This feature is far from ready and the work has been explorative.
For WordPress core, I have focused on issues related to the bundled themes. In WordPress 6.2, the plan is to allow classic themes to enable the new border, spacing and link color options. To enable this in Twenty Twenty-One, I have done lots of testing and I have been trying to re-work some of the CSS to make the theme compatible with the new link color options.