A month with the WordPress Core team – November 2022

After a lot of deliberation, we decided to change the format of these blog posts. We felt that a weekly or bi-weekly update did not allow us to focus on some bigger concepts and ideas. From now on, these blog posts will be a monthly overview of what our team worked on. It can still contain mentions and links to individual issues and an overview of what we did, but at the same time, it will provide some more “breathing room” to expand a bit more on abstract ideas and the grander plan.

Our monthly updates

Ari

November was a busy month!

Performance and sustainability

After the WordPress 6.1 release, I was really happy to see a lot of people focusing on performance. There is an increasing number of data-driven contributions in that area; WordPress developers have started using profiling tools more. The result of that, is that we are finally addressing long-standing issues. Some of these changes have already made their way in minor releases of WP, but there are a lot more on the way. WordPress 6.2 will be faster than previous releases, improving the performance and sustainability of the whole project!

Besides working on performance improvements myself, I started shifting my focus to helping others improve performance. That involved a lot more code reviews focused on performance tickets, and a plethora of discussions with people who want to contribute to that focus-area.

Forms in Gutenberg

One of the things I’m most excited about, is the proposal to add forms & inputs fields in WordPress.

The vast majority of WordPress sites contains a form of some sort. It can be a contact form, a comment form, a product-review form, or any other kind of form.

However, WordPress never had a native way to handle building and presenting these forms. In #44214 we introduce new form and input blocks. Users will be able to build the forms they need, and/remove the fields that they want, and so on.

Previously, in WordPress, comment forms were hardcoded. If anyone wanted to make any change to the default forms (or add a new form), they needed a good understanding of the WP code structure and good coding skills – or install a forms plugin.

If we merge this implementation, WordPress will be able to start using these blocks for post comments etc, deprecating all the legacy, hard-coded implementations we had. At the same time, it will allow all forms plugins to start using these core blocks as a framework they can expend on, and enrich it – as opposed to reinventing the wheel every time.

You can see a short screencast of building and styling a form below (screencast linked from the Gutenberg proposal):

Supporting SQLite in WordPress Core

A few months ago, we published a proposal to make WordPress officially support SQLite. That proposal has gained a lot of traction, and we started implementing it as a module in the Performance Lab plugin. There have been a lot of reviews, comments and feedback on that proposal. After addressing all the comments, we are now very close to merging it in the plugin.

If all goes well, we’ll be able to merge it later this week and it will be included in the next release of the plugin in a few days. 🥳

This is a huge win, both for performance and sustainability, as it will allow smaller WordPress sites to run on servers that don’t have a MySQL server. At the same time, it presents a unique opportunity for hosting companies to provide new, niche services for these sites – and simplify server maintenance.

Of course it’s a long road before this makes its way back to WordPress Core, but this first step will allow site-developers, plugin-developers, and hosts, to test the implementation; It is the first step towards a bigger change to ensure WordPress’s longevity for the future.

Autoloading WordPress classes

As PHP evolves, so must WordPress. We should not, under any circumstances become a legacy project.

Part of this “evolution”, is the implementation of an autoloader for PHP classes in WP-Core. There were attempts to do this in the past as well, however at the time it was met with a lot of resistance. I’m hoping that this time we will be able to move forward with this… At some point it has to be done, it’s just a matter of getting the timing right.

The idea has a lot of support from WP & PHP developers, so I’m currently working on an implementation for it. Hopefully this time we’ll get it right.🤞

Other notable updates

After many months, we finally managed to merge a change in Gutenberg which I feel is important to theme developers:

