Comments: Allow Notes @mention attributes in comment content (kses)

[adamsilverstein]

Backports the mention kses allowance from the Gutenberg Notes @mention work:

• WordPress/gutenberg#79604 and
• WordPress/gutenberg#80221 (both merged).

The notification layer (from the still-open WordPress/gutenberg#79606) has been split out to #12548 with its own Trac ticket, so this PR can land as soon as it is reviewed without waiting on the upstream notification work.

What

Allows the note mention markup (a class attribute on links) in comment content, scoped to note comments only:

• _wp_kses_allow_note_mention_attributes() (new, private) extends the pre_comment_content allowlist with class on a elements.
• wp_filter_comment() attaches it immediately before applying the pre_comment_content filter and removes it immediately after, and only when $commentdata['comment_type'] is note.

The pre_comment_content kses context itself is unchanged: wp_kses_allowed_html( 'pre_comment_content' ) still returns the default $allowedtags, and regular (including anonymous front-end) comments are sanitized exactly as before.

Because the scoping lives inside wp_filter_comment() - the single choke point both REST write paths pass through with comment_type already resolved - core does not need the separate REST-create arming fix the plugin shim required (WordPress/gutenberg#80221).

Why

The Notes @mention completer stores a mention as a link to the mentioned user's author page, <a class="wp-note-mention user-N" href="…">@Name</a>, the user-N class carrying the mentioned user's ID. The default comment kses allowlist ($allowedtags) permits a with only href and title, so for users without unfiltered_html the mention classes are stripped when the note is saved.

An earlier revision added the attributes to the pre_comment_content context unconditionally. That loosened sanitization for every comment on every site: class is a CSS/JS selector hook, so any commenter - including anonymous visitors - could publish text styled by theme classes (e.g. disguised as a button) or reachable by delegated script handlers. Scoping the allowance to the moment a note comment passes through wp_filter_comment() avoids that: notes can only be written by logged-in users with edit_post on the target post and never render on the front end.

Testing

Unit tests in tests/phpunit/tests/kses.php:

• test_wp_kses_allowed_html_pre_comment_content_disallows_mention_attributes verifies the pre_comment_content context still returns the stock $allowedtags.
• test_note_mention_markup_survives_note_content_sanitization verifies the mention class survives on a note.
• test_note_mention_allows_only_class_on_note_links verifies every attribute other than class and the default link attributes (e.g. onclick, style, data-*) is still stripped from note links.
• test_note_mention_markup_stripped_from_regular_comment_content verifies the class is stripped from the same markup in a regular comment.
• test_note_mention_allowance_does_not_leak_after_note_filtering verifies a regular comment filtered after a note gets the default rules and the allowlist is restored.

npm run test:php -- --filter test_note_mention

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

---

Proposed commit message

Comments: Allow note mention attributes in comment content.

The Notes @mention completer stores a mention as a link to the mentioned
user's author page, `<a class="wp-note-mention user-N" href="…">@Name</a>`,
with the `user-N` class token carrying the mentioned user's ID. The default
comment kses allowlist permits `a` with only `href` and `title`, so for
users without the `unfiltered_html` capability the mention classes are
stripped when the note is saved and the mention degrades to a plain link.

Scope the mention `class` allowance to `note` comments as they pass through
`wp_filter_comment()`, armed immediately before the `pre_comment_content`
filter runs and removed immediately after, so regular comments - including
anonymous front-end comments - are sanitized exactly as before.

See related Gutenberg pull requests: https://github.com/WordPress/gutenberg/pull/79604 and https://github.com/WordPress/gutenberg/pull/80221.

Props mamaduka.
Fixes #65622.

[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.

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

Props adamsilverstein, mamaduka.

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

[github-actions]

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.

[Mamaduka]

Sorry, only have time for a surface review.

• Not sure if we need new methods like wp_get_note_thread_root_id. Values can be easily derived.
• The follower notifications seem like work for a separate PR. I don't think it should be in scope for mention notifications.

I think the general API for managing email (or other) notifications would be better for the project than handling each case individually.

[adamsilverstein]

Sorry, only have time for a surface review.

• Not sure if we need new methods like wp_get_note_thread_root_id. Values can be easily derived.
• The follower notifications seem like work for a separate PR. I don't think it should be in scope for mention notifications.

I think the general API for managing email (or other) notifications would be better for the project than handling each case individually.

Reducing this to the kses only changes which matches the merged PRs. Opening a follow up for the notifications part to dig deeper.

[adamsilverstein]

Follow up: #12548