Merge changes published in the Gutenberg plugin "release/8.4" branch

.github/workflows/create-block.yml

@@ -0,0 +1,26 @@
+name: Create Block
+
+on:
+ push:
+ paths:
+ - 'packages/**'
+ - '!packages/**/test/**'
+ - '!packages/**/*.md'
+
+jobs:
+ build:
+
+ runs-on: ubuntu-latest
+
+ steps:
+ - uses: actions/checkout@v1
+ - name: Use Node.js 12.x
+ uses: actions/setup-node@v1
+ with:
+ node-version: 12.x
+ - name: npm install, build, format and lint
+ run: |
+ npm ci
+ npm run test:create-block
+ env:
+ CI: true

bin/build-plugin-zip.sh

@@ -26,7 +26,7 @@ warning () {
  echo -e "\n${YELLOW_BOLD}$1${COLOR_RESET}\n"
 }
 
-status "💃 Time to release Gutenberg 🕺"
+status "💃 Time to build the Gutenberg plugin ZIP file 🕺"
 
 if [ -z "$NO_CHECKS" ]; then
  # Make sure there are no changes in the working tree. Release builds should be

bin/packages/build-worker.js

@@ -8,7 +8,6 @@ const babel = require( '@babel/core' );
 const makeDir = require( 'make-dir' );
 const sass = require( 'node-sass' );
 const postcss = require( 'postcss' );
-
 /**
  * Internal dependencies
  */

bin/plugin/commands/packages.js