When a submenu of a navigation was active (ie the user was on a page that was not a primary/top-level item), we had no way to visually highlight the menus. This was fixed by adding a current-menu-ancestor class to navigation items (#40778).

We also started refocusing on the Webfonts API for WordPress. In the 6.1 release, a preliminary version was merged. For 6.2 we started focusing on a refactor of the implementation, one that will make more sense long-term and can be considered a permanent solution. More details on that can be found on #43492.

---

Andrea

In the last weeks, apart from working on accessibility issues and pull requests for the Gutenberg project, I’ve been focusing on something completely new to me. A good learning opportunity: visual comparison testing with Playwright. Building upon prior art by @kevin940726, @mirka, @WunderBart, @JustinyAhin, and @tellthemachines, I’ve been researching the best way to introduce visual comparison tests in #46210.

Why visual comparison tests matter.

Visual comparison tests can be used to check for visual regressions in the layout, styling, etc. More interestingly, they can be used to test visual features that related to user interaction. It matters the most when it comes to accessibility features. For example, in #46210 I’m aiming to test the focus style of the navigateRegions component. The focus style could be only tested by checking the actual CSS applied on the related elements, but that wouldn’t guarantee the focus style is actually visible to the users. Actually, this focus style was partially hidden or not visible at all, and only visual comparison tests can guarantee the focus style works as expected and is actually perceived by users. I can think of tons of other cases where visual comparisons tests can help accessibility features.

The actual challenge to build a solid visual comparison testing tool is about cross-operating systems differences. On the Gutenberg repository, tests run on CI and of course they run on Ubuntu. However, most WordPress developers work on macOS. Other developers may work on Windows.

When running the visual comparison tests locally, the reference images used to perform the comparison are generated taking a screenshot of what the browser (chromium by default) renders on the user operating system. When running on CI, the images are generated taking a screenshot of what the browser renders on Ubuntu. WordPress and Gutenberg use ‘system fonts’, that is: a font-family stack meant to use the ‘default’ fonts for each operating system. In short, the actual font used is different depending on the operating system in use. This introduces subtle differences in the reference images taken on the user operating system and on CI-Ubuntu. The reference images generated locally will likely differ from the ones generated while running the tests on CI, making the tests fail.

Call for help

We’re exploring a few options to work around this problem. Anyone with some good knowledge of GitHub actions workflows, Playwright and, optionally, Docker, is very welcome to join the conversation on #46210.

---

Sergey

Preparations for bumping the recommended PHP version to 8.0+

WordPress core currently lists PHP 7.4 or greater as the recommended version. As of 28 Nov 2022, PHP 7.4 is no longer supported by the PHP community. Bumping the recommended version to 8.0+ was briefly discussed a few months ago in #meta6432 as something to be re-evaluated after the WordPress 6.1 release.

Some of the biggest concerns with recommending PHP 8.0+ at this time are:

• Incomplete test coverage for WordPress core.
• Unknown state of plugin and theme compatibility.

While the former is a work in progress, I have created a Meta ticket to help with the latter and discuss the prerequisites for updating the recommended version to PHP 8.0+. See #meta6612, any thoughts and ideas welcome!

WordPress 6.1.1

On November 15, I participated in the release party for WordPress 6.1.1. This is a maintenance release that features 29 bug fixes in Core and 21 bug fixes for the block editor.

On the day of the release, some of the Meta tasks I helped with included:

• Updating the Credits API
• Running tests, enabling auto-updates, etc.

If you’d like to learn more about the release process, these steps are documented in the WordPress Core handbook: Releasing Minor Versions.

WordPress 6.2

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 sixty commits to WordPress core, mostly various bug fixes and enhancements. I also led a meeting 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 coding standards fixes in core. See ticket #56791 for more details.
• Continuing with various unit test improvements in core. See ticket #56793 for more details.
• Renaming function parameters that use reserved PHP keywords. See ticket #56788 for more details.
• Checking that both normalizer_*() functions exist in remove_accents(). This avoids a fatal error if a plugin includes polyfill for any of the functions but the Normalizer class has a different namespace, for example when using the Symfony polyfill. See ticket #56980 for more details.
• Showing correct theme per template or template part in Site Editor. See ticket #55437 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.