REST API: Main-site-only sites endpoint, tighter response and a single user parameter

[spacedmonkey]

Addresses the feedback on WordPress#13055: the sites endpoint should work from the network's main site only, with the "my sites" use case kept narrow and read-only.

Main site only

• Create, update, delete and single-site reads return a 403 from any site other than the main site: rest_cannot_create_not_on_main_site, rest_cannot_edit_not_on_main_site, rest_cannot_delete_not_on_main_site and rest_cannot_view_not_on_main_site.
• Two exceptions work from any site, in the view context only:
  • listing your own sites (user=me or your own ID)
  • a member reading their own site
• embed is no longer exempt for members.

Permissions

• context=edit requires manage_sites on both the collection and single-site routes (rest_forbidden_context). This is checked before the site is looked up, so it doesn't reveal whether a site ID exists.
• Listing another user's sites requires manage_sites (rest_forbidden_user).
• Without manage_sites, filtering or ordering by fields outside the view context is rejected (rest_forbidden_param). Those fields are archived, mature, spam, deleted, lang_id, lang_id_exclude, before, after, and orderby=registered|last_updated.

Response and schema

• These fields are now edit context only: registered, registered_gmt, last_updated, last_updated_gmt, archived, mature, spam, deleted, lang_id, post_count and the registered site meta, which may hold sensitive data.
• New read-only admin_url field, built with get_admin_url().
• home and siteurl now come from get_home_url() and get_site_url(), so the home_url and site_url filters apply.
• The write-only title duplicated blogname, since wp_initialize_site() stores the title as blogname. It's gone: blogname is now writable when a site is created and ignored on update. Backslashes are kept.
• A POST to /sites/{id} is an update, so it no longer runs the create-only path.

A single user parameter

• The collection filter user and the create-only user_id are now one user parameter. It is validated to accept a positive user ID or "me", and get_user_id_from_param() resolves "me" to the current user.
• Invalid values (xyz, 0, -1, an empty string, a list) are rejected with rest_invalid_param.
• An unknown administrator on create returns rest_user_invalid_id.

Other changes

• When the user filter matches no sites, get_items skips both site queries and still fires rest_site_query, so a plugin can widen the result.

Testing

• npm run test:php -- -c tests/phpunit/multisite.xml --filter 'WP_Test_REST_Sites_Controller|WP_Test_REST_Site_Meta_Fields': 254 tests pass.
• The single-site sites tests pass. The multisite restapi group only fails Test_oEmbed_Controller::test_proxy_with_classic_embed_provider, which also fails without these changes.
• composer lint and composer phpstan are clean.
• tests/qunit/fixtures/wp-api-generated.js is regenerated for the changed args.

🤖 Generated with Claude Code

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

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