[robelsust]

This PR implements Phase 1 of retiring legacy pingback and trackback endpoints by disabling them by default on fresh installations.

Following the successful commit of changeset [62417] (Trac #64837), which disabled incoming and outgoing pings for non-production environments (local, development, staging), this change addresses production fresh installs by updating default site options in populate_options():

• 'default_ping_status' changes from 'open' to 'closed'.
• 'default_pingback_flag' changes from 1 to 0.

Why this is necessary in 2026:

1. DDoS Amplification Vector: XML-RPC pingback.ping has been used for over a decade by botnets as an amplification reflection vector against external targets.
2. Server-Side Request Forgery (SSRF): Outgoing ping discovery triggers arbitrary outbound HTTP GET requests from the web server upon publishing posts, posing SSRF and internal port scanning risks (Trac #57363).
3. Comment Spam Mitigation: Disabling pingbacks by default stops automated trackback/pingback comment spam on newly provisioned sites.
4. Publishing / Cron Performance: Eliminates synchronous external network discovery during cron do_pings when posts contain external links.
5. Obsolescence: Pingbacks and Trackbacks have been widely superseded by modern Indieweb protocols (such as Webmentions, Trac #35435) and social syndication.

---

Backward Compatibility Guarantee (Phased Rollout)

• Existing Sites are 100% Untouched: In populate_options(), WordPress queries existing options before insertion and skips any option already present in the database. Upgrading existing sites to WordPress 7.2 will not alter their current default_ping_status or default_pingback_flag values.
• Opt-In Available Anytime: Site owners who wish to use pingbacks can easily enable them via Settings → Discussion by checking "Attempt to notify any blogs linked to from the post" and "Allow link notifications from other blogs (pingbacks and trackbacks) on new posts".
• Permalink Detection Intact: In upgrade.php, wp_install_maybe_enable_pretty_permalinks() relies on the X-Pingback header from the sample "Hello world!" post. Because wp_install_defaults() inserts the sample post directly into $wpdb->posts without specifying ping_status, the column default ensures rewrite detection continues working seamlessly during installation.

---

Changes Included:

1. src/wp-admin/includes/schema.php:
   • Updated 'default_ping_status' => 'closed' (was 'open').
   • Updated 'default_pingback_flag' => 0 (was 1).
2. tests/phpunit/tests/comment/pingsOpen.php:
   • Updated test_post_exist_status_open() to explicitly pass array( 'ping_status' => 'open' ) when creating the post, ensuring test symmetry with test_post_exist_status_closed().
3. tests/phpunit/tests/comment/defaultPingStatus.php:
   • Dedicated unit test suite with 9 tests covering:
     • Default option values on fresh installs ('closed' and 0).
     • Post creation defaulting to ping_status = 'closed' and pings_open() = false.
     • Explicit 'ping_status' => 'open' overrides.
     • get_default_comment_status() parity for pingback, trackback, and comment.
     • Option modification in Discussion settings propagating to post creation.
     • _publish_post_hook() suppressing _pingme postmeta when the flag is 0.
     • _publish_post_hook() adding _pingme postmeta when the flag is 1.
     • populate_options() preservation of existing site options during upgrades.

---

Testing & Verification:

• vendor/bin/phpcs src/wp-admin/includes/schema.php tests/phpunit/tests/comment/defaultPingStatus.php tests/phpunit/tests/comment/pingsOpen.php: 3 / 3 (100%), 0 errors, 0 warnings.
• vendor/bin/phpunit tests/phpunit/tests/comment/defaultPingStatus.php: 9 tests, 16 assertions, 100% pass.
• vendor/bin/phpunit tests/phpunit/tests/comment/pingsOpen.php: 3 tests, 3 assertions, 100% pass.
• vendor/bin/phpunit tests/phpunit/tests/comment/disablePingsForEnvironment.php: 17 tests, 21 assertions, 100% pass.
• vendor/bin/phpunit tests/phpunit/tests/comment/pingback.php: 4 tests, 6 assertions, 100% pass.
• vendor/bin/phpunit tests/phpunit/tests/option/sanitizeOption.php: 65 tests, 80 assertions, 100% pass.

Trac ticket: https://core.trac.wordpress.org/ticket/38207
See also: https://core.trac.wordpress.org/ticket/64837, https://core.trac.wordpress.org/ticket/56362

---

Use of AI Tools

AI assistance: Yes
Tool(s): Antigravity
Model(s): Gemini
Used for: Identifying the schema default options, investigating backward-compatibility constraints in populate_options(), reviewing core permalink dependencies in wp_install_maybe_enable_pretty_permalinks(), drafting the default option changes and dedicated unit tests in defaultPingStatus.php. All code changes, schema modifications, and test suite executions were reviewed and verified locally by robelsust.

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

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

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.