[robelsust]

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

Description

WP_REST_Server currently defines HTTP method sets as comma-separated string constants:

• READABLE = 'GET'
• CREATABLE = 'POST'
• EDITABLE = 'POST, PUT, PATCH'
• DELETABLE = 'DELETE'
• ALLMETHODS = 'GET, POST, PUT, PATCH, DELETE'

Because three of these happen to contain a single method, extensive ecosystem code (including WooCommerce, Elementor, and Jetpack) performs strict or loose equality checks such as $request->get_method() === WP_REST_Server::READABLE or passes the constant directly to outbound HTTP requests. Consequently, these constants are effectively frozen and cannot gain new HTTP methods (such as RFC 10008 HTTP QUERY method from #65616) without breaking existing routes across the ecosystem.

This PR addresses the issue by introducing dedicated static accessor methods on WP_REST_Server that return sets of methods as string[]:

• WP_REST_Server::get_readable_methods() -> array( 'GET' )
• WP_REST_Server::get_creatable_methods() -> array( 'POST' )
• WP_REST_Server::get_editable_methods() -> array( 'POST', 'PUT', 'PATCH' )
• WP_REST_Server::get_deletable_methods() -> array( 'DELETE' )

Returning arrays establishes the correct type semantics (a set of HTTP methods is a list, preventing incorrect string equality checks like ===), allows the method sets to safely expand in future WordPress versions, and seamlessly integrates with register_rest_route(), which already natively accepts arrays of methods.

The legacy constants are soft-deprecated via @deprecated 7.3.0 docblocks without triggering runtime notices, keeping existing plugins 100% functional.

Changes

1. Added static methods get_readable_methods(), get_creatable_methods(), get_editable_methods(), and get_deletable_methods() to WP_REST_Server.
2. Added @deprecated 7.3.0 tags to READABLE, CREATABLE, EDITABLE, DELETABLE, and ALLMETHODS.
3. Added dedicated unit tests covering method return values, constant equivalence, route registration, and request dispatching in tests/phpunit/tests/rest-api/wpRestServerGetMethods.php.

Testing Instructions

1. Run the dedicated unit test suite:

   vendor/bin/phpunit tests/phpunit/tests/rest-api/wpRestServerGetMethods.php

2. Verify route registration with the new methods:

   register_rest_route( 'my-plugin/v1', '/items', array(
       array(
           'methods'             => WP_REST_Server::get_readable_methods(),
           'callback'            => 'my_plugin_get_items',
           'permission_callback' => '__return_true',
       ),
   ) );

3. Run PHPCS to ensure compliance:

   vendor/bin/phpcs src/wp-includes/rest-api/class-wp-rest-server.php tests/phpunit/tests/rest-api/wpRestServerGetMethods.php

Attribution

Props @moonmeister, @westonruter, @therssoftware.

---

AI Usage Disclosure:
Assisted by generative AI (Antigravity) to prepare the implementation, DocBlocks, and PHPUnit test suite in accordance with WordPress coding guidelines. All code and test coverage were reviewed and verified.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs.

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.

---

Props Bot commands

You can trigger Props Bot actions by commenting on this PR:

• @propsbot add <username> to give props to a GitHub user. Requires write access.
• @propsbot remove <username> to leave a user out of the props. Requires write access.
• @propsbot refresh to refresh this list. Adding the props-bot label works too.

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