Block Comments: Add blockComment block support

[karthick-murugan]

What?

Closes #71784

Adds blockCommentId as a global attribute to all blocks to resolve 400 errors when adding block comments to ServerSideRender blocks.

Why?

When adding block comments to blocks that use ServerSideRender components, a 400 error occurs because the blockCommentId attribute is not recognized server-side. The REST API validation rejects the request with:

How?

This PR implements blockCommentId as a global attribute similar to metadata and lock attributes:

PHP Implementation

• Adds a filter on register_block_type_args to inject blockCommentId as a global attribute for all blocks
• Ensures the attribute is available during block registration, not after (avoiding timing issues)
• Uses the same pattern as other global attributes in WordPress core

JavaScript Implementation

• Adds a hook on blocks.registerBlockType to ensure blockCommentId is registered client-side
• Follows the same pattern as the existing lock and metadata hooks
• Ensures consistency between server and client-side attribute definitions

Testing Instructions

1. Open a post or page in the editor
2. Insert a block that uses ServerSideRender (e.g., Latest Comments)
3. Add a block comment to the ServerSideRender block
4. Verify that no 400 error occurs in the browser console
5. Confirm that the block comment is successfully added and displayed

Video

REC-20250923193256.mp4

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: karthick-murugan <karthickmurugan@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[Mamaduka]

This seems to be a leftover from an AI.

[Mamaduka]

The feature is still experimental, so this should be placed in lib/experimental/block-comments.php.

[Mamaduka]

This logic already exists in packages/editor/src/components/collab-sidebar/index.js. There is no need for duplication.

[karthick-murugan]

Updated all the changes @Mamaduka

[t-hamano]

Thanks for the PR!

I think there is a contradiction between the PR title and the implementation. I believe this PR just adds block attributes on the server-side, not block support.

This is code generated by an AI and has not been tested, but if we really want to add block support, the implementation should look something like this:

Details

<?php
/**
 * Block comment block support flag.
 *
 * @package gutenberg
 */

/**
 * Registers the blockComment block attribute for block types that support it.
 * This support is enabled by default and can be disabled by setting blockComment: false in block.json.
 *
 * @param WP_Block_Type $block_type Block Type.
 */
function gutenberg_register_block_comment_support( $block_type ) {
	// Check if block has explicitly disabled block comment support
	$has_block_comment_disabled = block_has_support( $block_type, array( 'blockComment' => false ), false );

	// If explicitly disabled, don't register the attribute
	if ( $has_block_comment_disabled ) {
		return;
	}

	if ( ! $block_type->attributes ) {
		$block_type->attributes = array();
	}

	if ( ! array_key_exists( 'blockComment', $block_type->attributes ) ) {
		$block_type->attributes['blockComment'] = array(
			'type' => 'string',
		);
	}
}

// Register the block support.
WP_Block_Supports::get_instance()->register(
	'block-comment',
	array(
		'register_attribute' => 'gutenberg_register_block_comment_support',
	)
);

[Mamaduka]

I think there is a contradiction between the PR title and the implementation. I believe this PR just adds block attributes on the server-side, not block support.

IMO, that's what's needed for this case, but I agree the title/description needs to be updated.

P.S. There's no need to add block-supports for this feature, since it's controlled at the post-type level and not by individual blocks.

[t-hamano]

Another idea: how about treating the blockCommentId as part of the metadata? That way we can avoid a core backport PR and hook.

[Mamaduka]

Another idea: how about treating the blockCommentId as part of the metadata? That way we can avoid a core backport PR and hook.

I like the idea; the value seems more suitable for metadata. @adamsilverstein, what do you think?

[adamsilverstein]

Another idea: how about treating the blockCommentId as part of the metadata? That way we can avoid a core backport PR and hook.
I like the idea; the value seems more suitable for metadata. @adamsilverstein, what do you think?

I like the idea in principle, would this mean moving the id from attributes to metadata? I'm not familiar with how block metadata works so I'll have to dig deeper to review or test a PR.

[t-hamano]

would this mean moving the id from attributes to metadata?

Yes. The block markup will be changed as follows:

<!-- From -->

<!-- wp:paragraph { "metadata": { "name": "My Paragraph" }, "blockCommentId": 1 } -->
<p>Hello World</p>
<!-- /wp:paragraph -->

<!-- To -->

<!-- wp:paragraph { "metadata": { "name": "My Paragraph", "blockCommentId": 1 } } -->
<p>Hello World</p>
<!-- /wp:paragraph -->

[t-hamano]

Another idea: how about treating the blockCommentId as part of the metadata? That way we can avoid a core backport PR and hook.

To advance this approach, I have updated the title of the issue to follow the new approach. #71784

[adamsilverstein]

Yes. The block markup will be changed as follows:

Great, thanks for clarifying @t-hamano. My next question which I can answer by testing your PR is if existing comment Ids need to be migrated to the metadata location to keep existing comments intact.

ps. Does the project have a description of what types of data should be stored in metadata vs. attributes? is metadata just a specific attribute or does it have special properties/APIs?

[t-hamano]

if existing comment Ids need to be migrated to the metadata location to keep existing comments intact.

The Block Commenting is still an experimental feature, so I don't think we should migrate existing comment IDs. Breaking changes should be acceptable for now.

[adamsilverstein]

The Block Commenting is still an experimental feature, so I don't think we should migrate existing comment IDs. Breaking changes should be acceptable for now.

Makes sense, thanks!

[t-hamano]

Let's try the new approach in a separate PR.

@karthick-murugan, I'd like to close this PR, but thanks for your efforts!