Make WordPress Core

Keyboard Shortcuts | Hide comment threads

Editor Chat Agenda: 29 September 2021

Facilitator and notetaker: @get_dave.

This is the agenda for the weekly editor chat scheduled for Wednesday, September 29, 2021, 03:00 PM GMT+1.

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 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

Changes to the WordPress Core PHP Test Suite

Why were changes needed ?

Dev Wapuu
Image credits: @marktimemedia

The WordPress test suite uses the industry standard PHPUnit tool to run the PHP unit tests.

Over the years, PHPUnit has seen a number of changes, new assertions being introduced, different annotations and more, but most notably, as of PHPUnit 8.0, a void return type was added to the typical fixture setUp() and tearDown() methods.

This void return type is problematic in the context of WordPress, as return types in general were only introduced in PHP 7.0 and the void return type wasn’t introduced until PHP 7.1.
While WordPress still has a minimum PHP version of PHP 5.6, the void return type can not be introduced in the test suite as it would inhibit the tests from being run on PHP 5.6 and 7.0.

At the same time, having to run the tests on older PHPUnit versions (PHPUnit < 8.0) made it increasingly difficult to get the test suite to run on new PHP versions, like PHP 8.0 and the upcoming PHP 8.1 (expected end of November) as these older PHPUnit versions are no longer supported and are not being made compatible with newer PHP versions anymore.

Over the past few years, a number of different solution directions were explored and rejected, largely due to the large maintenance burden these would add to the small team of WordPress contributors maintaining the test framework.

With the upcoming release of PHP 8.1 as a driver, we’ve taken another look at this problem and the available tooling in the wider PHP field and a solution has now been implemented which should future-proof the test suite for, at least, a number of years.

The solution

The implemented solution is based on the external PHPUnit Polyfills library, which “allows for creating PHPUnit cross-version compatible tests by offering a number of polyfills for functionality which was introduced, split up or renamed in PHPUnit”.

The PHPUnit Polyfills also solves the void conundrum via a tailored TestCase using snake_case methods.

In effect, this means that the WP Core test suite can now run on all PHPUnit versions between PHPUnit 5.7.21 up to the latest release (at the time of writing: PHPUnit 9.5.10), which allows for running the test suite against all supported PHP versions using the most appropriate PHPUnit version for that PHP version.

It also means that, as of mid August, the tests are being run against PHP 8.1 and fixes for PHP 8.1 compatibility are currently being made.

With the PHPUnit Polyfills in place, tests can now be written using the feature set of the highest supported version of PHPUnit.
The Polyfills library will fill in the gaps and ensure the tests can still run on lower versions of PHPUnit without problems.

What has changed ?

  1. The Composer lock file has been removed.
    The version constraints in the composer.json file have been made stricter to ensure the developer experience is not negatively impacted by this with regards to coding standards checks.
  2. The PHPUnit Polyfills library at version ^1.0.1 has been added as a Composer dev dependency.
  3. All WordPress Core tests now use PHPUnit 9.x assertions and expectations.
  4. All WordPress Core tests now use snake_case fixture methods, i.e. set_up() instead of setUp() and tear_down() instead of tearDown().
  5. The minimum supported PHPUnit version has been raised to PHPUnit 5.7.21 (was 5.4.0).
  6. The WordPress Core test bootstrap file will no longer throw an error when the tests are being run with PHPUnit 8.x or 9.x.
  7. The WordPress Core test bootstrap file will throw an error when the PHPUnit Polyfills are not available or do not comply with the minimum version requirements.
  8. All WP Core native assertions now have an extra, optional $message parameter, just like all PHPUnit native assertions.
    Please use this parameter in all tests which contain more than one assertion to make debugging tests easier.
  9. The WP_UnitTestCase_Base::setExpectedException() method is deprecated and should no longer be used.
  10. The WP_UnitTestCase_Base::checkRequirements() method is deprecated and no longer functional, and in reality hasn’t been for a long time for anyone using it in combination with PHPUnit 7.0+.
  11. The copies of the PHPUnit SpeedTrapListener classes have been removed as they were never actively used in Core.
    Anyone who still wants to use the SpeedTrapListener can install it separately.
  12. The copies of the PHPUnit 9.x MockObject classes which were introduced in the WP Core test suite in WP 5.6 have been removed, as they are no longer needed when the tests are run on the appropriate PHPUnit version for the PHP version used.

