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: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: adamsilverstein <adamsilverstein@git.wordpress.org>
Co-authored-by: swissspidy <swissspidy@git.wordpress.org>

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

Size Change: +15 B (0%)

Total Size: 1.95 MB

_{compressed-size-action}

Flaky tests detected in f64cfef.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/17763784020
📝 Reported issues:

• [Flaky Test] ensures List View global shortcut works properly #51533 in /test/e2e/specs/editor/various/list-view.spec.js

Why is this a top level support and not a property of the editor support? That would make way more sense to me at first glance. Can't have block-comments without editor support.

That's a good point, @swissspidy! The block comments don't work without the block editor.

@t-hamano, I think we also will need to update Gutenberg_REST_Comment_Controller, so that it accounts for disabled post type support.

• In 543ab97: Make block-comments part of editor support.
• In : f64cfef: Update Gutenberg_REST_Comment_Controller to check whether the post type supports block-comments.

I would like to confirm under what conditions the block comment support is considered enabled. My understanding is as follows, but is it correct?

✅Block Comment is enabled:

register_post_type(
	'post',
	array(
		// ...
		'supports' => array(
			'title',
			'editor' => array(
				'block-comments' => true,
			),
		),
	)
);

❌ Block Comment is disabled:

register_post_type(
	'post',
	array(
		// ...
		'supports' => array( 'title', 'editor' ),
	)
);

register_post_type(
	'post',
	array(
		// ...
		'supports' => array( 'title' ),
	)
);

register_post_type(
	'post',
	array(
		// ...
		'supports' => array(
			'title',
			'editor' => array(
				'block-comments' => false,
			),
		),
	)
);

We could also say it's implicitly enabled unless explicitly disabled.

So 'supports' => array( 'title', 'editor' ), would mean it's enabled

@swissspidy, I think we want to make this feature opt-in and enable it only for Posts and Pages by default. The 'supports' => array( 'title', 'editor' ) would mean enabling it for any post type that supports the editor.

I just realized that add_post_type_support doesn't merge support sub-properties. The last call will override previous ones.

This could be problematic for our use cases, as the editor is beginning to manage some of its features through sub-property flags.

add_action( 'init', function() {
	add_post_type_support( 'page', 'editor', array(
		'default-mode' => 'template-locked',
	) );

	// This second call will overwrite the first sub-support property instead of merging.
	add_post_type_support( 'page', 'editor', array(
		'block-comments' => true,
	) );
} );

I just realized that add_post_type_support doesn't merge support sub-properties. The last call will override previous ones.

This could be problematic for our use cases, as the editor is beginning to manage some of its features through sub-property flags.

Ideally, we may need to update the add_post_type_support() function so that the third argument (sub-properties) is automatically merged. However, for now, we may need to incorporate the subproperty merging logic ourselves into this PR, and I plan to work on that before merging this PR.

In 42025a0, I made sure to explicitly merge the subproperties so that even if the consumer had predefined editor support subproperties, they wouldn't be overwritten.

@t-hamano, are there any blockers here?

@Mamaduka I think there are no blockers. Are we good to merge this PR?

@t-hamano, yes. Let's merge this.