Comments: Add a REST API endpoint for comment types by adamsilverstein · Pull Request #51 · adamsilverstein/wordpress-develop

adamsilverstein · 2026-06-24T22:21:06Z

Description

Adds a read-only /wp/v2/comment-types REST endpoint that exposes the comment types registered via register_comment_type(), mirroring the existing post types controller (/wp/v2/types).

This lets REST clients discover the registered comment types and their labels. It directly serves the block editor's inline-commenting work (see #35214 comment:48), which needs to add and query comments by a registered block_comment type.

What it adds

WP_REST_Comment_Types_Controller with two read-only routes:
- GET /wp/v2/comment-types - list public comment types.
- GET /wp/v2/comment-types/{type} - a single comment type.
A show_in_rest argument on WP_Comment_Type, defaulting to the value of public (the same way show_ui cascades). It gates which types the endpoint exposes:
- comment, pingback, trackback are public, so they are visible.
- the internal note type is not public, so it is not exposed.
The controller exposes name, slug, description, and (in the edit context) labels. The edit context requires the moderate_comments capability.

The endpoint is additive and read-only, so there is no back-compat impact.

Scope / boundary

This is the next small, additive step on the #35214 tracking ticket, after:

Comments: Introduce a register_comment_type() API WordPress/wordpress-develop#12311 - the register_comment_type() registration API + labels (this PR is stacked on it and targets that branch; it will be retargeted to trunk once Comments: Introduce a register_comment_type() API WordPress/wordpress-develop#12311 lands).
Comments: Add filter for comment types excluded from queries by default WordPress/wordpress-develop#12310 (#65537) - the default_excluded_comment_types query filter.

Out of scope here (follow-ups): capabilities / meta-caps, admin UI, and generalizing the remaining hard-coded comment-type handling.

Testing

tests/phpunit/tests/rest-api/rest-comment-types-controller.php covers route registration, the context param, listing (including exclusion of note and show_in_rest => false types), single reads, invalid/non-REST type handling, edit-context permission checks, and the schema. WP_Comment_Type's show_in_rest cascade is asserted in tests/phpunit/tests/comment/types.php.

$ phpunit --group comment
OK (599 tests, 1506 assertions)

$ phpunit --filter WP_Test_REST_Comment_Types_Controller
OK (18 tests, 71 assertions)

PHPCS and PHPStan are clean on the changed files.

See #35214.

Review updates

Following a review pass over the stack:

Restored the authentication block in the QUnit REST fixture. tests/qunit/fixtures/wp-api-generated.js is generated, and the regeneration that added the comment-types routes had also dropped the application passwords authentication block. Diffed against trunk's copy to confirm those seven lines were the only unrelated removal, and put them back - otherwise CI's "version-controlled files not modified" check fails on a file the PR did not mean to touch.
Documented why the items link is advertised even when it answers 401. A caller without edit_posts may only pass type=comment to the comments endpoint, so for every other type the link is not followable anonymously. It stays advertised anyway: what a caller may query is a question for the comments endpoint rather than something discovery should second-guess, and the answer changes once per-type capabilities land. Better stated in a docblock than rediscovered by the next reader.
Dropped embed from the description field's contexts. The post types controller exposes description in view and edit only; there was no reason for this one to differ.

Testing

$ phpunit --group comment
OK (722 tests, 1796 assertions)

$ phpunit --filter WP_Test_REST_Comment_Types_Controller
OK (31 tests, 116 assertions)

PHPCS reports no new warnings on the changed files and PHPStan is clean.

AI Use

Code and description both written with 🤖 Claude Code. I will review and test.

github-actions · 2026-06-24T22:21:16Z

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.

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.

coderabbitai · 2026-06-24T22:21:16Z

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

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c68b08f7-0d0c-4bbb-a86b-50ef901c3e9b

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/rest-comment-types

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

Expose registered comment types through a read-only `/wp/v2/comment-types` controller, mirroring the post types controller (`/wp/v2/types`). This lets REST clients discover the registered types and their labels, which the block editor's inline-commenting work needs in order to add and query comments by type. Add a `show_in_rest` argument to `WP_Comment_Type` (defaulting to the value of `public`, as `show_ui` does) to gate which types the endpoint exposes. The built-in `comment`, `pingback`, and `trackback` types are public and therefore visible; the internal `note` type is not. Builds on the registration API in WordPress#12311. See #35214.

Cover the `/wp/v2/comment-types` controller: route registration, the context param, listing public types while excluding non-REST types (`note` and types that opt out via `show_in_rest`), single-type reads, permission checks for the `edit` context, and the item schema. Also assert the `show_in_rest` cascade on `WP_Comment_Type` and add the two new routes to the REST schema route list. See #35214.

Add happy-path coverage for the controller's dedicated HEAD-request handling in get_items() and prepare_item_for_response(), mirroring the post-types controller (ticket 56481): a collection HEAD request returns 200 without preparing item data, single-item HEAD requests still run the rest_prepare_comment_type filter and allow header injection, and HEAD requests with _fields succeed. Also assert the api.w.org/items link points at the type-filtered comments collection. See #35214.

…t-types # Conflicts: # src/wp-includes/class-wp-comment-type.php

@ticket