While the above changes have been made in WordPress 5.9, a minimal selection of these changes has been backported to WordPress 5.2 – 5.8:

  1. The PHPUnit Polyfills at version ^1.0.1 is now a requirement for the test suites in WP 5.2 – 5.8 and this requirement will be enforced via the test bootstrap.
  2. … which makes all the polyfills for PHPUnit 9.x assertions and expectations available when running tests against WP 5.2 – 5.8.
  3. Additionally, snake_case wrapper methods have been added for the camelCase fixture method names, meaning that for WP 5.2 – 5.8, the snake_case fixture method names will work without needing further work-arounds, both for fixture declarations as well as for calling the parent::set_up() and the likes.

    There is one caveat to this: the backported implementation presumes a fixed order for calling the parent (camelCase) methods versus the child (snake_case) methods: for set_up*() methods: parent first, child second; for tear_down*() methods: child first, parent second.
    This is the standard order, but if you have a fixture method which diverges from this or doesn’t call the parent, you may get unexpected results.

These backports allow for backporting future (security) fixes for WordPress itself without having to make the accompanying tests compatible with older PHPUnit versions.

These backports will also make it more straightforward for extenders to continue to test their plugin/theme against multiple WordPress versions.

For full details about all the changes, please have a read through Trac ticket 46149.

Changes under the hood which should not be noticable:

A new PHPUnit_Adapter_TestCase class has been added. This class is nested in-between the WP_UnitTestCase_Base class and the PHPUnit TestCase class and provides the PHPUnit cross-version adapter layer.

All PHPUnit assertion polyfill methods which previously existed in WP Core have been removed as they are no longer necessary now this functionality is provided via the PHPUnit Polyfills library.
All polyfills for assertions/expectations which were previously in WP are still available, they are now just provided via the Polyfills package.

As for the Docker set up: the PHPUnit container is no longer needed and has been removed from the docker-compose config.

What hasn’t changed:

  • The PHPUnit class aliases (for support of PHPUnit 5), which WP provided are still available, though shouldn’t be needed anymore.
  • You can still extend the WP_UnitTestCase class for your tests and will receive access to everything which was available before + more (i.e. a complete set of polyfills).

Future changes

There is a ticket open to rename some of the WordPress native test helper methods to handle the “doing it wrong” and WP native deprecation notices, as the current method names (too) closely resemble a PHPUnit native method name, which can easily lead to confusion and use of the wrong methods in tests.

When that ticket is actioned, this dev-note will be updated with the relevant information.

What does this mean for contributors to WordPress Core ?

In general:

If you use Composer locally, please run composer update --with-all-dependencies (or composer update -W for short) from the root of your WordPress clone now to make sure your install is updated and to get the most appropriate versions of the dependencies for the PHP version you are running on.

Go on, do that now. This dev-note will wait patiently for you to come back.

You will need to run this command semi-regularly in the future (whenever the composer.json file has been updated).

For WP 5.9 and higher, please don’t use composer install anymore.

If, for example for backports, you need to install the dependencies for WP 5.8 or lower, in that case, you still need to run composer install.

🎓 Why ?

The first time you run composer install locally, it creates a composer.lock file and when you run Composer again, it will look at your composer.lock file to install the “locked” versions again.

Previously, with the committed composer.lock file, the lock file was managed and updated centrally. However, that also meant that you often would be running the dev tools at a version which wasn’t the most appropriate one for the PHP version you are working under. This was getting more and more problematic for running the tests, which is why the file was removed.

Now the composer.lock file is no longer committed, you have to update it yourself to make sure you receive the latest version of the dev dependencies appropriate for your PHP version and within the version constraints set in the composer.json file.

For running the Core tests:

If you usually run the Core tests via Docker using the npm run test:php command, you can continue to do so and all should still work as expected.

If you usually run the Core tests via a Composer installed version of PHPUnit, again, you can continue to do so and all should still work as expected as long as you followed the above instructions to run composer update -W first.

If you usually run the Core tests via a PHAR file, you either have to run composer update -W once in a while or you have to set up a clone of the PHPUnit Polyfills repo. For more information about this last option, please see the set up information in the handbook.
If you are running locally on PHP 7.2 or higher, you may want to download a more recent PHPUnit PHAR file (PHPUnit 8 or 9) to benefit from the advances which have been made in PHPUnit.

If you are running the tests locally on PHP 7.2 or higher, you may notice the test runs being faster and the output being enhanced as the tests will now run on a more recent PHPUnit version.

💡 Pro-tip:

Now might also be a good time to verify that your local wp-tests-config.php file is still in sync with the wp-tests-config-sample.php file.

Similarly, if you use a local phpunit.xml overload configuration file, it is strongly recommended to verify that any changes made in the phpunit.xml.dist (and multisite.xml) file are synced into your local configuration.

For writing tests for Core:

You can now use the full range of assertions as available in PHPUnit 9.5 in your tests. Please use the most appropriate assertion available.

Test fixture methods MUST use snake_case method names from now on as per the below table.

Old nameNew name
setUpBeforeClass()set_up_before_class()
setUp()set_up()
assertPreConditions()assert_pre_conditions()
assertPostConditions()assert_post_conditions()
tearDown()tear_down()
tearDownAfterClass()tear_down_after_class()

The Make Core handbook page about writing tests has been updated with this information.
The page has also been enhanced with more handy tips and tricks, so please have a read through!

What does this mean for plugins/themes running integration tests based on the WP Core test suite ?

It is a known fact that there are a lot of plugins/themes which use the WordPress Core test framework as a basis for their integration tests.

If your plugin/theme is one of them, these changes will impact you as well.

Step-by-step: how to make your test setup compatible with these changes and with higher PHPUnit versions:

  1. Run your tests against PHP 7.4 with PHPUnit 7.x and WP 5.8.1 and make sure there are no pre-existing errors/failures.
  2. Add PHPUnit Polyfills as a Composer require-dev dependency (or inherit it from WP).
  3. If you add the Polyfills as a requirement and only support WP 5.9 and higher, remove the requirement for PHPUnit in favour of letting the Polyfills handle it. This will prevent potential future version constraint conflicts.
    • If you still need/want to run your tests against older WP versions, keep the PHPUnit requirement and make sure it is set to ^5.7.21 || ^6.5 || ^7.5 and let CI (continuous integration script) handle removing that requirement for WP 5.9.
    • Or do it in reverse and remove the requirement for dev and add it back in CI for older WP versions.
  4. Make sure the Polyfills autoloader is wired in to your test bootstrap.
    • If you’ve chosen to “inherit the Polyfills from WP”, in this context that means that you use a full clone of WordPress and will install the Composer dependencies for WordPress before running the tests. In that case, you should be all set.
    • If you use only a partial clone of WordPress, like when your tests have been set up using the WP-CLI scaffold command, or if you don’t run WordPress’ Composer setup, please make sure you load the Polyfills autoloader in your test bootstrap before running the WP native test bootstrap.
      • If you include your Composer vendor/autoload.php file as your test bootstrap before you run the WP native test bootstrap, you’re all set already, the Polyfills autoloader will be included automatically.
      • Alternatively, you can add a require_once 'path/to/vendor/yoast/phpunit-polyfills/phpunitpolyfills-autoload.php'; in your test bootstrap before including the WP native test bootstrap.
      • As a last alternative, you can declare a WP_TESTS_PHPUNIT_POLYFILLS_PATH constant containing the absolute path to the root directory of the PHPUnit Polyfills installation in your plugin/theme’s own test bootstrap file.
        Again, this constant must be declared prior to running the WP native test bootstrap file.
  5. Search your codebase for declarations of the fixture methods, as well as calls to (parent) fixture methods, and replace camelCase with snake_case in the method names.
    Example:
    // Old:
    public function setUp() {
         parent::setUp();
         // Do something.
    }
    
    // New:
    public function set_up() {
        parent::set_up();
        // Do something.
    }
  6. Verify your tests run without errors after the changes by running them against PHP 7.4 on PHPUnit 7.x with WP latest (= WP 5.8).
  7. Verify your tests run without errors after the changes by running them against PHP 7.4 on PHPUnit 7.x with WP trunk (= WP 5.9).
  8. While using WP trunk/5.9, switch to PHPUnit 8.x – look out for deprecation notices PHPUnit throws and just literally do what they tell you to do.
  9. While still using WP trunk/5.9, switch to PHPUnit 9.x – look out for deprecation notices PHPUnit throws and just literally do what they tell you to do.

