Docs: Fix some typos (WordPress#60260)

Co-authored-by: Soean <soean@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>

docs/contributors/code/back-merging-to-wp-core.md

@@ -31,7 +31,7 @@ There are however certain exceptions to that rule. PRs with the following criter
 
 -   Does not contain changes to PHP code.
 -   Has label `Backport from WordPress Core` - this code is already in WP Core and is being synchronized back to Gutenberg.
--   Has label `Backport to WordPress Core` - this code has already been syncrhonized to WP Core.
+-   Has label `Backport to WordPress Core` - this code has already been synchronized to WP Core.
 
 ## Further Reading
 

docs/getting-started/fundamentals/registration-of-a-block.md

@@ -33,7 +33,7 @@ register_block_type(
 );
 ```
 
-Here is a more complete example, including the `init` hook. 
+Here is a more complete example, including the `init` hook.
 
 ```php
 function minimal_block_ca6eda___register_block() {
@@ -46,7 +46,7 @@ _See the [full block example](https://github.com/WordPress/block-development-exa
 
 ## Registering a block with JavaScript (client-side)
 
-When the block has already been registered on the server, you only need to register the client-side settings in JavaScipt using the [`registerBlockType`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-blocks/#registerblocktype) method from the `@wordpress/blocks` package. You just need to make sure you use the same block name as defined in the block's `block.json` file. Here's an example:
+When the block has already been registered on the server, you only need to register the client-side settings in JavaScript using the [`registerBlockType`](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-blocks/#registerblocktype) method from the `@wordpress/blocks` package. You just need to make sure you use the same block name as defined in the block's `block.json` file. Here's an example:
 
 ```js
 import { registerBlockType } from '@wordpress/blocks';
@@ -71,7 +71,7 @@ The function accepts two parameters:
 The `settings` object passed as the second parameter includes many properties, but these are the two most important ones:
 
 - **`edit`:** The React component that gets used in the Editor for our block.
-- **`save`:** The function that returns the static HTML markup that gets saved to the database. 
+- **`save`:** The function that returns the static HTML markup that gets saved to the database.
 
 The `registerBlockType()` function returns the registered block type (`WPBlock`) on success or `undefined` on failure. Here's an example:
 

docs/getting-started/fundamentals/static-dynamic-rendering.md

@@ -6,11 +6,11 @@ A block's front-end markup can either be dynamically generated server-side upon
 The post <a href="https://developer.wordpress.org/news/2023/02/27/static-vs-dynamic-blocks-whats-the-difference/">Static vs. dynamic blocks: What’s the difference?</a> provides a great introduction to this topic.
 </div>
 
-## Static rendering 
+## Static rendering
 
 Blocks with "static rendering" produce front-end output that is fixed and stored in the database upon saving. These blocks rely solely on their `save` function to define their [HTML markup](https://developer.wordpress.org/block-editor/getting-started/fundamentals/markup-representation-block/), which remains unchanged unless manually edited in the Block Editor.
 
-If a block does not use a dynamic rendering method—meaning it doesn't generate content on the fly via PHP when the page loads—it's considered a "static block." 
+If a block does not use a dynamic rendering method—meaning it doesn't generate content on the fly via PHP when the page loads—it's considered a "static block."
 
 The diagram below illustrates how static block content is saved in the database and then retrieved and rendered as HTML on the front end.
 
@@ -24,7 +24,7 @@ Blocks in WordPress are encapsulated within special comment tags that serve as u
 
 <details><summary><strong>View an example of static rendering in the Preformatted block</strong></summary>
 <br/>
-The following <a href="https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/preformatted/save.js"><code>save</code> function</a> for the <a hreh="https://github.com/WordPress/gutenberg/tree/trunk/packages/block-library/src/preformatted">Preformatted</a> core block looks like this:
+The following <a href="https://github.com/WordPress/gutenberg/blob/trunk/packages/block-library/src/preformatted/save.js"><code>save</code> function</a> for the <a href="https://github.com/WordPress/gutenberg/tree/trunk/packages/block-library/src/preformatted">Preformatted</a> core block looks like this:
 
 ```js
 import { RichText, useBlockProps } from '@wordpress/block-editor';
@@ -160,7 +160,7 @@ On the front end, the `render_callback` is used to dynamically render the markup
 
 ### HTML representation of dynamic blocks in the database (`save`)
 
-For dynamic blocks, the `save` callback function can return just `null`, which tells the editor to save only the block delimiter comment (along with any existing [block attributes](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-attributes/)) to the database. These attributes are then passed into the server-side rendering callback, which will determine how to display the block on the front end of your site. 
+For dynamic blocks, the `save` callback function can return just `null`, which tells the editor to save only the block delimiter comment (along with any existing [block attributes](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-attributes/)) to the database. These attributes are then passed into the server-side rendering callback, which will determine how to display the block on the front end of your site.
 
 When `save` is `null`, the Block Editor will skip the [block markup validation process](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-edit-save/#validation), avoiding issues with frequently changing markup.
 
@@ -176,4 +176,4 @@ If you are using [InnerBlocks](https://developer.wordpress.org/block-editor/how-
 ## Additional resources
 
 - [Static vs. dynamic blocks: What’s the difference?](https://developer.wordpress.org/news/2023/02/27/static-vs-dynamic-blocks-whats-the-difference/) | Developer Blog
-- [Block deprecation – a tutorial](https://developer.wordpress.org/news/2023/03/10/block-deprecation-a-tutorial/) | Developer Blog
+- [Block deprecation – a tutorial](https://developer.wordpress.org/news/2023/03/10/block-deprecation-a-tutorial/) | Developer Blog

docs/how-to-guides/curating-the-editor-experience/disable-editor-functionality.md

@@ -1,14 +1,14 @@
 # Disable Editor functionality
 
-This page is dedicated to the many ways you can disable specific functionality in the Post Editor and Site Editor that are not covered in other areas of the curation documentation. 
+This page is dedicated to the many ways you can disable specific functionality in the Post Editor and Site Editor that are not covered in other areas of the curation documentation.
 
 ## Restrict block options
 
-There might be times when you don’t want access to a block at all to be available for users. To control what’s available in the inserter, you can take two approaches: [an allow list](/docs/reference-guides/filters/block-filters.md#using-an-allow-list) that disables all blocks except those on the list or a [deny list that unregisters specific blocks](/docs/reference-guides/filters/block-filters.md#using-a-deny-list). 
+There might be times when you don’t want access to a block at all to be available for users. To control what’s available in the inserter, you can take two approaches: [an allow list](/docs/reference-guides/filters/block-filters.md#using-an-allow-list) that disables all blocks except those on the list or a [deny list that unregisters specific blocks](/docs/reference-guides/filters/block-filters.md#using-a-deny-list).
 
 ## Disable the Pattern Directory
 
-To fully remove patterns bundled with WordPress core from being accessed in the Inserter, the following can be added to your `functions.php` file: 
+To fully remove patterns bundled with WordPress core from being accessed in the Inserter, the following can be added to your `functions.php` file:
 
 ```php
 function example_theme_support() {
@@ -21,7 +21,7 @@ add_action( 'after_setup_theme', 'example_theme_support' );
 
 Some Core blocks are actually [block variations](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-variations/). A great example is the Row and Stack blocks, which are actually variations of the Group block. If you want to disable these "blocks", you actually need to disable the respective variations.
 
-Block variations are registered using JavaScript and need to be disabled with JavaScript. The code below will disable the Row variation. 
+Block variations are registered using JavaScript and need to be disabled with JavaScript. The code below will disable the Row variation.
 
 ```js
 wp.domReady( () => {
@@ -48,7 +48,7 @@ add_action( 'enqueue_block_editor_assets', 'example_disable_variations_script' )
 
 There are a few Core blocks that include their own [block styles](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-styles/). An example is the Image block, which includes a block style for rounded images called "Rounded". You many not want your users to round images, or you might prefer to use the border-radius control instead of the block style. Either way, it's easy to disable any unwanted block styles.
 
-Unlike block variations, you can register styles in either JavaScript or PHP. If a style was registered in JavaScript, it must be disabled with JavaScript. If registered using PHP, the style can be disabled with either. All Core block styles are registed in JavaScript.
+Unlike block variations, you can register styles in either JavaScript or PHP. If a style was registered in JavaScript, it must be disabled with JavaScript. If registered using PHP, the style can be disabled with either. All Core block styles are registered in JavaScript.
 
 So, you would use the following code to disable the "Rounded" block style for the Image block.
 
@@ -58,7 +58,7 @@ wp.domReady( () => {
 });
 ```
 
-This JavaScript should be enqueued much like the block variation example above. Refer to the [block styles](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-styles/) documentation for how to register and unregister styles using PHP. 
+This JavaScript should be enqueued much like the block variation example above. Refer to the [block styles](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-styles/) documentation for how to register and unregister styles using PHP.
 
 ## Disable access to the Template Editor
 
@@ -71,7 +71,7 @@ function example_theme_support() {
 add_action( 'after_setup_theme', 'example_theme_support' );
 ```
 
-This prevents both the ability to create new block templates or edit them from within the Post Editor. 
+This prevents both the ability to create new block templates or edit them from within the Post Editor.
 
 ## Disable access to the Code Editor
 
@@ -86,4 +86,4 @@ function example_restrict_code_editor_access( $settings, $context ) {
 add_filter( 'block_editor_settings_all', 'example_restrict_code_editor_access', 10, 2 );
 ```
 
-This code prevents all users from accessing the Code Editor. You could also add [capability](https://wordpress.org/documentation/article/roles-and-capabilities/) checks to disable access for specific users.
+This code prevents all users from accessing the Code Editor. You could also add [capability](https://wordpress.org/documentation/article/roles-and-capabilities/) checks to disable access for specific users.