Update @wordpress JavaScript packages for WordPress 6.0 Beta1 release

[adamziel]

What?

This huge PR is required to ship WordPress 6.0 Beta 1. It is part of the process described in the developer handbook.

Why?

The WordPress repository contains the Gutenberg files, some of them in a pre-built form.

Releasing a new WordPress version means bringing a new version of the Gutenberg code from the relevant Gutenberg release. In this case, it is v13.0.0-rc.3.

It may seem somewhat awkward to ship a Gutenberg Release Candidate instead of the stable version – it is intentional, though. That's how the process is lined up in the release calendar. Beta 1 is scheduled for today, April 12th, and v13.0.0-rc.3 is the latest available Gutenberg release. The stable Gutenberg version v13.0.0 will only be released later this week and included in an upcoming WordPress 6.0 Beta 2 on April 19th.

How?

Step 0: Pre-requisites

There was some grunt work to perform before this PR could be even created:

• Include relevant blocks in the Gutenberg release
• Release Gutenberg v13.0.0-rc.3.
• Backport the PHP changes from the Gutenberg plugin into wordpress-develop

Every next step depends upon these.

Step 1: Update WordPress packages

I've updated all the relevant packages

$ npm install
$ npm run wp-packages-update

Step 2: Update blocks list

I've made adjustments in all the files that include a list of blocks in some form:

• tools/webpack/blocks.js
• wp-content/plugin/lib/blocks.php
• wp-includes/blocks/index.php

Then also unregistered the init hooks in tests/phpunit/includes/functions.php

Step 3: build

I've ran the production and the development build:

# Run WordPress production build in the repo root
$ cd wordpress-develop
$ npm run build

# Run WordPress dev build in src/
$ cd src
$ npm run build:dev

Step 4: Whack-a-mole

I've spent a while iterating on any emerging problems and CI failures with @gziolo. It is partially documented in the discussion below:

• Unit tests failed – the fixtures for server-side rendered blocks do not include the wp-container-\d+ class
• Unit tests failed – same as above, but for the wp-gallery-\d+ class

Step 5: SVN commit

@gziolo listed the svn:ignore steps required to commit these changes to the SVN repo.

#2564 (comment)

Trac ticket: https://core.trac.wordpress.org/ticket/55505 (created to keep track of the process on the WordPress SVN/Trac side of things)

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[ramonjd]

👋

Failing tests such as these –

5) Tests_Blocks_Render::test_do_block_output with data set #22 ('core__gallery__columns.html', 'core__gallery__columns.server.html')
File '/var/www/tests/phpunit/includes/../data/blocks/fixtures/core__gallery__columns.html' does not match expected value
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
 '
-<ul class="wp-block-gallery columns-1 is-cropped">
+<ul class="wp-container-12 wp-block-gallery-11 wp-block-gallery columns-1 is-cropped">
 	<li class="blocks-gallery-item">
 		<figure>
 			<img src="https://cldup.com/uuUqE_dXzy.jpg" alt="title" />

/var/www/tests/phpunit/tests/blocks/render.php:228

– relate to a change in the Columns block, where we added layout support. See comment: WordPress/gutenberg#37360 (comment)

Blocks that opt into layout support are gifted generated classnames 🎁 of wp_unique_id( 'wp-container-' )

One possible approach is to update test_do_block_output in Tests_Blocks_Render to swap the id for something we expect. It's how Gutenberg approaches it when testing generated classnames in elements support.

	public function test_do_block_output( $html_filename, $server_html_filename ) {
		$html_path        = self::$fixtures_dir . '/' . $html_filename;
		$server_html_path = self::$fixtures_dir . '/' . $server_html_filename;

		foreach ( array( $html_path, $server_html_path ) as $filename ) {
			if ( ! file_exists( $filename ) ) {
				throw new Exception( "Missing fixture file: '$filename'" );
			}
		}

		$html = do_blocks( self::strip_r( file_get_contents( $html_path ) ) );
		// If blocks opt into Gutenberg's layout implementation
		// the container will receive an added classname of `wp_unique_id( 'wp-container-' )`
		// so we need to normalize the random id.
		$normalized_html = preg_replace( '/wp-container-\d+/', 'wp-container-1', $html );
		$expected_html   = self::strip_r( file_get_contents( $server_html_path ) );

		$this->assertSame(
			$expected_html,
			$normalized_html,
			"File '$html_path' does not match expected value"
		);
	}

And then in the columns (and any other offending fixtures)

<!-- wp:column -->
<div class="wp-container-1 wp-block-column">
	<!-- wp:paragraph -->
	<p>Column One, Paragraph One</p>
	<!-- /wp:paragraph -->
	<!-- wp:paragraph -->
	<p>Column One, Paragraph Two</p>
	<!-- /wp:paragraph -->
</div>
<!-- /wp:columns -->

[ocean90]

And then in the columns (and any other offending fixtures)

The new wp-container- class is expected because the layout option for the column block was enabled in WordPress/gutenberg#39422.

[adamziel]

Problem

There's one more puzzle piece to address in regard to class names – the wp-block-gallery-11 thing:

-<ul class="wp-block-gallery columns-1 is-cropped">
+<ul class="wp-container-12 wp-block-gallery-11 wp-block-gallery columns-1 is-cropped">

It was introduced specifically for the gallery block in WordPress/gutenberg#38164

Fixtures from the Gutenberg trunk don't seem to acknowledge that class name: https://github.com/WordPress/gutenberg/blob/trunk/test/integration/fixtures/blocks/core__gallery__columns.html

The integration tests implemented in JavaScript pass without a problem, presumably because wp_unique_id is never ran in these code paths.

Solution

• I might go for a similar preg_replace exception as for the wp-container- thing for now.
• Adjusting the fixtures here might require a backport to the gutenberg repo server fixtures are only present in this repo.

[gziolo]

We still need to use svn:ignore in newly added folders with new blocks to align with the following rules in .gitignore:

/src/wp-includes/blocks/**/*.css
/src/wp-includes/blocks/**/*.js
/src/wp-includes/blocks/**/*.js.map

[adamziel]

The CSS styles are not loading properly in the site editor on this branch – notice how the site logo block looks like:

The problem does not occur in trunk:

It broke in the very beginning of this branch - right after updating the WordPress packages: c50d107

[gziolo]

Create ignorelist.txt:

*.js.map
*.js
*.css

Run in every new block folder:

svn propset svn:ignore -F ingorelist.txt .

[adamziel]

The CSS issue is due to editor.css files not being loaded in the site editor. Broken on the left, working on the right:

This PR doesn't change anything related to the site editor other than bumping the package version in the package.json from 3.0.27 to 4.3.1 – that must be the problem, then?

[gziolo]

Committed with https://core.trac.wordpress.org/changeset/53157. Awesome work @adamziel wrangling all those tricky changes. Let's tackle the issues with styles in the site editor with a new PR.

[adamziel]

The CSS issue seems to be a missing backport of WordPress/gutenberg#37193

wordpress-develop trunk relies on __editorAssets which is exactly what the pr above replaced with __unstableResolvedAssets. cc @ellatrix

[gziolo]

The CSS issue seems to be a missing backport of WordPress/gutenberg#37193

Fixed with 1d086c5.

[gziolo]

Commit: https://core.trac.wordpress.org/changeset/53160.