prep build 09/06

.eslintrc.js

@@ -100,6 +100,7 @@ module.exports = {
 							'findIndex',
 							'findKey',
 							'findLast',
+							'first',
 							'flatMap',
 							'flatten',
 							'flattenDeep',
@@ -122,6 +123,7 @@ module.exports = {
 							'isUndefined',
 							'keyBy',
 							'keys',
+							'last',
 							'lowerCase',
 							'mapKeys',
 							'maxBy',
@@ -131,6 +133,7 @@ module.exports = {
 							'nth',
 							'once',
 							'overEvery',
+							'partial',
 							'partialRight',
 							'random',
 							'reject',

docs/how-to-guides/propagating-updates.md

@@ -0,0 +1,62 @@
+# Propagating updates for block types 
+
+This resource seeks to offer direction for those needing to provide updates to content, whether in a template for a theme, pattern, or a block over an entire site. Since each content type allows or disallows certain kind of synchronization, it's important to know what's possible before creating to make maintenance easier in the future. 
+
+## Recommendations on managing updates
+
+### Establish early what content you expect to require updates
+
+At a high level, it’s important to recognize that not every piece of content can be updated across the entire site and that the method of creation greatly impacts what’s possible. As a result, it’s critical to spend time ahead of creation determining what you expect to need updates and to put that content in the appropriate format. This will make a huge difference in terms of future maintenance. 
+
+### Embrace theme design at the block level
+
+Block theme design requires a mindset shift from the previous approach of designing large sections of a theme and controlling them via updates. While a holistic view of a design is still important when creating a custom theme project, blocks require that themers approach design on a more atomic level. This means starting from the block itself, typically through theme.json customizations. **The goal is that each individual "atom" (i.e., block) can be moved around, edited, deleted, and put back together without the entire design falling apart.**
+
+The more that you approach design at the block level, the less need there is to propagate updates to things like patterns and templates across the entire site. If the atomic pieces are in place, their layout should not matter.
+
+## Content types (and how to properly update them)
+
+### Blocks
+
+How to manage block updates depends on the nature of the block itself. If the block depends on external data, then making it dynamic from start with the `render_callback` function is often a better choice as it provides more control. If the block's structure is expected to change over time, then starting with the static block that uses `save()` method defining a default output is the recommended approach. Over time, it's possible to go hybrid and include also the `render_callback` that can use the output from `save` as a fallback while processing an alternate output. Keep in mind that that flexibility and controls comes at the cost of additional processing during rendering. Another option is using static blocks that rely on managing updates with [block deprecations](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-deprecation/). This will require you to manually update exist blocks.  Depending on your needs and comfortability, either approach can work. **To get started on creating blocks and save time, [you can use the Create Block tool](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-create-block/).**
+
+### Patterns
+
+**For content that you want updated later on, do not use patterns and instead rely on reusable blocks or template parts.** Patterns cannot be updated after you insert one into your site. For context, you can think of Patterns as more like sample/example/starter content. While Patterns exposed in the Inserter might evolve over time, those changes won't be automatically applied to any current useage of the pattern. Once insertered, patterns become completely detached from the original pattern unlike Reusable block or Template Part block. 
+
+If needed, one potential workaround for patterns with custom styles is to add a class name to the wrapping block for a pattern. For example, the following adds a themeslug-special class to a Group block:
+
+```
+<!-- wp:group {"className":"themeslug-special"} -->
+<div class="wp-block-group themeslug-special">
+	<!-- Nested pattern blocks -->
+</div>
+<!-- /wp:group -->
+```
+
+It is not fool-proof because users can modify the class via the editor UI.  However, because this setting is under the "Advanced" panel it is likely to stay intact in most instances. This gives theme authors some CSS control for some pattern types, allowing them to update existing uses. However, it does not prevent users from making massive alterations that cannot be updated. 
+
+### Reusable blocks
+
+As the name suggests, these blocks are inherently synced across your site. Keep in mind that there are currently limitations with relying on reusable blocks to handle certain updates since content, HTML structure, and styles will all stay in sync when updates happen. If you require more nuance than that, this is a key element to factor in and a dynamic block might be a better approach.
+
+### Template Parts and Templates
+
+Because block themes allow users to directly edit templates and template parts, how changes are managed need to be adjusted in light of the greater access given to users. For context, when templates or template parts are changed by the user, the updated templates from the theme update don’t show for the user. Only new users of the theme or users who have not yet edited a template are experiencing the updated template. If users haven’t modified the files then the changes you make on the file system will be reflected on the user’s sites – you just need to update the files and they’ll get the changes. However if they have made changes to their templates then the only way you can update their templates is to:
+
+- Revert all their changes
+- Update the templates and template parts in the database
+
+Generally speaking, if a user has made changes to templates then it’s recommended to leave the templates as is, unless agreed upon with the user (ie in an agency setting). 
+
+One thing to be mindful of when updating templates is inserting references to new or different template parts.  For example, the templates/page.html template could insert a parts/header.html part in version 1.0 but change that reference to parts/header-alt.html in version 2.0.  Some developers may see this as a "workaround" in instances where users modified the original header.html.  However, this is likely to break a user's customized design since the page.html template would no longer reference the correct part unless they also modified and saved the page template.
+
+Likewise, it is generally poor practice to delete template parts in theme updates.  In this scenario, users could create custom top-level templates that include a call to the part and expect it to continue existing.
+
+### Resources
+
+- [Comparing Patterns, Template Parts, and Reusable Blocks](https://wordpress.org/support/article/comparing-patterns-template-parts-and-reusable-blocks/)
+- [Block deprecation](https://developer.wordpress.org/block-editor/reference-guides/block-api/block-deprecation/)
+- [Create Block tool](https://developer.wordpress.org/block-editor/reference-guides/packages/packages-create-block/)
+
+

docs/how-to-guides/themes/theme-json.md

@@ -428,7 +428,7 @@ The naming schema for the classes and the custom properties is as follows:
 					"slug": "x-large",
 					"size": 46,
 					"name": "Large"
-				},
+				}
 			]
 		},
 		"spacing": {
@@ -454,7 +454,7 @@ The naming schema for the classes and the custom properties is as follows:
 					"slug": "60",
 					"size": "2rem",
 					"name": "Large"
-				},
+				}
 			]
 		},
 		"blocks": {

docs/manifest.json

@@ -305,6 +305,12 @@
 		"markdown_source": "../docs/how-to-guides/plugin-sidebar-0.md",
 		"parent": "how-to-guides"
 	},