Once you’ve run through these steps, your tests should be cross-version compatible with PHPUnit 5.7.21 – 9.5, able to run against the WordPress 5.2 to 5.9 branches and able to run on PHP 5.6 – 8.1.

Next, you may want to run your tests against PHP 8.0 and 8.1 using PHPUnit 9.x with WP 5.9 to see if your plugin/theme is compatible with these more recent PHP versions.

🚨 Pro-tip:

If you want your CI build to fail when PHPUnit encounters PHP native deprecation notices, make sure to add convertDeprecationsToExceptions="true" to your PHPUnit configuration file as the default value for this setting has been changed to false in PHPUnit 9.5.10/8.5.21.

Enabling this setting is strongly recommended for testing your plugin/theme against PHP 8.1, as PHP 8.1 introduces a lot of new deprecations.

What to do when running tests in CI against multiple WP/PHP combinations ?

If you are running your plugin/theme integration tests against multiple WordPress and PHP combinations, you will most likely need to make some adjustments to your Continuous Integration (CI) script(s).

Which exact changes you need to make depends entirely on your specific setup. There is no “one size fits all” solution.

As a general rule of thumb:

  • WP 5.2 – 5.5 is able to run tests against PHP 5.6 – 7.4 with PHPUnit 5.x (PHP 5.6 and 7.0) – 7.x (PHP 7.1 and higher).
  • WP 5.6 – 5.8 is able to run tests against PHP 5.6 – 8.0 with PHPUnit 5.x (PHP 5.6 and 7.0) – 7.x (PHP 7.1 and higher).
  • WP 5.9 and higher is able to run tests against PHP 5.6 – 8.1 with PHPUnit 5.x – 9.x (use the most appropriate PHPUnit version for each PHP version).

Also see the PHP Compatibility and WordPress Versions and PHPUnit Compatibility and WordPress Versions pages in the Make Core handbook.

Other typical things to take into account and to work around when needed:

  • Is there a config - platform - php setting in your composer.json which fixes the PHP version to a specific version – typically PHP 5.6 – for installing dependencies ?
    If so, you may need to either selectively remove this setting or run Composer with --ignore-platform-reqs for certain WP/PHP combinations in your test matrix.
  • Has the composer.lock file been committed ?
    In that case, you may need to either selectively remove that file in CI before running composer install; or run composer update -W for certain WP/PHP combinations in your test matrix.
  • Do you use a complete clone of WP ?
    For WP 5.2 – 5.8, you’ll need to install the WP dependencies by using composer install.
    For WP 5.9 and higher, you’ll need to install the WP dependencies by using composer update -W.

To make sure you run the test against the right PHPUnit version, you may need to run (a variation on):

1
2
composer remove --dev phpunit/phpunit
composer update --dev yoast/phpunit-polyfills --with-dependencies --ignore-platform-reqs

💡 Did you know ?

If you use GitHub Actions to run your tests for continuous integration and PHPUnit and the PHPUnit Polyfills are your only external test dependencies, as of Setup-PHP 2.15.0 (expected soon), you can use the tools key in the shivammathur/setup-php action to install these:

1
2
3
4
5
- name: Setup PHP with tools
  uses: shivammathur/setup-php@v2
  with:
    php-version: '8.0'
    tools: phpunit-polyfills

For more information about the tools key for setup-php, see the action documentation.

For more information on how to wire in the PHPUnit Polyfills when installed via setup-php, see the FAQ section of the Polyfills documentation.

Anticipating some frequently asked questions

I’m a plugin/theme maintainer, but don’t use Composer, can I still run my integration tests ?

Yes, but you do need to make sure that either the Polyfills are available via a Composer global or local install or via some other manner, like a clone of the repo.

If you haven’t looked at Composer before, now might be a good time to take a look at it.

I’m running my tests via another tool stack (like BrainMonkey, WP Mock, PHP Mock, WP Browser, PestPHP), how do the changes made to the WordPress test suite affect me ?

Short answer: They don’t.

Long answer: if you want to run your tests against multiple PHP and PHPUnit combinations, you may still find the PHPUnit Polyfills library helpful to you.

If you’ve not heard of the above mentioned tools before and want to read up on them, here are some links:

I used the WP-CLI scaffold command to set up my integration tests. How do the changes made to the WordPress test suite affect me ?

There is no automated way right now to adapt existing tests for which the initial was created via the WP-CLI scaffold command, to make use of the new setup.

