[adamsilverstein]

Stack: Custom Comment Types (#35214)

	PR	Change	Builds on
	#12311	register_comment_type() registration API	trunk
	#51	REST /wp/v2/comment-types endpoint	WordPress#12311
👉	#52	Capabilities object (advisory) (this PR)	WordPress#12311
	#55	Enforce type capabilities in map_meta_cap()	#52
	#56	Type-aware REST moderation	#55
	#57	Type-aware admin comment dimming	#56
	#53	render_callback display callback	WordPress#12311
	#54	is_ping ping grouping	#53
	#12310	default_excluded_comment_types filter	trunk
	#58	wp_update_comment_counts() recount helper	WordPress#12310

WordPress#12311 and WordPress#12310 are on WordPress/wordpress-develop; the rest are fork PRs targeting their parent branch and will retarget to trunk as their base lands.

Description refreshed by Claude after another review:

What

Adds a capabilities object to comment types, modeled on WP_Post_Type and get_post_type_capabilities(). A registered comment type can describe its own edit, delete, and moderate capabilities through $comment_type_object->cap.

register_comment_type( 'review', array( 'capability_type' => 'review' ) );

$obj = get_comment_type_object( 'review' );
$obj->cap->edit_comment;      // 'edit_review' (meta)
$obj->cap->edit_comments;     // 'edit_reviews'
$obj->cap->moderate_comments; // 'moderate_reviews'

Why

Per-type permissions are one of the main asks on https://core.trac.wordpress.org/ticket/35214. Before core can enforce anything, a type needs a way to declare which capabilities belong to it, and the REST endpoint needs something to expose. This PR adds only that model.

On its own this PR changes no behavior. map_meta_cap() is untouched, so the capabilities are advisory. Anyone with moderate_comments can still edit, approve, spam, or delete comments of every type. The enforcement lives in the next PR (#55, #55), and the two should land in the same release: once #55 maps them, current_user_can( 'edit_review', $id ) on a custom base changes from a literal capability check to a mapped one. Shipping a release in between would leave that meaning ambiguous.

How

• New capability_type registration argument (default 'comment'). An array like array( 'story', 'stories' ) supplies an explicit plural.
• New capabilities registration argument to override individual generated names, meta or primitive.
• New get_comment_type_capabilities() in src/wp-includes/comment.php builds the set: meta caps edit_comment, delete_comment, moderate_comment from the singular base, and primitives edit_comments, edit_others_comments, delete_comments, moderate_comments from the plural.
• WP_Comment_Type::set_props() stores the result in $cap, collapses an array capability_type back to its singular base, and drops the capabilities input.
• The built-in types register without a capability_type, so they all resolve to core's existing edit_comment and moderate_comments.

A few deliberate choices:

• No read_comment. Core has no semantics for reading a single comment and nothing would map it, so it is left out (and a test pins that) until there is.
• The "others" axis is edit-only for now: edit_others_comments without a delete_others_comments counterpart. One can be added compatibly once enforcement settles which primitives the moderation flows actually check.
• The docs warn against reusing a post type base. A base of 'post' generates edit_comment => 'edit_post', which sends a comment ID through the post branch of map_meta_cap().

Testing

1. Run the comment and capability suites:
   • vendor/bin/phpunit --group comment
   • vendor/bin/phpunit --group capabilities
2. In a mu-plugin, register a type with a custom base and inspect it:

   add_action( 'init', function () {
       register_comment_type( 'review', array( 'capability_type' => array( 'review', 'reviews' ) ) );
   } );

   Then wp eval 'print_r( get_comment_type_object( "review" )->cap );' should list the *_review / *_reviews names.
3. Confirm nothing changed for existing comments: as an editor, moderate and edit regular comments in wp-admin as before.

Out of scope / follow-ups

• Enforcement in map_meta_cap(): Comments: Enforce registered comment type capabilities in map_meta_cap() (Trac #35214) #55.
• REST moderation gates and the admin AJAX gate build on Comments: Enforce registered comment type capabilities in map_meta_cap() (Trac #35214) #55: Comments: Make REST comment moderation comment-type aware (Trac #35214, Stage 3) #56 and Comments: Make admin comment dimming comment-type aware (Trac #35214, Stage 3) #57.
• Exposing cap through the REST comment types endpoint: Comments: Add a REST API endpoint for comment types #51.

See #35214.

Trac ticket: https://core.trac.wordpress.org/ticket/35214

AI Use

Claude Code did the typing here, I did the asking. I will review and test.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs.

Core Committers: Use this line as a base for the props when committing in SVN:

Props adamsilverstein.

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

---

Props Bot commands

You can trigger Props Bot actions by commenting on this PR:

• @propsbot add <username> to give props to a GitHub user. Requires write access.
• @propsbot remove <username> to leave a user out of the props. Requires write access.
• @propsbot refresh to refresh this list. Adding the props-bot label works too.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 6a2c5333-5f64-40b7-8790-39b591d7416c

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• Trigger review

Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/comment-type-caps

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

[adamsilverstein]

Follow-up: capability enforcement via map_meta_cap()

This PR intentionally keeps the cap object advisory. Proposing the lowest-risk path to actual enforcement, mirroring register_post_type():

• Opt-in. Default capability_type => 'comment' stays byte-for-byte identical (editing still derives from the parent post's edit_post; moderation still uses the moderate_comments primitive). Only types declaring a non-default capability_type / explicit capabilities route through the new handling.
• Map, don't grant. New per-type meta caps (read_comment / edit_comment / delete_comment / moderate_comment) map to the type's primitives via map_meta_cap(); sites grant the primitives to roles, exactly as with custom post types. No role (admin included) is silently locked out because the default path is unchanged.
• Stage the call-site rerouting (edit → moderation → delete) instead of one audit-heavy change, so each surface gets a focused security review.

One question to settle before coding: do custom comment types keep deriving edit permission from the parent post, or get a permission boundary independent of it? That is the substantive design fork (the comment:19 concern). Happy to write this up on Trac #35214 if the direction looks right.