Merge branch 'trunk' into rnmobile/integration-test-button-radius

.eslintrc.js

@@ -49,7 +49,7 @@ module.exports = {
 		jsdoc: {
 			mode: 'typescript',
 		},
-		'import/resolver': require.resolve( './test/lint/import-resolver' ),
+		'import/resolver': require.resolve( './tools/eslint/import-resolver' ),
 	},
 	rules: {
 		'jest/expect-expect': 'off',

docs/contributors/folder-structure.md

@@ -124,4 +124,10 @@ The following snippet explains how the Gutenberg repository is structured omitti
     │   Configuration for the Gutenberg Mobile unit tests.
     │
     └── test/unit
-        Configuration for the Packages unit tests.
+    │   Configuration for the Packages unit tests.
+    │
+    └── tools/eslint
+    │   Configuration files for the ESLint linter.
+    │
+    └── tools/webpack
+    │   Configuration files for the webpack build.

docs/getting-started/faq.md

@@ -95,7 +95,7 @@ This is the canonical list of keyboard shortcuts:
 			<td><kbd>⇧</kbd><kbd>⌘</kbd><kbd>,</kbd></td>
 		</tr>
 		<tr>
-			<td>Open the block navigation menu.</td>
+			<td>Open the list view menu.</td>
 			<td><kbd>Shift</kbd>+<kbd>Alt</kbd>+<kbd>O</kbd></td>
 			<td><kbd>⌃</kbd><kbd>⌥</kbd><kbd>O</kbd></td>
 		</tr>

docs/getting-started/tutorials/create-block/block-code.md

@@ -12,7 +12,7 @@ In the `gutenpride.php` file, the enqueue process is already setup from the gene
 
 ```php
 function create_block_gutenpride_block_init() {
-	register_block_type_from_metadata( __DIR__ );
+	register_block_type( __DIR__ );
 }
 add_action( 'init', 'create_block_gutenpride_block_init' );
 ```

docs/getting-started/tutorials/create-block/wp-plugin.md

@@ -92,12 +92,12 @@ To load the built script, so it is run within the editor, you need to tell WordP
 
 ```php
 function create_block_gutenpride_block_init() {
-	register_block_type_from_metadata( __DIR__ );
+	register_block_type( __DIR__ );
 }
 add_action( 'init', 'create_block_gutenpride_block_init' );
 ```
 
-The `register_block_type_from_metadata` function registers the block we are going to create and specifies the `editor_script` file handle registered from the metadata provided in `block.json` file. So now when the editor loads it will load this script.
+The `register_block_type` function registers the block we are going to create and specifies the editor script handle registered from the metadata provided in `block.json` file with the `editorScript` field. So now when the editor loads it will load this script.
 
 ```json
 {
@@ -137,6 +137,6 @@ For more info, see the build section of the [Getting Started with JavaScript tut
 
 ## Summary
 
-Hopefully, at this point, you have your plugin created and activated. We have the package.json with the `@wordpress/scripts` dependency, that defines the build and start scripts. The basic block is in place and can be added to the editor.
+Hopefully, at this point, you have your plugin created and activated. We have the `package.json` with the `@wordpress/scripts` dependency, that defines the build and start scripts. The basic block is in place and can be added to the editor.
 
 Next Section: [Anatomy of a Block](/docs/getting-started/tutorials/create-block/block-anatomy.md)

docs/reference-guides/block-api/block-metadata.md

@@ -1,11 +1,6 @@
 # Metadata
 
-To register a new block type using metadata that can be shared between codebase that uses JavaScript and PHP, start by creating a `block.json` file. This file:
-
--   Gives a name to the block type.
--   Defines some important metadata about the registered block type (title, category, icon, description, keywords).
--   Defines the attributes of the block type.
--   Registers all the scripts and styles for your block type.
+Starting in WordPress 5.8 release, we encourage using the `block.json` metadata file as the canonical way to register block types. Here is an example `block.json` file that would define the metadata for a plugin create a notice block.
 
 **Example:**
 
@@ -50,9 +45,19 @@ To register a new block type using metadata that can be shared between codebase
 }
 ```
 
-The same file is also used when [submitting block to Block Directory](/docs/getting-started/tutorials/create-block/submitting-to-block-directory.md).
+## Benefits using the metadata file
+
+The block definition allows code sharing between JavaScript, PHP, and other languages when processing block types stored as JSON, and registering blocks with the `block.json` metadata file provides multiple benefits on top of it.
+
+From a performance perspective, when themes support lazy loading assets, blocks registered with `block.json` will have their asset enqueuing optimized out of the box. The frontend CSS and JavaScript assets listed in the `style` or `script` properties will only be enqueued when the block is present on the page, resulting in reduced page sizes.
+
+Furthermore, because the [Block Type REST API Endpoint](https://developer.wordpress.org/rest-api/reference/block-types/) can only list blocks registered on the server, registering blocks server-side is recommended; using the `block.json` file simplifies this registration.
+
+Last, but not least, the [WordPress Plugins Directory](https://wordpress.org/plugins/) can detect `block.json` files, highlight blocks included in plugins, and extract their metadata. If you wish to [submit your block(s) to the Block Directory](/docs/getting-started/tutorials/create-block/submitting-to-block-directory.md), all blocks contained in your plugin must have a `block.json` file for the Block Directory to recognize them.
 
-## Server-side registration
+## Block registration
+
+### PHP (server-side)
 
 The [`register_block_type`](https://developer.wordpress.org/reference/functions/register_block_type/) function that aims to simplify the block type registration on the server, can read metadata stored in the `block.json` file.
 
@@ -75,6 +80,41 @@ register_block_type(
 );
 ```
 
+### JavaScript (client-side)
+
+When the block is registered on the server, you only need to register the client-side settings on the client using the same block’s name.
+
+**Example:**
+
+```js
+registerBlockType( 'my-plugin/notice', {
+	edit: Edit,
+	// ...other client-side settings
+} );
+```
+
+Although registering the block also on the server with PHP is still recommended for the reasons above, if you want to register it only client-side you can now use `registerBlockType` method from `@wordpress/blocks` package to register a block type using the metadata loaded from `block.json` file.
+
+The function takes two params:
+
+-   `$blockNameOrMetadata` (`string`|`Object`) – block type name (supported previously) or the metadata object loaded from the `block.json` file with a bundler (e.g., webpack) or a custom Babel plugin.
+-   `$settings` (`Object`) – client-side block settings.
+
+It returns the registered block type (`WPBlock`) on success or `undefined` on failure.
+
+**Example:**
+
+```js
+import { registerBlockType } from '@wordpress/blocks';
+import Edit from './edit';
+import metadata from './block.json';
+
+registerBlockType( metadata, {
+	edit: Edit,
+	// ...other client-side settings
+} );
+```
+
 ## Block API
 
 This section describes all the properties that can be added to the `block.json` file to define the behavior and metadata of block types.

docs/reference-guides/block-api/block-registration.md

@@ -2,7 +2,7 @@
 
 Block registration API reference.
 
-**Note:** You can use the functions documented on this page, but a flexible method to register new block types is to use the block.json metadata file. See [metadata documentation for complete information](/docs/reference-guides/block-api/block-metadata.md).
+**Note:** You can use the functions documented on this page to register a block on the client-side only, but a flexible method to register new block types is to use the `block.json` metadata file. See [metadata documentation for complete information](/docs/reference-guides/block-api/block-metadata.md).
 
 ## `registerBlockType`
 

docs/reference-guides/filters/block-filters.md

@@ -2,13 +2,56 @@
 
 To modify the behavior of existing blocks, WordPress exposes several APIs:
 
-## Filters
+## Registration
 
-The following filters are available to extend the settings for existing blocks.
+The following filters are available to extend the settings for blocks during their registration.
+
+### `block_type_metadata`
+
+Filters the raw metadata loaded from the `block.json` file when registering a block type on the server with PHP. It allows applying modifications before the metadata gets processed.
+
+The filter takes one param:
+
+-   `$metadata` (`array`) – metadata loaded from `block.json` for registering a block type.
+
+_Example_:
+
+```php
+<?php
+
+function filter_metadata_registration( $metadata ) {
+	$metadata['apiVersion'] = 1;
+	return $metadata;
+};
+add_filter( 'block_type_metadata', 'filter_metadata_registration', 10, 2 );
+
+register_block_type( __DIR__ );
+```
+
+### `block_type_metadata_settings`
+
+Filters the settings determined from the processed block type metadata. It makes it possible to apply custom modifications using the block metadata that isn’t handled by default.
+
+The filter takes two params:
+
+-   `$settings` (`array`) – Array of determined settings for registering a block type.
+-   `$metadata` (`array`) – Metadata loaded from the `block.json` file.
+
+_Example:_
+
+```php
+function filter_metadata_registration( $settings, $metadata ) {
+	$settings['api_version'] = $metadata['apiVersion'] + 1;
+	return $settings;
+};
+add_filter( 'block_type_metadata_settings', 'filter_metadata_registration', 10, 2 );
+
+register_block_type( __DIR__ );
+```
 
 ### `blocks.registerBlockType`
 
-Used to filter the block settings. It receives the block settings and the name of the registered block as arguments. Since v6.1.0 this filter is also applied to each of a block's deprecated settings.
+Used to filter the block settings when registering the block on the client with JavaScript. It receives the block settings and the name of the registered block as arguments. This filter is also applied to each of a block's deprecated settings.
 
 _Example:_
 
@@ -34,6 +77,10 @@ wp.hooks.addFilter(
 );
 ```
 
+## Block Editor
+
+The following filters are available to change the behavior of blocks while editing in the block editor.
+
 ### `blocks.getSaveElement`
 
 A filter that applies to the result of a block's `save` function. This filter is used to replace or extend the element, for example using `wp.element.cloneElement` to modify the element's props or replace its children, or returning an entirely new element.
@@ -221,30 +268,6 @@ wp.hooks.addFilter(
 
 {% end %}
 
-#### `media.crossOrigin`
-
-Used to set or modify the `crossOrigin` attribute for foreign-origin media elements (i.e `<img>`, `<audio>` , `<img>` , `<link>` , `<script>`, `<video>`). See this [article](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/crossorigin) for more information the `crossOrigin` attribute, its values and how it applies to each element.
-
-One example of it in action is in the Image block's transform feature to allow cross-origin images to be used in a `<canvas>`.
-
-_Example:_
-
-```js
-addFilter(
-	'media.crossOrigin',
-	'my-plugin/with-cors-media',
-	// The callback accepts a second `mediaSrc` argument which references
-	// the url to actual foreign media, useful if you want to decide
-	// the value of crossOrigin based upon it.
-	( crossOrigin, mediaSrc ) => {
-		if ( mediaSrc.startsWith( 'https://example.com' ) ) {
-			return 'use-credentials';
-		}
-		return crossOrigin;
-	}
-);
-```
-
 ## Removing Blocks
 
 ### Using a deny list

docs/reference-guides/filters/editor-filters.md

@@ -38,6 +38,30 @@ wp.hooks.addFilter(
 );
 ```
 
+### `media.crossOrigin`
+
+Used to set or modify the `crossOrigin` attribute for foreign-origin media elements (i.e `<img>`, `<audio>` , `<img>` , `<link>` , `<script>`, `<video>`). See this [article](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/crossorigin) for more information the `crossOrigin` attribute, its values and how it applies to each element.
+
+One example of it in action is in the Image block's transform feature to allow cross-origin images to be used in a `<canvas>`.
+
+_Example:_
+
+```js
+addFilter(
+	'media.crossOrigin',
+	'my-plugin/with-cors-media',
+	// The callback accepts a second `mediaSrc` argument which references
+	// the url to actual foreign media, useful if you want to decide
+	// the value of crossOrigin based upon it.
+	( crossOrigin, mediaSrc ) => {
+		if ( mediaSrc.startsWith( 'https://example.com' ) ) {
+			return 'use-credentials';
+		}
+		return crossOrigin;
+	}
+);
+```
+
 ## Editor settings
 
 ### `block_editor_settings`

lib/class-wp-theme-json-gutenberg.php

@@ -1086,8 +1086,8 @@ public function merge( $incoming ) {
 		foreach ( $nodes as $metadata ) {
 			foreach ( $to_replace as $property_path ) {
 				$path = array_merge( $metadata['path'], $property_path );
-				$node = _wp_array_get( $incoming_data, $path, array() );
-				if ( ! empty( $node ) ) {
+				$node = _wp_array_get( $incoming_data, $path, null );
+				if ( isset( $node ) ) {
 					gutenberg_experimental_set( $this->theme_json, $path, $node );
 				}
 			}

lib/client-assets.php

@@ -102,6 +102,20 @@ function gutenberg_override_script( $scripts, $handle, $src, $deps = array(), $v
 		$output = sprintf( "wp.i18n.setLocaleData( { 'text direction\u0004ltr': [ '%s' ] }, 'default' );", $ltr );
 		$scripts->add_inline_script( 'wp-i18n', $output, 'after' );
 	}
+
+	/*
+	 * Wp-editor module is exposed as window.wp.editor.
+	 * Problem: there is quite some code expecting window.wp.oldEditor object available under window.wp.editor.
+	 * Solution: fuse the two objects together to maintain backward compatibility.
+	 * For more context, see https://github.com/WordPress/gutenberg/issues/33203
+	 */
+	if ( 'wp-editor' === $handle ) {
+		$scripts->add_inline_script(
+			'wp-editor',
+			'Object.assign( window.wp.editor, window.wp.oldEditor );',
+			'after'
+		);
+	}
 }
 
 /**

packages/admin-manifest/src/index.js

@@ -1,7 +1,9 @@
 function addManifest( manifest ) {
 	const link = document.createElement( 'link' );
 	link.rel = 'manifest';
-	link.href = 'data:application/manifest+json,' + JSON.stringify( manifest );
+	link.href = `data:application/manifest+json,${ encodeURIComponent(
+		JSON.stringify( manifest )
+	) }`;
 	document.head.appendChild( link );
 }
 
@@ -94,8 +96,7 @@ window.addEventListener( 'load', () => {
 
 	const { logo, siteTitle, adminUrl } = window.wpAdminManifestL10n;
 	const manifest = {
-		// Replace spaces with non breaking spaces. Chrome collapses them.
-		name: siteTitle.replace( / /g, ' ' ),
+		name: siteTitle,
 		display: 'standalone',
 		orientation: 'portrait',
 		start_url: adminUrl,

packages/base-styles/_z-index.scss

@@ -141,7 +141,6 @@ $z-layers: (
 	// ...Except for popovers immediately beneath wp-admin menu on large breakpoints
 	".components-popover.block-editor-inserter__popover": 99999,
 	".components-popover.table-of-contents__popover": 99998,
-	".components-popover.block-editor-block-navigation__popover": 99998,
 	".components-popover.customize-widgets-more-menu__content": 99998,
 	".components-popover.edit-post-more-menu__content": 99998,
 	".components-popover.edit-site-more-menu__content": 99998,

packages/block-editor/package.json

@@ -55,6 +55,7 @@
 		"@wordpress/shortcode": "file:../shortcode",
 		"@wordpress/token-list": "file:../token-list",
 		"@wordpress/url": "file:../url",
+		"@wordpress/warning": "file:../warning",
 		"@wordpress/wordcount": "file:../wordcount",
 		"classnames": "^2.2.5",
 		"css-mediaquery": "^0.1.2",