The current recommendation is to go through the steps in “What does this mean for plugins/themes running integration tests based on the WP Core test suite ?“, which might be more or less involved depending on what version of the scaffolded test setup you are currently using.

A future version of the WP-CLI scaffold plugin-tests command will provide an upgrade mechanism to automatically upgrade an existing test setup to the new requirements. This will include adding a fully Composer-based testing setup as a replacement for the current bootstrap logic, making a composer update possible in the future to keep up with further test setup changes.

If you’re interested in learning more about these plans for the future, please subscribe to the issue on GitHub to stay informed.

I’m using WP Test Utils for my unit and integration tests. How do the changes made to the WordPress test suite affect me ?

WP Test Utils is a library offering utilities for both unit testing and integration testing for WordPress plugins and themes. WP Test Utils already includes the PHPUnit Polyfills.

For the unit testing part, which is based on BrainMonkey, you are not affected by the changes.

If you use the integration testing utilities, you will need to make the change from camelCase to snake_case for the fixture methods in your test suite and you can now potentially widen the PHPUnit version requirements for your integration tests (also see the information about this in step 3 of the “Step by step” guide and the information about adjusting CI scripts).

Presuming you were already using the PHPUnit Polyfills provided by the Test Utils to use modern assertions, that’s it. You’re done.

WP Test Utils will continue to handle the integration test bootstrapping, which allows for running the tests against multiple WordPress and PHP versions.

The first version of WP Test Utils which has full support for the test framework changes made in WP 5.9, is WP Test Utils 1.0.0.

WP Test Utils 1.0.0 also includes improved support for integration tests which were created using the WP-CLI scaffold command and support for running tests against WP versions which don’t include the backports, like WP 5.2 – 5.8 point releases released before today, as well as WP < 5.2.


Props to @hellofromtonya, @johnbillion, @dingo_d, @netweb, @sergeybiryukov, @swissspidy, @schlessera for reviewing ahead of publication.

#5-9, #build-test-tools, #dev-notes, #phpunit, #unit-tests

Thanks for all your work on this, and the excellent write-up!

WordPress 5.8.2+ Release Schedule

Thanks to everyone that helped release 5.8.1 on September 9th! It’s time to look ahead to 5.8.2, and other 5.8.x releases (if necessary).

Like the 5.8.1 release, these releases are following the strategy of having a consistent minor release squad for all 5.8.x releases.

5.8.2

The following schedule is proposed for a 5.8.2 release:

  • RC: Tuesday, October 5, 2021
  • Final release: Tuesday, October 12, 2021

As of the publish date of this post, 19 open tickets are currently in the 5.8.2 milestone for consideration. Please head over and check out that list to help contribute to the release.

5.8.3 (if necessary)

For the 5.8.x release cycle, a 5.8.3 release will be pursued only if necessary. Below is the proposed schedule for 5.8.3:

  • RC: Tuesday November 2, 2021
  • Final release: Wednesday, November 10, 2021

These dates also take into account the 5.9 release cycle, which will be approaching the first beta release at this time.

Release coordination

Because the 5.8.x releases are part of 5.8 by extension, all coordination and conversation related to the 5.8.x releases are held in the #5-8-release-leads Slack channel. This channel will be archived when WordPress 5.9 is released.

Props @desrosj & @audrasjb for peer review.

#5-8, #5-8-1, #5-8-2, #5-8-3, #5-8-x

thank you for looking forward and including 5.8.3 dates (if it is needed). That’s helpful and something I think should be considered for other minor releases in the future.

Do you have this issue on the radar? http://wayback.fauppsala.se:80/wayback/20210927144029/https://core.trac.wordpress.org/ticket/53965
It seems like a pretty breaking issue that should probably be addressed in 5.8.2.

Dev chat summary – September 22, 2021

@audrasjb led the chat on this agenda. You can also read the Slack logs.

Highlighted blog posts

Bringing to your attention some interesting reads and some call for feedback and/or volunteers:

Worth mentioning:

Thanks to the 42 contributors of the past week, including 7 new contributors! Kudos to the 4 core committers of the week, too.

A Week in Core – September 20, 2021

Upcoming releases updates

Next minor release(s)

@desrosj and @circlecube are still leading the 5.8.x releases.

They will publish a schedule for 5.8.2 and –if needed– 5.8.3 on September 23.

Next major release

Concerning the next major release —WordPress 5.9— a planning roundup was published a couple weeks ago.

