prep build 07/23

.github/workflows/sync-backport-changelog.yml

@@ -4,21 +4,33 @@ on:
     push:
         branches:
             - trunk
+    issues:
+        types: [labeled]
 
 jobs:
     sync-backport-changelog:
         name: Sync Core Backport Issue
         runs-on: ubuntu-latest
+        if: >
+            github.event_name == 'push' ||
+            (
+                github.event_name == 'issues' &&
+                github.event.action == 'labeled' &&
+                github.event.label.name == '🤖 Sync Backport Changelog'
+            )
         steps:
-            - uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
+            - name: Checkout
+              uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7
               with:
                   fetch-depth: 2 # Fetch the last two commits to compare changes
             - name: Check for changes in backport-changelog
-              id: check-for-changes
+              if: github.event_name == 'push'
               run: |
-                  git diff --quiet HEAD^ HEAD -- backport-changelog || echo "HAS_CHANGES=1" >> "$GITHUB_OUTPUT"
+                  if git diff --quiet HEAD^ HEAD -- backport-changelog; then
+                      echo "skip_sync=true" >> "$GITHUB_ENV"
+                  fi
             - name: Sync Issue
-              if: steps.check-for-changes.outputs.HAS_CHANGES
+              if: ${{ ! env.skip_sync }}
               uses: actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea # v7.0.1
               with:
                   script: |

backport-changelog/readme.md

@@ -1,16 +1,63 @@
 # Core Backport Changelog
 
-Any PR that makes changes to be backported to [core](https://github.com/WordPress/wordpress-develop) should log a core PR here. It's possible to have multiple Gutenberg PRs link to a single core backport PR. The core backport PR can remain open as long as wanted/needed. The entries are sorted by core release (in folders), and each entry should be an md file with the core PR number as the file name, and the link to the Gutenberg PR in the file content. The file content should start with the core PR URL, followed by a Markdown list of Gutenberg PRs (see example). Files are used to avoid rebase conflicts.
+If you've changed or added files to the Gutenberg plugin, you'll need to confirm whether the changes are to be backported to [WordPress Core](https://github.com/WordPress/wordpress-develop), and therefore featured in the next release of WordPress.
 
-If you think a file path is wrongly flagged as needing a core backport PR, you can add it to the list of exceptions in `.github/workflows/check-backport-changelog.yml`.
+On open Gutenberg PRs, changes to certain files are flagged as requiring backporting to WordPress Core, for example, PHP files in `/lib` and PHP unit tests. 
 
-## Example
+These changes must have a corresponding Core PR before they can be merged to Gutenberg trunk.
+
+To create a Core PR, first create a [new Trac ticket](https://core.trac.wordpress.org/newticket) and submit a pull request to the [WordPress Core GitHub repository](https://github.com/WordPress/wordpress-develop).
+
+The Core PR can remain open as long as is required.
+
+For more information on how to create a Core PR, see the [WordPress Core Handbook](https://make.wordpress.org/core/handbook/contribute/git/github-pull-requests-for-code-review/).
+
+## How to add a Core Backport PR to the changelog
+
+After you create Core PR, you'll need to create a corresponding markdown file, and place it within the appropriate release subdirectory.
+
+The filename is the Core PR number.
+
+For example, if your Core PR number is `1234` and is slated to be part of the WordPress 6.9 release, the filename will be `1234.md`, and will be placed in the `/backport-changelog/6.9` directory.
+
+The content of the markdown file should be the Github URL of the Core PR, followed by a list of Gutenberg PR Github URLs whose changes are backported in the Core PR.
+
+A single Core PR may contain changes from one or multiple Gutenberg PRs.
+
+### Examples
+
+Let's say the next WordPress release is 6.9. You have two Gutenberg PRs — `1111` and `2222` — whose changes are backported in a single Core PR, number `1234`.
+
+First you would create a file named `1234.md` in the `/6.9` folder. 
+
+If the `/6.9` folder doesn't exist, create it. 
+
+Then you would add the following content to your new file:
 
-Path: `{wp-release-number-x.x}/{core-pr-number}.md`, e.g. `6.6/1234.md`.
-File content:
 ```md
-https://github.com/WordPress/wordpress-develop/pull/{core-pr-number}
+https://github.com/WordPress/wordpress-develop/pull/1234
 
-* https://github.com/WordPress/gutenberg/pull/{first-gb-pr-number}
-* https://github.com/WordPress/gutenberg/pull/{second-gb-pr-number}
+* https://github.com/WordPress/gutenberg/pull/1111
+* https://github.com/WordPress/gutenberg/pull/2222
 ```
+
+If `1234.md` already exists, you would add the Gutenberg PRs to the list in the existing file.
+
+## Why use individual files?
+
+For the backport changelog, Gutenberg uses individual files as opposed to a single changelog file to avoid rebase conflicts.
+
+## Exceptions
+
+Some Gutenberg PRs may be flagged as needing a core backport PR when they don't, for example when the PR contains minor comment changes, or the changes already exist in Core.
+
+For individual PRs, there are two Github labels that can be used to exclude a PR from the backport changelog CI check:
+
+- `Backport from WordPress Core` - Indicates that the PR is a backport from WordPress Core and doesn't need a Core PR.
+- `No Core Sync Required` - Indicates that any changes do not need to be synced to WordPress Core.
+
+If there are specific file or directory changes that should **never** be flagged as requiring a Core backport PR, you can add it to the list of exceptions in [.github/workflows/check-backport-changelog.yml](https://github.com/WordPress/gutenberg/tree/trunk/.github/workflows/check-backport-changelog.yml).
+
+## Where to get help
+
+If you're unsure, you can always ask the Gutenberg Core team for help on the Gutenberg PR `@WordPress/gutenberg-core` or via the #core-editor channel in [WordPress Slack](https://make.wordpress.org/chat/).

docs/reference-guides/core-blocks.md

@@ -396,7 +396,7 @@ Display a list of your most recent comments. ([Source](https://github.com/WordPr
 
 -	**Name:** core/latest-comments
 -	**Category:** widgets
--	**Supports:** align, interactivity (clientNavigation), spacing (margin, padding), typography (fontSize, lineHeight), ~~html~~
+-	**Supports:** align, color (background, gradients, link, text), interactivity (clientNavigation), spacing (margin, padding), typography (fontSize, lineHeight), ~~html~~
 -	**Attributes:** commentsToShow, displayAvatar, displayDate, displayExcerpt
 
 ## Latest Posts

docs/reference-guides/data/data-core-edit-site.md

@@ -24,6 +24,8 @@ _Returns_
 
 ### getCurrentTemplateTemplateParts
 
+> **Deprecated**
+
 Returns the template parts and their blocks for the current edited template.
 
 _Parameters_

lib/README.md

@@ -192,12 +192,12 @@ Existing comments in `lib/load.php` should act as a guide.
 
 ## When to sync changes to Gutenberg PHP with Core and vice versa
 
-If you've changed or added PHP files to the Gutenberg plugin, you'll need to confirm whether the changes are to be synced to WordPress Core, and therefore featured in the next release of WordPress.
+On open Gutenberg PRs, changes to certain files are flagged as requiring syncing (also called "backporting") to WordPress Core, for example, PHP files in `/lib` and PHP unit tests.
 
-The Gutenberg GitHub pull request in question should be labeled with the `Needs PHP backport` label if the changes are to be synced to Core.
+The CI checks will indicate whether you need to create a Core PR. If you do, you'll need to create a corresponding markdown file and place it within the appropriate release subdirectory in the [Core backport changelog](https://github.com/WordPress/gutenberg/tree/trunk/backport-changelog/).
 
-If so, it is recommended to create a [new Trac ticket](https://core.trac.wordpress.org/newticket) and submit a pull request to the [WordPress Core GitHub repository](https://github.com/WordPress/wordpress-develop) soon after your pull request is merged.
+For more information, please refer to the [Core backport changelog documentation](https://github.com/WordPress/gutenberg/tree/trunk/backport-changelog/readme.md).
 
-So too, if you've made changes in WordPress Core to code that also lives in the Gutenberg plugin, these changes will need to be synced (often called "backporting") to Gutenberg. The relevant Gutenberg GitHub pull request should be labeled with the `Backport from WordPress Core` label.
+So too, if you've made changes in WordPress Core to code that also lives in the Gutenberg plugin, these changes will need to be synced to Gutenberg. The relevant Gutenberg GitHub pull request should be labeled with the `Backport from WordPress Core` label.
 
 If you're unsure, you can always ask for help in the #core-editor channel in [WordPress Slack](https://make.wordpress.org/chat/).

lib/experimental/editor-settings.php

@@ -31,6 +31,9 @@ function gutenberg_enable_experiments() {
 	if ( $gutenberg_experiments && array_key_exists( 'gutenberg-zoomed-out-patterns-tab', $gutenberg_experiments ) ) {
 		wp_add_inline_script( 'wp-block-editor', 'window.__experimentalEnableZoomedOutPatternsTab = true', 'before' );
 	}
+	if ( $gutenberg_experiments && array_key_exists( 'gutenberg-quick-edit-dataviews', $gutenberg_experiments ) ) {
+		wp_add_inline_script( 'wp-block-editor', 'window.__experimentalQuickEditDataViews = true', 'before' );
+	}
 }
 
 add_action( 'admin_init', 'gutenberg_enable_experiments' );

lib/experiments-page.php

@@ -151,6 +151,18 @@ function gutenberg_initialize_experiments_settings() {
 		)
 	);
 
+	add_settings_field(
+		'gutenberg-quick-edit-dataviews',
+		__( 'Quick Edit in DataViews', 'gutenberg' ),
+		'gutenberg_display_experiment_field',
+		'gutenberg-experiments',
+		'gutenberg_experiments_section',
+		array(
+			'label' => __( 'Allow access to a quick edit panel in the pages data views.', 'gutenberg' ),
+			'id'    => 'gutenberg-quick-edit-dataviews',
+		)
+	);
+
 	register_setting(
 		'gutenberg-experiments',
 		'gutenberg-experiments'

package.json

@@ -172,7 +172,6 @@
 		"@wordpress/scripts": "file:packages/scripts",
 		"@wordpress/stylelint-config": "file:packages/stylelint-config",
 		"ajv": "8.7.1",
-		"ajv-draft-04": "1.0.0",
 		"appium": "2.0.0",
 		"babel-jest": "29.7.0",
 		"babel-loader": "9.1.3",

packages/base-styles/_mixins.scss

@@ -318,6 +318,7 @@
 	height: $radio-input-size-sm;
 	min-width: $radio-input-size-sm;
 	max-width: $radio-input-size-sm;
+	position: relative;
 
 	@include break-small() {
 		height: $radio-input-size;
@@ -328,17 +329,21 @@
 
 	&:checked::before {
 		box-sizing: inherit;
-		width: 8px;
-		height: 8px;
-		transform: translate(7px, 7px);
+		width: math.div($radio-input-size-sm, 2);
+		height: math.div($radio-input-size-sm, 2);
+		position: absolute;
+		top: 50%;
+		left: 50%;
+		transform: translate(-50%, -50%);
 		margin: 0;
 		background-color: $white;
 
 		// This border serves as a background color in Windows High Contrast mode.
 		border: 4px solid $white;
 
 		@include break-small() {
-			transform: translate(5px, 5px);
+			width: math.div($radio-input-size, 2);
+			height: math.div($radio-input-size, 2);
 		}
 	}
 
@@ -351,7 +356,7 @@
 
 	&:checked {
 		background: var(--wp-admin-theme-color);
-		border-color: var(--wp-admin-theme-color);
+		border: none;
 	}
 }
 

packages/base-styles/_variables.scss

@@ -93,7 +93,7 @@ $border-width-tab: 1.5px;
 $helptext-font-size: 12px;
 $radius-round: 50%;
 $radius-block-ui: 2px;
-$radio-input-size: 20px;
+$radio-input-size: 16px;
 $radio-input-size-sm: 24px; // Width & height for small viewports.
 
 // Deprecated, please avoid using these.

packages/block-editor/src/components/block-toolbar/shuffle.js

@@ -54,10 +54,16 @@ export default function Shuffle( { clientId, as = Container } ) {
 			return EMPTY_ARRAY;
 		}
 		return patterns.filter( ( pattern ) => {
+			const isCorePattern =
+				pattern.source === 'core' ||
+				( pattern.source?.startsWith( 'pattern-directory' ) &&
+					pattern.source !== 'pattern-directory/theme' );
 			return (
 				// Check if the pattern has only one top level block,
 				// otherwise we may shuffle to pattern that will not allow to continue shuffling.
 				pattern.blocks.length === 1 &&
+				// We exclude the core patterns and pattern directory patterns that are not theme patterns.
+				! isCorePattern &&
 				pattern.categories?.some( ( category ) => {
 					return categories.includes( category );
 				} ) &&

packages/block-editor/src/components/block-tools/use-show-block-tools.js

@@ -45,8 +45,13 @@ export function useShowBlockTools() {
 			editorMode === 'navigation';
 
 		const isZoomOut = editorMode === 'zoom-out';
+		const _showZoomOutToolbar =
+			isZoomOut &&
+			block?.attributes?.align === 'full' &&
+			! _showEmptyBlockSideInserter &&
+			! maybeShowBreadcrumb;
 		const _showBlockToolbarPopover =
-			! isZoomOut &&
+			! _showZoomOutToolbar &&
 			! getSettings().hasFixedToolbar &&
 			! _showEmptyBlockSideInserter &&
 			hasSelectedBlock &&
@@ -58,12 +63,7 @@ export function useShowBlockTools() {
 			showBreadcrumb:
 				! _showEmptyBlockSideInserter && maybeShowBreadcrumb,
 			showBlockToolbarPopover: _showBlockToolbarPopover,
-			showZoomOutToolbar:
-				hasSelectedBlock &&
-				isZoomOut &&
-				! _showEmptyBlockSideInserter &&
-				! maybeShowBreadcrumb &&
-				! _showBlockToolbarPopover,
+			showZoomOutToolbar: _showZoomOutToolbar,
 		};
 	}, [] );
 }

packages/block-editor/src/components/iframe/content.scss

@@ -54,7 +54,7 @@
 		display: flex;
 		flex-direction: column;
 
-		> .is-root-container {
+		> .is-root-container:not(.wp-block-post-content) {
 			flex: 1;
 			display: flex;
 			flex-direction: column;

packages/block-library/src/group/deprecated.js

@@ -109,15 +109,11 @@ const deprecated = [
 			);
 		},
 		isEligible: ( { layout } ) =>
-			! layout ||
-			layout.inherit ||
-			( layout.contentSize && layout.type !== 'constrained' ),
+			layout?.inherit ||
+			( layout?.contentSize && layout?.type !== 'constrained' ),
 		migrate: ( attributes ) => {
 			const { layout = null } = attributes;
-			if ( ! layout ) {
-				return attributes;
-			}
-			if ( layout.inherit || layout.contentSize ) {
+			if ( layout?.inherit || layout?.contentSize ) {
 				return {
 					...attributes,
 					layout: {