Editor: Add emoji reactions as a comment type for Notes by adamsilverstein · Pull Request #10930 · WordPress/wordpress-develop

adamsilverstein · 2026-02-14T01:35:52Z

Summary

Introduces the reaction comment type to support emoji reactions on collaborative Notes, replacing the previous _wp_note_reactions meta approach from Gutenberg PR #75148 (now closed in favor of #75549).

Each reaction is stored as a separate comment with comment_type = 'reaction' rather than as serialized meta data on the note.

Changes

Avatar support: Add reaction to the allowed avatar comment types
Admin exclusions: Exclude reactions from the admin comment list table and comment type filter
Comment counts: Exclude reactions from approved and pending comment count queries
REST API: Extend WP_REST_Comments_Controller to handle reaction type:
- Permissions checks treat reactions like notes (edit_comment/edit_post instead of moderate_comments)
- Validation: parent must be a note, content must be a valid emoji slug (heart, celebration, smile, eyes, rocket), one emoji per user per note
- Auto-approve reactions (skip spam/flood checks)
- Read permission and link embedding match note behavior
Tests: PHPUnit tests for reaction creation, invalid parent, invalid emoji, duplicate detection, different reactions on same note, login requirement, and comment count exclusion
Fixtures: Regenerated wp-api-generated.js

Trac ticket

See https://core.trac.wordpress.org/ticket/63191

Test plan

🤖 Generated with Claude Code

github-actions · 2026-02-14T01:36:03Z

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, westonruter, noruzzaman.

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

src/wp-includes/comment.php

westonruter · 2026-02-14T01:40:38Z

tests/qunit/fixtures/wp-api-generated.js

-            }
-        }
-    },
+    "authentication": [],


Why did this changed? Stale from a previous commit?

yes, I ran the test_build_wp_api_client_fixtures test locally to regenerate fixtures and this was the result. I wrote that test so I'm confident this is correct, but happy to add in a separate PR since its unrelated to the current changes. ideally we should have a check similar to package lock that checks if running the regeneration changes the fixture and reject the merge if so.

westonruter · 2026-02-14T01:41:16Z

tests/qunit/fixtures/wp-api-generated.js

-                            "properties": [],
+                            "properties": {
+                                "wp_pattern_sync_status": {
+                                    "type": "string",
+                                    "title": "",
+                                    "description": "",
+                                    "default": "",
+                                    "enum": [
+                                        "partial",
+                                        "unsynced"
+                                    ]
+                                }
+                            },


I guess this fixture wasn't updated correctly for a previous commit that introduced this?

correct. you can verify by running the test_build_wp_api_client_fixtures test locally to regenerate fixtures. the file should match what you see in this PR. (I used WP_TESTS_DIR=/Users/adamsilverstein/repositories/wordpress-develop/tests/phpunit/ DB_PASSWORD=**** php ./vendor/bin/phpunit --verbose -c ./phpunit.xml.dist --filter=test_build_wp_api_client_fixture)

src/wp-includes/comment.php

github-actions · 2026-02-14T08:08:18Z

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

All changes will be lost when closing a tab with a Playground instance.
All changes will be lost when refreshing the page.
A fresh instance is created each time the link below is clicked.
Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

Introduce the `reaction` comment type to support emoji reactions on collaborative Notes, replacing the previous `_wp_note_reactions` meta approach. Changes include: - Add `reaction` to avatar comment types. - Exclude reactions from admin comment lists and comment counts. - Extend the REST API Comments Controller to handle reactions: permissions checks, validation (valid emoji slugs, parent must be a note, one emoji per user per note), auto-approval, and content allowed checks. - Add PHPUnit tests for reaction creation, validation, and counting. - Regenerate API fixtures. Props flavor flavor. See #63191. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

adamsilverstein · 2026-02-18T14:43:30Z

I have updated this backport PR to apply the custom comment type approach for storage used in WordPress/gutenberg#75549 which replaces the meta based approach in WordPress/gutenberg#75144.

westonruter · 2026-02-18T21:51:53Z

src/wp-admin/includes/class-wp-comments-list-table.php

 		$comment_type = '';

-		if ( ! empty( $_REQUEST['comment_type'] ) && 'note' !== $_REQUEST['comment_type'] ) {
+		if ( ! empty( $_REQUEST['comment_type'] ) && ! in_array( $_REQUEST['comment_type'], array( 'note', 'reaction' ), true ) ) {


It seems like perhaps there should be some centralized place for this list of non-comment comment types which can be re-used. This would avoid having to manually and tediously update all these instances whenever there is a new such type introduced. Maybe like a wp_get_internal_comment_types().

Then this could be:

Suggested change

if ( ! empty( $_REQUEST['comment_type'] ) && ! in_array( $_REQUEST['comment_type'], array( 'note', 'reaction' ), true ) ) {

if ( ! empty( $_REQUEST['comment_type'] ) && ! in_array( $_REQUEST['comment_type'], wp_get_internal_comment_types(), true ) ) {

westonruter · 2026-02-18T21:52:45Z

src/wp-admin/includes/class-wp-comments-list-table.php

 			'post_id'                   => $post_id,
 			'type'                      => $comment_type,
-			'type__not_in'              => array( 'note' ),
+			'type__not_in'              => array( 'note', 'reaction' ),


With the above suggestion:

Suggested change

'type__not_in' => array( 'note', 'reaction' ),

'type__not_in' => wp_get_internal_comment_types(),

westonruter · 2026-02-18T21:55:41Z

src/wp-admin/includes/comment.php

 	$post_id_in    = "'" . implode( "', '", $post_id_array ) . "'";

-	$pending = $wpdb->get_results( "SELECT comment_post_ID, COUNT(comment_ID) as num_comments FROM $wpdb->comments WHERE comment_post_ID IN ( $post_id_in ) AND comment_approved = '0' AND comment_type != 'note' GROUP BY comment_post_ID", ARRAY_A );
+	$pending = $wpdb->get_results( "SELECT comment_post_ID, COUNT(comment_ID) as num_comments FROM $wpdb->comments WHERE comment_post_ID IN ( $post_id_in ) AND comment_approved = '0' AND comment_type != 'note' AND comment_type != 'reaction' GROUP BY comment_post_ID", ARRAY_A );


Suggested change

$pending = $wpdb->get_results( "SELECT comment_post_ID, COUNT(comment_ID) as num_comments FROM $wpdb->comments WHERE comment_post_ID IN ( $post_id_in ) AND comment_approved = '0' AND comment_type != 'note' AND comment_type != 'reaction' GROUP BY comment_post_ID", ARRAY_A );

$comment_type_not = implode(

'',

array_map(

fn( $comment_type ) => sprintf( ' AND comment_type != "%s"' ), // TODO: Prepare!???

wp_get_internal_comment_types()

)

);

$pending = $wpdb->get_results( "SELECT comment_post_ID, COUNT(comment_ID) as num_comments FROM $wpdb->comments WHERE comment_post_ID IN ( $post_id_in ) AND comment_approved = '0' $comment_type_not GROUP BY comment_post_ID", ARRAY_A );

westonruter · 2026-02-18T21:55:52Z