Worth noting that @chanthaboune proposed a review of the upcoming 5.9 key features in the last issue of the WordPress.org podcast.

@audrasjb proposed to start to schedule bug scrubs for the milestone. He will run the first scrub of 5.9 on Thursday, September 26, 2019 at 08:00 PM UTC.

Reminder: everyone is welcome to run a bug scrub on the #core Slack channel. If you are interested, please read this handbook post: Leading bug scrubs. And yes, that’s a call for volunteers 🙂 Please add a comment below if you want to help.

For 5.9, @hellofromtonya pointed out that it would be nice to try to also plan some APAC-friendly bug scrubs when possible.

Component maintainers updates

Help/About@marybaum

Build/Test Tools@sergeybiryukov

  • Some changes were implemented to make the PHPUnit Polyfills loading more flexible and improve the related messaging. See changesets 51810-51813 and ticket #46149 for more details.
  • The PHPUnit Polyfills package and related test infrastructure changes are now backported to a few older branches (WP 5.8 to 5.2). This makes it easier for developers to continue testing on multiple versions of WordPress while adding tests for newer versions of PHP, which require more modern PHPUnit practices. See changesets 51838-51840, 51843-51846 and ticket #53911 for more details.
  • Work is now complete on Modernizing to the Latest PHPUnit version. Dev note is being reviewed and plan is to publish on Monday.
  • PHP 8.1: work is nearly complete, i.e. identified through tests. Will be shifting shortly into community feedback and open call for contributions to identify and help fix compatibility issues.

General@sergeybiryukov and @hellofromtonya

Internationalization@sergeybiryukov

  • A translator comment was added to clarify the “Block HTML” string in the Block widget settings form. This should reduce confusion for Polyglots translating the string.

Toolbar@sabernhardt

  • @sabernhardt shared a draft of a Toolbar component update post (it’s also available in a Google doc if you want to add comments that way)

Open Floor

From @hellofromtonya: If you want to contribute to the Testing Team, here’s this week’s edition of Week in Test which is a curated list of where testers (of any skillset) are needed this week.

#5-8-x, #5-9, #dev-chat, #summary

Core Editor Improvement: Introducing the Widget Group Block

While the Block Widgets Editor was released with WordPress 5.8, the work to improve the experience hasn’t stopped to help even more folks use blocks to build out widget areas in an endless number of ways. The latest in a series of improvements comes with the launch of Gutenberg 11.5 that introduces a Widget Group block. This new block replicates the familiar experience of being able to add a title to a group of blocks and allows you to group any block, making it easier to move and layout content however you’d like. This both helps with compatibility for older themes when migrating over to the new editor and enables a more cohesive experience for building out widget areas.

For example, before this update, it was tricky to get the spacing right for adding a header above another set of blocks. Now, you can do that with ease:

Video showing how to use the Widget Group Block.

This also makes it a breeze to move collections of blocks into new widget areas: 

Video showing how you can drag and drop a collection of blocks within the Widget Group Block.

As always, you can also make these changes in the Customizer! For more general information about the Block Widgets Editor, check out the Dev note and the user documentation. To get involved in this work, head to #feature-widgets-block-editor and explore the GitHub tracking project to see what’s next. 

Props to @critterverse for the lovely videos! #core-editor, #core-editor-improvement, #feature-widgets-block-editor

Dev Chat Agenda for Sept 22, 2021

Here is the agenda for this week’s developer meeting to occur at Wednesday, September 22, 2021 at 08:00 PM UTC.

Blog Post Highlights and announcements

Bringing to your attention some interesting reads and some call for feedback and/or volunteers:

Next releases status update

  • Next minor release: WP 5.8.2
  • Next major release: WP 5.9

Components check-in and status updates

  • Check-in with each component for status updates.
  • Poll for components that need assistance.

Open Floor

Do you have something to propose for the agenda, or a specific item relevant to the usual agenda items above?

Please leave a comment, and say whether or not you’ll be in the chat, so the group can either give you the floor or bring up your topic for you accordingly.

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

#5-8-2, #5-9, #agenda, #core, #dev-chat

A Week in Core – September 20, 2021

Welcome back to a new issue of Week in Core. Let’s take a look at what changed on Trac between September 13 and September 20, 2021.

  • 21 commits
  • 42 contributors
  • 31 tickets created
  • 0 tickets reopened
  • 23 tickets closed