@@ -145,7 +145,8 @@ async function updatePackageChangelogs(
  // A version bump required. Found new changelog section.
  if (
  versionBump !== 'minor' &&
- lineNormalized.startsWith( '### ' )
+ ( lineNormalized.startsWith( '### ' ) ||
+ lineNormalized.startsWith( '- initial release' ) )
  ) {
  versionBump = minimumVersionBump;
  }

bin/plugin/commands/release.js

@@ -743,9 +743,9 @@ async function releasePlugin( isRC = true ) {
  );
 
  abortMessage =
- 'Aborting! Make sure to ' + isRC
-  ? 'remove'
-  : 'reset' + ' the remote release branch and remove the git tag.';
+ 'Aborting! Make sure to ' +
+ ( isRC ? 'remove' : 'reset' ) +
+ ' the remote release branch and remove the git tag.';
 
  // Creating the GitHub Release
  const release = await runGithubReleaseStep(

bin/test-create-block.sh

@@ -0,0 +1,38 @@
+#!/bin/bash
+
+# This script validates whether `npm init @wordpress/block` works properly
+# with the latest changes applied to the `master` branch. It purposefully
+# avoids installing `@wordpress/scripts` package from npm when scaffolding
+# a test block and uses the local package by executing everything from the
+# root of the project.
+
+# Exit if any command fails.
+set -e
+
+DIRECTORY="$PWD"
+
+status () {
+ echo -e "\n\033[1;34m$1\033[0m\n"
+}
+
+cleanup() {
+ rm -rf "$DIRECTORY/esnext-test"
+}
+
+trap cleanup EXIT
+
+status "Scaffolding block..."
+npx wp-create-block esnext-test --no-wp-scripts
+cd esnext-test
+
+status "Formatting JavaScript files..."
+../node_modules/.bin/wp-scripts format-js
+
+status "Building block..."
+../node_modules/.bin/wp-scripts build
+
+status "Lintig CSS files..."
+../node_modules/.bin/wp-scripts lint-style
+
+status "Linting JavaScript files..."
+../node_modules/.bin/wp-scripts lint-js

docs/architecture/modularity.md

@@ -2,9 +2,9 @@
 
 The WordPress block editor is based around the idea that you can combine independent blocks together to write your post or build your page. Blocks can also use and interact with each other. This makes it very modular and flexible.
 
-But the Block Editor does not embrace modularity for its behavior and output only, the Gutenberg repository is also built from the ground up as several reusable and independent modules or packages, that, combined together lead to the application and interface we all now. These modules are known as [WordPress packages](https://www.npmjs.com/org/wordpress) and are published and updated regularly on the npm package repository.
+But the Block Editor does not embrace modularity for its behavior and output only. The Gutenberg repository is also built from the ground up as several reusable and independent modules or packages, that, combined together, lead to the application and interface we all know. These modules are known as [WordPress packages](https://www.npmjs.com/org/wordpress) and are published and updated regularly on the npm package repository.
 
-These packages are used to power the Block Editor but they  can be used to power any page in the WordPress Admin or outside.
+These packages are used to power the Block Editor, but they can be used to power any page in the WordPress Admin or outside.
 
 ## Why?
 

docs/contributors/getting-started.md

@@ -65,7 +65,7 @@ To build: open a terminal (or if on Windows, a command prompt) and navigate to t
 
 After building the cloned gutenberg directory contains the complete plugin, you can upload the entire repository to your `wp-content/plugins` directory and activate the plugin from the WordPress admin.
 
-Another way to upload after building is to run `npm run package-plugin` to create a plugin zip file — this requires `bash` and `php` to run. The script creates `gutenberg.zip` that you can use to install Gutenberg through the WordPress admin.
+Another way to upload after building is to run `npm run build:plugin-zip` to create a plugin zip file — this requires `bash` and `php` to run. The script creates `gutenberg.zip` that you can use to install Gutenberg through the WordPress admin.
 
 ## Storybook
 

docs/contributors/release.md

@@ -2,29 +2,25 @@
 
 This Repository is used to perform several types of releases. This document serves as a checklist for each one of these. It is helpful if you'd like to understand the different workflows.
 
-To release Gutenberg, you need commit access to the [WordPress.org plugin repository][plugin repository]. 🙂
+To release Gutenberg, you need commit access to the [WordPress.org plugin repository][plugin repository] as well as being part of the [WordPress organization at npm](https://www.npmjs.com/org/wordpress). 🙂
 
 ## Plugin Releases
 
 ### Schedule
 
-We release a new major version approximately every two weeks. The current and next versions are [tracked in GitHub milestones](https://github.com/WordPress/gutenberg/milestones), along with each version's tagging date.
+We release a new major version approximately every two weeks. The current and next versions are [tracked in GitHub milestones](https://github.com/WordPress/gutenberg/milestones), along with each version's tagging date (the day when _the release candidate_ is to be tagged).
 
-On the date of the current milestone, we publish a release candidate and make it available for plugin authors and users to test. If any regressions are found with a release candidate, a new release candidate can be published.
+- **On the date of the current milestone**, we publish a release candidate and make it available for plugin authors and users to test. If any regressions are found with a release candidate, a new one can be published. On this date, all remaining PRs on the milestone are moved automatically to the next release. Release candidates should be versioned incrementally, starting with `-rc.1`, then `-rc.2`, and so on.
 
-The date in the milestone is the date of **tagging the release candidate**. On this date, all remaining PRs on the milestone are moved automatically to the next release.
-
-Release candidates should be versioned incrementally, starting with `-rc.1`, then `-rc.2`, and so on.
-
-Two days after the first release candidate, the stable version is created based on the last release candidate and any necessary regression fixes.
-
-Once the stable version is released, a post [like this](https://make.wordpress.org/core/2019/06/26/whats-new-in-gutenberg-26th-june/) describing the changes and performing a [performance audit](./testing-overview.md#performance-testing) should be published.
+- **Two days after the first release candidate**, the stable version is created based on the last release candidate and any necessary regression fixes. Once the stable version is released, a post [like this](https://make.wordpress.org/core/2019/06/26/whats-new-in-gutenberg-26th-june/) describing the changes and performing a [performance audit](./testing-overview.md#performance-testing) is published.
 
 If critical bugs are discovered on stable versions of the plugin, patch versions can be released at any time.
 
 ### Release Tool
 
-The plugin release process is entirely automated. To release the RC version of the plugin, run the following command and follow the instructions: (Note that at the time of writing, the tool doesn't support releasing multiple consecutive RC releases)
+> Note that at the time of writing, the tool doesn't support releasing consecutive RC releases. However, it is possible to use the tool for patch releases following the first stable release.
+
+The plugin release process is entirely automated. To release the RC version of the plugin, run the following command and follow the instructions:
 
 ```bash
 ./bin/plugin/cli.js rc
@@ -36,7 +32,11 @@ To release a stable version, run:
 ./bin/plugin/cli.js stable
 ```
 
-It is possible to run the "stable" release CLI in a consecutive way to release patch releases following the first stable release.
+During the release process, you'll be asked to provide:
+
+- A changelog: prepare one beforehand by following the instructions below.
+- A [personal access token](https://help.github.com/en/github/authenticating-to-github/creating-a-personal-access-token-for-the-command-line): have one ready beforehand by visiting [this page](https://github.com/settings/tokens/new?scopes=repo,admin:org,write:packages), if you haven't got one yet.
+- User and password for your GitHub account: if 2FA is enabled for your account (it should), you need to provide a personal access token instead of password (you can use the one necessary for the release).
 
 ### Manual Release Process
 
@@ -105,7 +105,7 @@ git push origin release/x.x
 
 1. Run `git fetch --tags`.
 2. Check out the tag for this release, you should run `git checkout vx.x.0-rc.1`.
-3. Run `./bin/build-plugin-zip.sh` from the root of project. This packages a zip file with a release build of `gutenberg.zip`.
+3. Run `npm run build:plugin-zip` from the root of project. This packages a zip file with a release build of `gutenberg.zip`.
 
 ##### Publish the Release on GitHub
 
@@ -166,12 +166,11 @@ Creating a release involves:
 8. Push the tag `git push --tags`.
 9. Merge the version bump pull request.
 
-
 ##### Build the Plugin
 
 1. Run `git fetch --tags`.
 2. Check out the tag for this release, you should run `git checkout vx.x.0`.
-3. Run `./bin/build-plugin-zip.sh` from the root of project. This packages a zip file with a release build of `gutenberg.zip`.
+3. Run `npm run build:plugin-zip` from the root of project. This packages a zip file with a release build of `gutenberg.zip`.
 
 ##### Publish the Release on GitHub
 
@@ -228,38 +227,43 @@ If you don't have access to [make.wordpress.org/core](https://make.wordpress.org
 
 The Gutenberg repository mirrors the [WordPress SVN repository](https://make.wordpress.org/core/handbook/about/release-cycle/) in terms of branching for each SVN branch, a corresponding Gutenberg `wp/*` branch is created:
 
- - The `wp/trunk` branch contains all the packages that are published and used in the `trunk` branch of WordPress.
- - A Gutenberg branch targeting a specific WordPress major release (including its further minor increments) is created (example `wp/5.2`) based on the `wp/trunk` Gutenberg branch when the WordPress `trunk` branch is marked as "feature-freezed". (This usually happens when the first `beta` of the next WordPress major version is released).
+- The `wp/trunk` branch contains all the packages that are published and used in the `trunk` branch of WordPress.
+- A Gutenberg branch targeting a specific WordPress major release (including its further minor increments) is created (example `wp/5.2`) based on the `wp/trunk` Gutenberg branch when the WordPress `trunk` branch is marked as "feature-freezed". (This usually happens when the first `beta` of the next WordPress major version is released).
 
 ### Synchronizing WordPress Trunk
 
-For each Gutenberg plugin release, WordPress trunk should be synchronized with this release. This involves the following steps that are automated with `./bin/plugin/cli npm-stable` command:
+For each Gutenberg plugin release, WordPress trunk should be synchronized. Note that the WordPress `trunk` branch can be closed or in "feature-freeze" mode. Usually, this happens between the first `beta` and the first `RC` of the WordPress release cycle. During this period, the Gutenberg plugin releases should not be synchronized with WordPress Core.
+
+The process has three steps: 1) update the `wp/trunk` branch within the Gutenberg repo 2) publish the new package versions to npm 3) update the WordPress `trunk` branch.
 
-**Note:** The WordPress `trunk` branch can be closed or in "feature-freeze" mode. Usually, this happens between the first `beta` and the first `RC` of the WordPress release cycle. During this period, the Gutenberg plugin releases should not be synchronized with WordPress Core.
+The first step is automated via `./bin/plugin/cli.js npm-stable` command. You only have to run the command, but, for the record, the manual process would look like this:
 
 1. Ensure the WordPress `trunk` branch is open for enhancements.
 2. Get the last published Gutenberg release branch with `git fetch`.
-2. Check out the `wp/trunk` branch.
-3. Remove all files from the current branch: `git rm -r .`.
-4. Check out all the files from the release branch: `git checkout release/x.x -- .`.
-5. Commit all changes to the `wp/trunk` branch with `git commit -m "Merge changes published in the Gutenberg plugin vX.X release"` and push to the repository.
-6. Update the `CHANGELOG.md` files of the packages with the new publish version calculated and commit to the `wp/trunk` branch.
-Assuming the package versions are written using this format `major.minor.patch`, make sure to bump at least the `minor` version number. For example, if the CHANGELOG of the package to be released indicates that the next unreleased version is `5.6.1`, choose `5.7.0` as a version in case of `minor` version.
+3. Check out the `wp/trunk` branch.
+4. Remove all files from the current branch: `git rm -r .`.
+5. Check out all the files from the release branch: `git checkout release/x.x -- .`.
+6. Commit all changes to the `wp/trunk` branch with `git commit -m "Merge changes published in the Gutenberg plugin vX.X release"` and push to the repository.
+7. Update the `CHANGELOG.md` files of the packages with the new publish version calculated and commit to the `wp/trunk` branch. Assuming the package versions are written using this format `major.minor.patch`, make sure to bump at least the `minor` version number. For example, if the CHANGELOG of the package to be released indicates that the next unreleased version is `5.6.1`, choose `5.7.0` as a version in case of `minor` version.
 
-Now, the branch is ready to be used to publish the npm packages.
+Once the command is finished, you can start the second part: publishing the npm packages.
 
-1. Run the [package release process] but when asked for the version numbers to choose for each package pick values based on the updated CHANGELOG files.
-2. Cherry-pick the "Publish" (created by Lerna) and the CHANGELOG update commits into the `master` branch of Gutenberg.
-
-Now, the npm packages should be ready and a patch can be created and committed into WordPress `trunk`.
+1. Update your local `wp/trunk` branch with the latest changes pushed to GitHub.
+2. Log-in to npm via the console: `npm login`. Note that you should have 2FA enabled. 
+3. From the `wp/trunk` branch, run the script `npm run publish:prod`.
+ - When asked for the version numbers to choose for each package pick the values of the updated CHANGELOG files.
+ - You'll be asked for your One-Time Password (OTP) a couple of times. This is the code from the 2FA authenticator app you use. Depending on how many packages are to be released you may be asked for more than one OTP, as they tend to expire before all packages are released.
+ - If the publishing process ends up incomplete (perhaps because it timed-out or an bad OTP was introduce) you can resume it via [`lerna publish from-package`](https://github.com/lerna/lerna/tree/master/commands/publish#bump-from-package).
+4. Cherry-pick the commits created by lerna ("Publish" and the CHANGELOG update) into the `master` branch of Gutenberg.
 
+Finally, now that the npm packages are ready, a patch can be created and committed into WordPress `trunk`.
 
 ### Minor WordPress Releases
 
 The following workflow is needed when bug fixes or security releases need to be backported into WordPress Core. This can happen in a few use-cases:
 
- - During the `beta` and the `RC` period of the WordPress release cycle.
- - For WordPress minor releases and WordPress security releases (example `5.1.1`).
+- During the `beta` and the `RC` period of the WordPress release cycle.
+- For WordPress minor releases and WordPress security releases (example `5.1.1`).
 
 1. Cherry-pick
 2. Check out the last published Gutenberg release branch `git checkout release/x.x`
@@ -278,7 +282,6 @@ Now, the branch is ready to be used to publish the npm packages.
 
 Now, the npm packages should be ready and a patch can be created and committed into the corresponding WordPress SVN branch.
 
-
 ### Standalone Package Releases
 
 The following workflow is needed when packages require bug fixes or security releases to be published to _npm_ outside of a WordPress release cycle.

docs/designers-developers/developers/backward-compatibility/deprecations.md

@@ -2,10 +2,14 @@
 
 For features included in the Gutenberg plugin, the deprecation policy is intended to support backward compatibility for two minor plugin releases, when possible. Features and code included in a stable release of WordPress are not included in this deprecation timeline, and are instead subject to the [versioning policies of the WordPress project](https://make.wordpress.org/core/handbook/about/release-cycle/version-numbering/). The current deprecations are listed below and are grouped by _the version at which they will be removed completely_. If your plugin depends on these behaviors, you must update to the recommended alternative before the noted version.
 
+## 8.6.0
+
+- Block API integration with [Block Context](https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/block-api/block-context.md) was updated. When registering a block use `usesContext` and `providesContext` pair in JavaScript files and `uses_context` and `provides_context` pair in PHP files instead of previous pair `context` and `providesContext`.
+
 ## 8.3.0
 
 - The PHP function `gutenberg_get_post_from_context` has been removed. Use [Block Context](https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/block-api/block-context.md) instead.
-- The old Block Pattern APIs `register_pattern`/`unregister_pattern` have been removed. Use the [new functions](https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/block-api/block-patterns.md#register_block_pattern) instead. 
+- The old Block Pattern APIs `register_pattern`/`unregister_pattern` have been removed. Use the [new functions](https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/block-api/block-patterns.md#register_block_pattern) instead.
 
 ## 5.5.0
 

docs/designers-developers/developers/block-api/block-attributes.md

@@ -185,6 +185,16 @@ attributes: {
 From here, meta attributes can be read and written by a block using the same interface as any attribute:
 
 {% codetabs %}
+{% ESNext %}
+```js
+edit( { attributes, setAttributes } ) {
+ function onChange( event ) {
+ setAttributes( { author: event.target.value } );
+ }
+
+ return <input value={ attributes.author } onChange={ onChange } type="text" />;
+},
+```
 {% ES5 %}
 ```js
 edit: function( props ) {
@@ -198,16 +208,6 @@ edit: function( props ) {
  } );
 },
 ```
-{% ESNext %}
-```js
-edit( { attributes, setAttributes } ) {
- function onChange( event ) {
- setAttributes( { author: event.target.value } );
- }
-
- return <input value={ attributes.author } onChange={ onChange } type="text" />;
-},
-```
 {% end %}
 
 ### Considerations