- Document exactly what 'show_in_rest' gates (the read-only discovery endpoint) in the property docblock and the register_comment_type() args reference, including that it does not affect comment readability via /wp/v2/comments, and realign the args hash. - Document the deliberate divergence from WP_Post_Type in defaulting 'show_in_rest' from 'public': the false default there is pure back-compat for pre-REST post types, which a new registry lacks. - Reuse the existing 'not allowed to edit comments' string instead of introducing a new translator-facing string. - Correct the get_items() summary (it retrieves REST-exposed types, not public ones) and mark the seam where per-type capability checks land once comment type capabilities exist. - Tests: pin the anonymous 401-before-type-resolution ordering (a deliberate divergence from the post types controller's 404), cover HEAD for invalid types, _fields-limited responses, additional fields registered for 'comment-type', edit-context labels for all exposed types with 'note' still hidden from moderators, and add missing @ticket tags. Drop the hand-rolled tear_down() now handled by the test framework.

…props().

tests/qunit/fixtures/wp-api-generated.js is written by test_build_wp_api_client_fixtures and diff-checked in CI; the new /wp/v2/comment-types routes must be reflected in the committed copy.

…t-types # Conflicts: # src/wp-includes/comment.php

…xture. The fixture was regenerated in an environment without SSL and outside a local environment type, so wp_is_application_passwords_available() returned false and the authentication object came out as an empty array. That hunk has nothing to do with the comment types routes, and it fails the "version-controlled files are not modified" check on any repo that runs it, because a canonical regeneration puts the object back. Restore the block. The fixture is now identical to trunk apart from the two new comment-types route entries, which were correct already. See #35214.

Three things the endpoint did without saying why. The advertised 'items' link points at the comments collection filtered by type, but that endpoint's `type` parameter is protected: a caller without `edit_posts` may only ask for 'comment', so for every other type the link answers 401 to an anonymous client. Keeping the link is the right call - what a caller may query belongs to the comments endpoint, and the answer changes once per-type capabilities land - but the next reader should not have to rediscover it. The `description` field was exposed in embed context, where the post types controller it mirrors exposes only view and edit. Embed is conventionally identity fields; there is no reason for the divergence, so drop it. Two behaviors also had no test: a non-public type that sets show_in_rest is listed and readable, which is the direction the exclusion tests miss, and the collection's edit context answers 403 to an authenticated caller without the capability, matching the single-item route. See #35214.

…t-types # Conflicts: # src/wp-includes/comment.php

@SInCE

…troller. The branch was written while trunk was 7.1-alpha; trunk is now 7.2-alpha, so the controller's and show_in_rest property's @SInCE tags would have credited the wrong release - and left WP_Comment_Type internally contradictory, with the property claiming to predate its class. Also trim a speculative design note about future per-type capabilities out of get_items() (that discussion belongs on the ticket), and move two test methods above the protected helpers to restore the tests-then-helpers layout used by the rest of the file. See #35214.

…covery. show_in_rest deliberately cascades from public alone, so a type registered with internal => true but left public still defaults to being listed by the discovery endpoint. That combination is most likely an oversight on the registrant's part, and the argument contract should say plainly how to opt out rather than leaving the cascade to be inferred: pass show_in_rest => false or public => false, as the built-in note type does. See #35214.

adamsilverstein mentioned this pull request Jun 24, 2026

Comments: Add a capabilities object to comment types #52

Open

adamsilverstein added 3 commits June 24, 2026 23:30

adamsilverstein force-pushed the feature/rest-comment-types branch from 6be8f2f to 7daed7e Compare June 25, 2026 06:32

adamsilverstein added 4 commits July 11, 2026 10:03

Merge branch 'feature/register-comment-type' into feature/rest-commen…

e6490e1

…t-types # Conflicts: # src/wp-includes/class-wp-comment-type.php

Coding Standards: Remove a double blank line in WP_Comment_Type::set_…

e06ca77

…props().

REST API: Regenerate the wp-api.js fixture for the comment-types routes.

22c3975

tests/qunit/fixtures/wp-api-generated.js is written by test_build_wp_api_client_fixtures and diff-checked in CI; the new /wp/v2/comment-types routes must be reflected in the committed copy.

adamsilverstein force-pushed the feature/rest-comment-types branch from 8238c8a to 22c3975 Compare July 11, 2026 17:17

adamsilverstein mentioned this pull request Jul 17, 2026

Comments: Add a REST API endpoint for comment types #60

Draft

adamsilverstein added 6 commits August 12, 2026 16:49

Merge branch 'feature/register-comment-type' into feature/rest-commen…

0997e29

…t-types # Conflicts: # src/wp-includes/comment.php

Merge branch 'feature/register-comment-type' into feature/rest-commen…

0543a34

…t-types # Conflicts: # src/wp-includes/comment.php

Navigation Menu

Comments: Add a REST API endpoint for comment types - #51

Comments: Add a REST API endpoint for comment types#51
adamsilverstein wants to merge 13 commits into
feature/register-comment-typefrom
feature/rest-comment-types

adamsilverstein commented Jun 24, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Jun 24, 2026

Uh oh!

coderabbitai Bot commented Jun 24, 2026 •

edited

Loading

Review skipped

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

adamsilverstein commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

What it adds

Scope / boundary

Testing

Review updates

Testing

AI Use

Uh oh!

github-actions Bot commented Jun 24, 2026

Uh oh!

coderabbitai Bot commented Jun 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

adamsilverstein commented Jun 24, 2026 •

edited

Loading

coderabbitai Bot commented Jun 24, 2026 •

edited

Loading