+	{
+		"title": "Propagating updates for block types ",
+		"slug": "propagating-updates",
+		"markdown_source": "../docs/how-to-guides/propagating-updates.md",
+		"parent": "how-to-guides"
+	},
 	{
 		"title": "Themes",
 		"slug": "themes",

docs/reference-guides/core-blocks.md

@@ -32,7 +32,7 @@ Add a user's avatar. ([Source](https://github.com/WordPress/gutenberg/tree/trunk
 
 -	**Name:** core/avatar
 -	**Category:** theme
--	**Supports:** align, color (~~background~~, ~~text~~), spacing (margin), ~~alignWide~~, ~~html~~
+-	**Supports:** align, color (~~background~~, ~~text~~), spacing (margin, padding), ~~alignWide~~, ~~html~~
 -	**Attributes:** isLink, linkTarget, size, userId
 
 ## Reusable block
@@ -77,7 +77,7 @@ Display a list of all categories. ([Source](https://github.com/WordPress/gutenbe
 
 -	**Name:** core/categories
 -	**Category:** widgets
--	**Supports:** align, typography (fontSize, lineHeight), ~~html~~
+-	**Supports:** align, spacing (margin, padding), typography (fontSize, lineHeight), ~~html~~
 -	**Attributes:** displayAsDropdown, showEmpty, showHierarchy, showOnlyTopLevel, showPostCounts
 
 ## Code
@@ -518,7 +518,7 @@ Displays the contents of a post or page. ([Source](https://github.com/WordPress/
 
 -	**Name:** core/post-content
 -	**Category:** theme
--	**Supports:** align (full, wide), ~~html~~
+-	**Supports:** align (full, wide), typography (fontSize, lineHeight), ~~html~~
 -	**Attributes:** 
 
 ## Post Date

docs/toc.json

@@ -133,6 +133,7 @@
 			},
 			{ "docs/how-to-guides/notices/README.md": [] },
 			{ "docs/how-to-guides/plugin-sidebar-0.md": [] },
+			{ "docs/how-to-guides/propagating-updates.md": [] },
 			{
 				"docs/how-to-guides/themes/README.md": [
 					{ "docs/how-to-guides/themes/block-theme-overview.md": [] },

lib/blocks.php

@@ -191,21 +191,22 @@ function gutenberg_register_core_block_assets( $block_name ) {
 	// else (for development or test) default to use the current time.
 	$default_version = defined( 'GUTENBERG_VERSION' ) && ! ( defined( 'SCRIPT_DEBUG' ) && SCRIPT_DEBUG ) ? GUTENBERG_VERSION : time();
 
-	$style_path        = "build/block-library/blocks/$block_name/style.css";
-	$editor_style_path = "build/block-library/blocks/$block_name/style-editor.css";
+	$style_path      = "build/block-library/blocks/$block_name/";
+	$stylesheet_url  = gutenberg_url( $style_path . 'style.css' );
+	$stylesheet_path = gutenberg_dir_path() . $style_path . ( is_rtl() ? 'style-rtl.css' : 'style.css' );
 
-	if ( file_exists( gutenberg_dir_path() . $style_path ) ) {
+	if ( file_exists( $stylesheet_path ) ) {
 		wp_deregister_style( "wp-block-{$block_name}" );
 		wp_register_style(
 			"wp-block-{$block_name}",
-			gutenberg_url( $style_path ),
+			$stylesheet_url,
 			array(),
 			$default_version
 		);
 		wp_style_add_data( "wp-block-{$block_name}", 'rtl', 'replace' );
 
 		// Add a reference to the stylesheet's path to allow calculations for inlining styles in `wp_head`.
-		wp_style_add_data( "wp-block-{$block_name}", 'path', gutenberg_dir_path() . $style_path );
+		wp_style_add_data( "wp-block-{$block_name}", 'path', $stylesheet_path );
 	} else {
 		wp_register_style( "wp-block-{$block_name}", false, array() );
 	}
@@ -235,7 +236,7 @@ function() {
 		// If the file exists, enqueue it.
 		if ( file_exists( gutenberg_dir_path() . $theme_style_path ) ) {
 
-			if ( file_exists( gutenberg_dir_path() . $style_path ) ) {
+			if ( file_exists( $stylesheet_path ) ) {
 				// If there is a main stylesheet for this block, append the theme styles to main styles.
 				wp_add_inline_style(
 					"wp-block-{$block_name}",
@@ -254,6 +255,7 @@ function() {
 		}
 	}
 
+	$editor_style_path = "build/block-library/blocks/$block_name/style-editor.css";
 	if ( file_exists( gutenberg_dir_path() . $editor_style_path ) ) {
 		wp_deregister_style( "wp-block-{$block_name}-editor" );
 		wp_register_style(

lib/compat/wordpress-6.1/script-loader.php

@@ -65,7 +65,7 @@ function gutenberg_enqueue_stored_styles() {
 		}
 		// Chain core store ids to signify what the styles contain.
 		$style_tag_id             .= '-' . $style_key;
-		$compiled_core_stylesheet .= gutenberg_style_engine_get_stylesheet_from_store( $style_key );
+		$compiled_core_stylesheet .= gutenberg_style_engine_get_stylesheet_from_context( $style_key );
 	}
 
 	// Combine Core styles.
@@ -81,7 +81,7 @@ function gutenberg_enqueue_stored_styles() {
 		if ( in_array( $store_name, $core_styles_keys, true ) ) {
 			continue;
 		}
-		$styles = gutenberg_style_engine_get_stylesheet_from_store( $store_name );
+		$styles = gutenberg_style_engine_get_stylesheet_from_context( $store_name );
 		if ( ! empty( $styles ) ) {
 			$key = "wp-style-engine-$store_name";
 			wp_register_style( $key, false, array(), true, true );

package.json

@@ -98,7 +98,7 @@
 		"@octokit/rest": "16.26.0",
 		"@octokit/types": "6.34.0",
 		"@octokit/webhooks-types": "5.6.0",
-		"@playwright/test": "1.22.2",
+		"@playwright/test": "1.25.1",
 		"@pmmmwh/react-refresh-webpack-plugin": "0.5.2",
 		"@storybook/addon-a11y": "6.5.7",
 		"@storybook/addon-actions": "6.5.7",

packages/block-editor/CHANGELOG.md

@@ -2,6 +2,10 @@
 
 ## Unreleased
 
+### Breaking change
+
+-   `FontSizePicker`: Deprecate bottom margin style. Add a `__nextHasNoMarginBottom` prop to start opting into the margin-free styles that will become the default in a future version, currently scheduled to be WordPress 6.4 ([#43870](https://github.com/WordPress/gutenberg/pull/43870)).
+
 ## 9.8.0 (2022-08-24)
 
 ## 9.7.0 (2022-08-10)