The Core team is currently working on the next point (5.8.2) and major (5.9) releases 🛠

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

Block editor

  • Cache global stylesheet by theme key – #53175

Build/Test Tools

  • Expect an absolute path in WP_TESTS_PHPUNIT_POLYFILLS_PATH constant – #46149
  • Improve messaging when PHPUnit Polyfills cannot be found – #46149
  • Improve messaging when PHPUnit Polyfills do not comply with version requirements – #46149
  • Make WP_TESTS_PHPUNIT_POLYFILLS_PATH more flexible – #46149
  • Reworks Tests_Option_Option::test_bad_option_names() into data provider – #53635

Bundled Themes

  • Twenty Eleven: Set a fixed height for search form when header image is added – #40398
  • Twenty Seventeen: Make blog header margin more specific on front page – #43628
  • Twenty Twenty-One: Add missing escaping for the “Secondary menu” label – #54127

Coding Standards

  • Code Modernization: Fix “passing null to non-nullable” deprecation notice in WP_Comment_Query::get_comment_ids()#53635
  • Rename the $arrURL variable to $parsed_url in WP_Http::request()#53359
  • Rename the $arrURL variable to $parsed_url in WP_Http_Cookie::__construct()#53359
  • Rename the $arrURL variable to $parsed_url in WP_Http_Streams::request()#53359
  • Rename the $processedHeaders variable to $processed_headers in WP_Http::request()#53359
  • Use strict comparison in wp-inclues/class-wp-http-cookie.php#53359

Documentation

  • Update description for the $wp_version global – #53413

Embeds

  • Add Pinterest as a trusted oEmbed provider – #53448

Internationalization

  • Add a translator comment to clarify the “Block HTML” string in the Block widget settings form – #54110

Media

  • Fix $content parameter default value in img_caption_shortcode()#53635

Options, Meta APIs

  • Fix “passing null to non-nullable” deprecations to (get|add|update|delete)_option()#53635

Upgrade/Install

  • Create a temporary backup of plugins and themes before updating – #51857

Props

Thanks to the 42 people who contributed to WordPress Core on Trac last week: @hellofromTonya (9), @jrf (8), @lucatume (4), @schlessera (4), @jeherve (4), @sabernhardt (3), @mukesh27 (3), @SergeyBiryukov (3), @pbearne (2), @azaozz (2), @dd32 (2), @muhammadfaizanhaidar (2), @NekoJonez (1), @Amieiro (1), @knutsp (1), @johnbillion (1), @namith.jawahar (1), @ayeshrajans (1), @laurelfulford (1), @hirofumi2012 (1), @jainnidhi (1), @mai21 (1), @fedepia (1), @Soean (1), @francina (1), @a2hosting (1), @Boniu91 (1), @richards1052 (1), @galbaras (1), @KZeni (1), @pento (1), @mikeschroder (1), @audrasjb (1), @TimothyBlynJacobs (1), @poena (1), @pbiron (1), @afragen (1), @aristath (1), @joedolson (1), @oandregal (1), @teucrium (1), @lukecavanagh (1).

Congrats and welcome to our 7 new contributors of the week: @NekoJonez, @Amieiro, @namith.jawahar, @mai21, @richards1052, @KZeni, and @teucrium ♥️

Core committers: @sergeybiryukov (11), @hellofromtonya (8), @pento (1), @jorgefilipecosta (1).

#5-8-2, #5-9, #core, #week-in-core

Is there a planned release date for 5.8.2?

Yeah, and we have a “WP 5.8.2 Update” item in today’s devchat agenda, the minor release squad is going to tell us more about the planning 🙂

CSS Chat Summary: 16 September 2021

The meeting took place here on Slack. @dryanpress facilitated and @danfarrow wrote up these notes.

