diff --git a/docs/contributors/release.md b/docs/contributors/release.md index cee20e5cc0219..d88c260a3904a 100644 --- a/docs/contributors/release.md +++ b/docs/contributors/release.md @@ -188,7 +188,7 @@ 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 targetting 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). + - 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 @@ -196,9 +196,9 @@ For each Gutenberg plugin release, WordPress trunk should be synchronized with t **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. -1. Ensure the WordPress `trunk` branch is open for enhancements. +1. Ensure the WordPress `trunk` branch is open for enhancements. 2. Check out the last published Gutenberg release branch `git checkout release/x.x` -3. Create a Pull Request from this branch targetting `wp/trunk`. +3. Create a Pull Request from this branch targeting `wp/trunk`. 4. Merge the Pull Request using the "Rebase and Merge" button to keep the history of the commits. Now, the branch is ready to be used to publish the npm packages. @@ -208,7 +208,7 @@ Now, the branch is ready to be used to publish the npm packages. 3. Update the `CHANGELOG.md` files of the published packages with the new released versions and commit to the `wp/trunk` branch. 4. 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 commited into WordPress `trunk`. +Now, the npm packages should be ready and a patch can be created and committed into WordPress `trunk`. ### Minor WordPress Releases @@ -220,7 +220,7 @@ The following workflow is needed when bug fixes or security releases need to be 1. Cherry-pick 2. Check out the last published Gutenberg release branch `git checkout release/x.x` -3. Create a Pull Request from this branch targetting the WordPress related major branch (Example `wp/5.2`). +3. Create a Pull Request from this branch targeting the WordPress related major branch (Example `wp/5.2`). 4. Merge the Pull Request using the "Rebase and Merge" button to keep the history of the commits. Now, the branch is ready to be used to publish the npm packages. @@ -228,12 +228,12 @@ Now, the branch is ready to be used to publish the npm packages. 1. Check out the WordPress branch used before (Example `wp/5.2`). 2. Run the [package release process] but when asked for the version numbers to choose for each package, (assuming the package versions are written using this format `major.minor.patch`) make sure to bump only the `patch` version number. For example, if the last published package version for this WordPress branch was `5.6.0`, choose `5.6.1` as a version. -**Note:** For WordPress `5.0` and WordPress `5.1`, a different release process was used. This means that when choosing npm package versions targetting these two releases, you won't be able to use the next `patch` version number as it may have been already used. You should use the "metadata" modifier for these. For example, if the last published package version for this WordPress branch was `5.6.1`, choose `5.6.1+patch.1` as a version. +**Note:** For WordPress `5.0` and WordPress `5.1`, a different release process was used. This means that when choosing npm package versions targeting these two releases, you won't be able to use the next `patch` version number as it may have been already used. You should use the "metadata" modifier for these. For example, if the last published package version for this WordPress branch was `5.6.1`, choose `5.6.1+patch.1` as a version. 3. Update the `CHANGELOG.md` files of the published packages with the new released versions and commit to the corresponding branch (Example `wp/5.2`). 4. Cherry-pick the CHANGELOG update commits into the `master` branch of Gutenberg. -Now, the npm packages should be ready and a patch can be created and commited into the corresponding WordPress SVN branch. +Now, the npm packages should be ready and a patch can be created and committed into the corresponding WordPress SVN branch. --------- diff --git a/docs/designers-developers/developers/tutorials/format-api/1-register-format.md b/docs/designers-developers/developers/tutorials/format-api/1-register-format.md index 667a63206295e..6a18806f6a48a 100644 --- a/docs/designers-developers/developers/tutorials/format-api/1-register-format.md +++ b/docs/designers-developers/developers/tutorials/format-api/1-register-format.md @@ -39,9 +39,9 @@ Then add a new file named `my-custom-format.js` with the following contents: } )( window.wp ); ``` -Make that plugin available in your WordPress setup and activate it. Then, load a new page/post. +Make that plugin available in your WordPress setup and activate it. Then, load a new page/post. -The list of available format types is maintained in the `core/rich-text` store. You can query the store to check that your custom format is now avaliable. To do so, run this code in your browser's console: +The list of available format types is maintained in the `core/rich-text` store. You can query the store to check that your custom format is now available. To do so, run this code in your browser's console: wp.data.select( 'core/rich-text' ).getFormatTypes(); diff --git a/docs/designers-developers/developers/tutorials/format-api/2-toolbar-button.md b/docs/designers-developers/developers/tutorials/format-api/2-toolbar-button.md index c6e72011f1782..53b776b562b41 100644 --- a/docs/designers-developers/developers/tutorials/format-api/2-toolbar-button.md +++ b/docs/designers-developers/developers/tutorials/format-api/2-toolbar-button.md @@ -1,6 +1,6 @@ # Add a Button to the Toolbar -Now that the format is avaible, the next step is to surface it to the UI. You can make use of the [`RichTextToolbarButton`](/packages/editor/src/components/rich-text/README.md#RichTextToolbarButton) component to extend the format toolbar. +Now that the format is available, the next step is to surface it to the UI. You can make use of the [`RichTextToolbarButton`](/packages/editor/src/components/rich-text/README.md#RichTextToolbarButton) component to extend the format toolbar. Paste this code in `my-custom-format.js`: @@ -68,7 +68,7 @@ The following sample code renders the previously shown button only on paragraph return ( props.selectedBlock && props.selectedBlock.name === 'core/paragraph' - ); + ); } ) )( MyCustomButton ); diff --git a/docs/designers-developers/developers/tutorials/javascript/loading-javascript.md b/docs/designers-developers/developers/tutorials/javascript/loading-javascript.md index c3805f26845cc..f48775df5782d 100644 --- a/docs/designers-developers/developers/tutorials/javascript/loading-javascript.md +++ b/docs/designers-developers/developers/tutorials/javascript/loading-javascript.md @@ -30,7 +30,7 @@ If your code is registered and enqueued correctly, you should see a message in y ![Console Log Message Success](https://raw.githubusercontent.com/WordPress/gutenberg/master/docs/designers-developers/assets/js-tutorial-console-log-success.png) -**Note for Theme Developers:** The above method of enqueing is used for plugins. If you are extending the block editor for your theme there is a minor difference, you will use the `get_template_directory_uri()` function instead of `plugins_url()`. So for a theme, the enqueue example is: +**Note for Theme Developers:** The above method of enqueuing is used for plugins. If you are extending the block editor for your theme there is a minor difference, you will use the `get_template_directory_uri()` function instead of `plugins_url()`. So for a theme, the enqueue example is: ```php function myguten_enqueue() { diff --git a/docs/designers-developers/developers/tutorials/javascript/scope-your-code.md b/docs/designers-developers/developers/tutorials/javascript/scope-your-code.md index 5d78b928ae603..802e4872cf8d5 100644 --- a/docs/designers-developers/developers/tutorials/javascript/scope-your-code.md +++ b/docs/designers-developers/developers/tutorials/javascript/scope-your-code.md @@ -28,7 +28,7 @@ This behavior can be problematic, and is the reason we need to scope the code. B ## Scoping Code Within a Function -In JavaScript, you can scope your code by writing it within a function. Functions have "local scope", or a scope that is specific only to that function. Aditionally, in JavaScript you can write anonymous functions, functions without a name, which will also prevent your function name from being overridden in the global scope. +In JavaScript, you can scope your code by writing it within a function. Functions have "local scope", or a scope that is specific only to that function. Additionally, in JavaScript you can write anonymous functions, functions without a name, which will also prevent your function name from being overridden in the global scope. Taking advantage of these two JavaScript features, `first.js` could be scoped as: