Synced with trunk and resolved conflicts

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

@@ -4,20 +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
+              if: github.event_name == 'push'
               run: |
-                  git diff --quiet HEAD^ HEAD -- backport-changelog || echo "changes=true" >> $GITHUB_OUTPUT
+                  if git diff --quiet HEAD^ HEAD -- backport-changelog; then
+                      echo "skip_sync=true" >> "$GITHUB_ENV"
+                  fi
             - name: Sync Issue
-              if: env.changes == 'true'
+              if: ${{ ! env.skip_sync }}
               uses: actions/github-script@60a0d83039c74a4aee543508d2ffcb1c3799cdea # v7.0.1
               with:
                   script: |
@@ -52,18 +65,20 @@ jobs:
                       const endDelimiter = '<!-- END TRUNK BACKPORT CHANGELOG -->';
                       const autoGeneratedContent = `${startDelimiter}\n${processedChangelog}\n${endDelimiter}`;
 
-                      const regex = new RegExp(`${startDelimiter}[\\s\\S]*${endDelimiter}`);
+                      const existingBody = latestIssue.body ?? '';
+
                       let newBody;
 
-                      if (regex.test(latestIssue.body)) {
+                      const regex = new RegExp(`${startDelimiter}[\\s\\S]*${endDelimiter}`);
+                      if (regex.test(existingBody)) {
                         // If delimiters exist, replace the content between them
-                        newBody = latestIssue.body.replace(regex, autoGeneratedContent);
+                        newBody = existingBody.replace(regex, autoGeneratedContent);
                       } else {
                         // If delimiters don't exist, append the new content at the end
-                        newBody = `${latestIssue.body}\n\n${autoGeneratedContent}`;
+                        newBody = `${existingBody}\n\n${autoGeneratedContent}`;
                       }
 
-                      if (newBody.trim() !== latestIssue.body.trim()) {
+                      if (newBody.trim() !== existingBody.trim()) {
                         await github.rest.issues.update({
                           owner: context.repo.owner,
                           repo: context.repo.repo,

backport-changelog/6.7/7020.md

@@ -0,0 +1,3 @@
+https://github.com/WordPress/wordpress-develop/pull/7020
+
+* https://github.com/WordPress/gutenberg/pull/63470

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_

docs/reference-guides/interactivity-api/api-reference.md

@@ -840,7 +840,7 @@ const { state } = store("myPlugin", {
 });
 ```
 
-As mentioned above with [`wp-on`](#wp-on), [`wp-on-window`](#wp-on-window), and [`wp-on-document`](#wp-on-document), an async action should be used whenever the `async` versions of the aforementioned directives cannot be used due to the action requiring synchronous access to the `event` object. Synchronous access is reqired whenever the action needs to call `event.preventDefault()`, `event.stopPropagation()`, or `event.stopImmediatePropagation()`. To ensure that the action code does not contribute to a long task, you may manually yield to the main thread after calling the synchronous event API. For example:
+As mentioned above with [`wp-on`](#wp-on), [`wp-on-window`](#wp-on-window), and [`wp-on-document`](#wp-on-document), an async action should be used whenever the `async` versions of the aforementioned directives cannot be used due to the action requiring synchronous access to the `event` object. Synchronous access is required whenever the action needs to call `event.preventDefault()`, `event.stopPropagation()`, or `event.stopImmediatePropagation()`. To ensure that the action code does not contribute to a long task, you may manually yield to the main thread after calling the synchronous event API. For example:
 
 ```js
 // Note: In WordPress 6.6 this splitTask function is exported by @wordpress/interactivity.

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/compat/wordpress-6.7/block-bindings.php

@@ -0,0 +1,40 @@
+<?php
+/**
+ * Temporary compatibility code for new functionalitites/changes related to block bindings APIs present in Gutenberg.
+ *
+ * @package gutenberg
+ */
+
+/**
+ * Adds the block bindings sources registered in the server to the editor settings.
+ *
+ * This allows them to be bootstrapped in the editor.
+ *
+ * @param array $settings The block editor settings from the `block_editor_settings_all` filter.
+ * @return array The editor settings including the block bindings sources.
+ */
+function gutenberg_add_server_block_bindings_sources_to_editor_settings( $editor_settings ) {
+	// Check if the sources are already exposed in the editor settings.
+	if ( isset( $editor_settings['blockBindingsSources'] ) ) {
+		return $editor_settings;
+	}
+
+	$registered_block_bindings_sources = get_all_registered_block_bindings_sources();
+	if ( ! empty( $registered_block_bindings_sources ) ) {
+		// Initialize array.
+		$editor_settings['blockBindingsSources'] = array();
+		foreach ( $registered_block_bindings_sources as $source_name => $source_properties ) {
+			// Add source with the label to editor settings.
+			$editor_settings['blockBindingsSources'][ $source_name ] = array(
+				'label' => $source_properties->label,
+			);
+			// Add `usesContext` property if exists.
+			if ( ! empty( $source_properties->uses_context ) ) {
+				$editor_settings['blockBindingsSources'][ $source_name ]['usesContext'] = $source_properties->uses_context;
+			}
+		}
+	}
+	return $editor_settings;
+}
+
+add_filter( 'block_editor_settings_all', 'gutenberg_add_server_block_bindings_sources_to_editor_settings', 10 );