CSS Custom Properties (#49930)

  • @dryanpress shared the working document and the trac ticket, for anybody new to the project
  • All core CSS files have now been claimed, and are either in progress or have a PR, however @dryanpress reminded us that if anyone has claimed a file and can no longer work on it please do let us know
  • The next step is reviewing and merging PRs. Help is very welcome if anybody is up for “trying out a PR and making sure the colors still look correct (or correct enough, where maybe we made changes)
  • @dryanpress raised the topic of skinning admin colour schemes, as there are some custom properties for body.admin-color-ectoplasm already in custom-properties.css. We would probably create a couple of colour schemes at a later stage, for testing & demonstration purposes
  • @dryanpress outlined the final todo list for the project:
    • Merge all remaining files
    • Look for duplication and opportunities for property consolidation
    • Final team review
    • Merge proposal write-ups
  • @ryelle added that, before the final team review step, discussion will be needed about what to consolidate and how, for example rgba and box-shadow values
  • @ryelle added that, as there are several PRs now merged, anybody interested could start generating some ideas for these next steps right now
  • @dryanpress asked if we are still on target for an --experimental release in 5.9 which @ryelle confirmed we have good momentum for
  • @ryelle observed that there are other places outside of CSS files where CSS is used, for example php and js files, which also need to be reviewed. @dryanpress offered to add this and the other tasks (mentioned above) to the planning document
  • @CodeXplorer admitted to wanting to help but feeling lost, to which @dryanpress provided a few notes of the current state of the project
  • @danfarrow had quickly calculated there are now 127 custom properties in custom-properties.css. @robertg added that this isn’t including the 225 (approx) in his PR

Open Floor / CSS Link Share

Thanks everybody!

#core-css, #summary

WordPress JavaScript Standards Change Proposal

This post was authored by @opr18 (Thomas Roberts).

During a recent WordPress #core-js meeting there was a discussion about updating the JavaScript coding standard. The specific update that is being proposed is to change the rules relating to comments.

Currently, the standard reads:

Comments come before the code to which they refer, and should always be preceded by a blank line. Capitalize the first letter of the comment, and include a period at the end when writing full sentences. There must be a single space between the comment token (//) and the comment text.

The proposal is that the new wording should be:

Comments come before the code to which they refer, and should always be preceded by a blank line. Unless writing a linter override, or a `@see` type comment, capitalize the first letter of the comment, and include a period at the end. There must be a single space between the comment token (//) and the comment text.

The problem with the current guideline is that it is not enforceable by automated tools. It is hard for linting tools to easily distinguish between what is and isn’t a full sentence in the context of code comments.

Code reviews can quickly fill up with noisy comments and suggestions to capitalise or add periods to code comments. If this were fixable with a linting rule then these comments wouldn’t be necessary.

There are instances where it may not make sense to write in sentence case, for example: adding linter overrides or writing `see` comments where the comment may just be the name of a method or file, etc. so we would not enforce the rule on these types of comments.

If this guideline were to be amended, there would be several instances of code in the Gutenberg repository alone that do not follow it. It would be necessary to create a PR that fixes all of these issues. Because the change only relates to comments, a single PR can be made addressing all instances of comments that don’t follow the guideline, because the rule relates to comments only, this would have no impact on functionality so minimal testing would be required.

WordPress core currently uses JSHint for linting JavaScript files, and it does not appear that even the existing style guideline is enforced. Even so, if efforts were made to move to ESLint in WordPress core, implementing a fix for any comments that do not follow the standard should be straightforward.

Initially the rule could be enforced as a “warning” while the PR to fix the issues is completed and after it has been merged the rule could graduate to an “error”.

Here is a draft PR demonstrating the punctuation aspect of the proposed change: http://wayback.fauppsala.se:80/wayback/20210927144029/https://github.com/WordPress/gutenberg/pull/34964

As a part of next steps, this post is looking for feedback on:

  • How do you feel about the proposed changes to the wording of the standard?
  • Are there any concerns about the plan for implementing this change?

This proposal is open for feedback until October 5th, 2021 at which point a final decision will be made during #core-js office hours that day.

#coding-style, #codingstandards, #proposal

What about comments for translators? More often than not, they better be brief and not necessarily in full sentences. If a comment explains usage of variables, then just a word is sometime enough.
(I’m still a bit unsure about how well comments for translators get scraped from js files, though.)

I agree that enforcing these rules for translator comments isn’t necessary, or in the spirit of the rule, so I propose that they get skipped too. There’s already a case for skipping `see` or `todo` type comments for similar reasons.

Editor Chat Agenda: 22 September 2021

Facilitator and notetaker: @jorgefilipecosta

This is the agenda for the weekly editor chat scheduled for Wednesday, September 22 2021, 04:00 PM GMT+1.

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

For task coordination: I’ve landed a couple of fixes for floats without container and themes without theme.json. Also helped with reviews and release duties (11.5.1).