Auto-approve self pingbacks

[annezazu]

This came up from @matt: self-pingbacks should auto-approve. Unclear whether this should be a setting or something that automatically happens as I'm not sure of the broader use cases where folks might not want this.

[desrosj]

Related: #24241.

Pingbacks and trackbacks carry no email address, so they can never satisfy the comment_previously_approved option in check_comment() — they always fall through to return false. Since that option is enabled by default, every ping is held for moderation indefinitely, including the ones a site sends to itself when a new post links to an older one.

Today the only way to stop moderating self-pings is to disable comment_previously_approved entirely, which also auto-approves pings from every other site.

## Changes

• Adds wp_is_self_ping( $url, $comment_type ), which reports whether a ping's source URL resolves to a published post on this site. It gates on the comment type first, so regular comments don't pay for the post lookup.
• Uses it in check_comment(), in the branch where pings currently fall through, so self-pings are no longer held.
• Adds a wp_is_self_ping filter for sites that would rather keep moderating them.

A few deliberate choices:

• Host matching is delegated to url_to_postid(), which compares parsed hostnames and returns 0 for foreign URLs. A URL that merely *contains* the home URL (http://example.com/?ref=https://mysite.com/a-post/) is not treated as local. There's a test for this.
• The check runs after the existing gates, not before them. "Comment must be manually approved", moderation keywords, and the maximum link count all still take precedence. Placing it in check_comment() rather than wp_check_comment_data() is what preserves that ordering.
• The source post must be published. A draft or private post that happens to resolve is not trusted.
• Both pingback and trackback are covered, matching the scope of the related #24241.

## Notes for reviewers

The ticket asks an open question — setting or automatic? — and this is the automatic version, with a filter instead of a new option. Related: #24241, where the counter-position is argued (some site owners delete all self-pings and would prefer to reject them outright). If a setting is preferred, this is the logic that would sit behind it.

One thing deliberately left out, worth a decision: on a multi-author site, any published post can currently trigger an auto-approved self-ping, so a Contributor-level author's post title can land as an approved comment on someone else's post. Restricting approval to source posts whose author is the target's author or can moderate_comments would close that, reusing the trust rule already a few lines above in wp_check_comment_data(). Happy to add it if reviewers want it in core rather than left to the filter.

## Testing

Verified end to end by driving the real pingback.ping XML-RPC handler with a mocked source fetch and reading the resulting comment, with stock settings (comment_previously_approved = '1'):

	before	after
self-ping	comment_approved = '0'	comment_approved = '1'
ping from another site	comment_approved = '0'	comment_approved = '0'

Automated coverage added:

• tests/phpunit/tests/comment/checkComment.php — self-ping approved (pingback and trackback), external ping held, spoofed URL held, comment_moderation still wins, unpublished source held, a regular comment with a local author URL still held, and the filter switching it off.
• tests/phpunit/tests/comment/wpAllowComment.php — the resulting approval status is 1 for a self-ping and 0 for an external ping.

npm run test:php -- --group comment    # 608 tests, 1496 assertions
npm run test:php -- --group xmlrpc     # 318 tests, 1246 assertions

phpcs reports no new issues on the changed files.

To reproduce manually, note that pings are disabled outside production environments as of 7.1 (wp_should_disable_pings_for_environment()), so a local install needs that filtered off first.

## Use of AI Tools

AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: Research, implementation, and tests; reviewed and edited by me.

[youknowriad]

In 63036:

Pings/Trackbacks: Auto-approve pingbacks and trackbacks from the same site.

Pings carry no email address, so they never satisfy the
comment_previously_approved option, which is enabled by default. Every ping
is held for moderation indefinitely as a result, including the ones a site
sends to itself when a new post links to an older one.

Approve a ping whose source URL resolves to a published post on this site.
Existing moderation checks still take precedence, and the new
auto_approve_ping filter controls the decision.

Props annezazu, avcascade, chriscct7, desrosj, dshanske, eurello, matt,
mohkatz, SergeyBiryukov, stevegrunwell.
Fixes #65016.

[sabernhardt]

@youknowriad Did you intend to commit [63036] toward 7.2?

The separate 7.1 branch has not been created yet, so any commit to trunk needs ​double sign-off, and it is too late for enhancement tickets.

The new filter should have a dev note too, and the 7.1 field guide is already published.

[jorbin]

It's too late for this to land in 7.1 and this did not have double sign-off. While I think it could be a valuable addition to core, this is not the point in the release cycle for it.

After chatting with @annezazu, I'm going to revert it so that it can be re-added after branching and get tested (and documented as @sabernhardt notes) during the 7.2 cycle.

[annezazu]

Hey folks. I was missing context and apologize for the back and forth. This was intended for 7.1 and came from Matt. Let's land this for 7.1. Can folks give this a review retroactively and ensure there's not something else we're missing that needs to be modified for it to land? For example, this piece:

"One thing deliberately left out, worth a decision: on a multi-author site, any published post can currently trigger an auto-approved self-ping, so a Contributor-level author's post title can land as an approved comment on someone else's post."

[griffbrad]

This definitely addresses a long-standing annoyance, so I appreciate the contribution. It's late in the cycle but not a particularly high-risk change from what I can see and is well-covered by automated tests. 👍

[youknowriad]

This was an urgent request to land. I did miss that 7.1 branch was not created yet (kind of surprised by that since beta for 7.1 happened a long time ago), but let's ship this in 7.1 in that case.

[sabernhardt]

The documentation says 7.2.0. Adding the change to the 7.1 milestone should require a follow-up commit (with double sign-off).

Also, #24241 is still open. If the PR does not complete both tickets, it might not be ready yet.

Makes a few updates:

• Version annotations to 7.1.0
• Clarifies "this site" means "the same site" in various docs.
• Prefixes the new filter with wp_.
• Extends the tests:
  • adds test to ensure MS sub-site posts are not auto approved
  • adds test to ensure that post ID sent to filter is zero for external sites.
  • adds docs for each test

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

## Use of AI Tools

I'm also curious whether url_to_postid() is good enough or if some additional checks could help. And whether there's a better spot for the filter in general. I'll have a better opinion to share tomorrow :)

I _really_ want there to be something better than url_to_postid(), but it generally covers all the scenarios. I think, if anything, there may be a bug report or two against that function available to be made, but nothing blocking this.

@youknowriad @jeremyfelt can either of you think of other tests that it would be wise to include? Especially for multisite installs.

I want to confirm if this PR is ready to be committed, as tomorrow is the final RC release. It seems that at least the old wp_auto_approve_pingback in the Docblock needs to be updated.

Just to confirm, does this PR address the concerns raised by @sabernhardt?

https://core.trac.wordpress.org/ticket/65016#comment:9