Sitemaps abilities: register status reads + rebuild dispatch via Registrar

[enejb]

Implements the Sitemaps module slice of the Abilities Everywhere plan (§3.3).

Summary

• Adds Sitemaps_Abilities (Registrar subclass) under modules/sitemaps/abilities/, wired from the bottom of modules/sitemaps.php so it only registers while the Sitemaps module is active.
• Registers two abilities under category jetpack-sitemaps:
  • jetpack-sitemaps/get-status — zero-arg read returning { active, url, post_count, page_count, news_sitemap_enabled, sitemaps }. sitemaps is the child-sitemap list actually present in the served sitemap.xml index — each entry { loc, lastmod }, parsed from the stored master sitemap (no HTTP loopback), empty until a master sitemap exists. Gated on edit_posts (content managers can inspect sitemap state). Annotated readonly + idempotent.
  • jetpack-sitemaps/request-rebuild — zero-arg dispatch returning { dispatched, status, next_scheduled_at } with status in queued / running / already_running. Gated on manage_options (admin only). Annotated non-readonly + idempotent: returns dispatched=false + status=running when the jetpack-sitemap-state-lock transient is set (build in flight), dispatched=false + status=queued when a cron tick is already scheduled, and otherwise schedules a single-event jp_sitemap_cron_hook tick and returns dispatched=true. next_scheduled_at is the next jp_sitemap_cron_hook tick as an ISO 8601 UTC string with an explicit Z zone designator, e.g. 2026-05-19T19:33:20Z (or null when nothing is scheduled, e.g. status=running with no future tick) so callers learn when the queued/pending build will run without a follow-up status read.
• get-status deliberately omits a synthetic "last build" scalar. It was previously derived from the jetpack-sitemap-state option's max[master].lastmod projection, which reads its initial/reset shape (no max) even while a fully-built sitemap.xml is being served — so it reported null for sites that demonstrably have a working sitemap. Instead the ability surfaces the real per-child lastmod values straight from the served master document. The redundant master_sitemap_url (a duplicate of url) and the always-null reserved last_error were also dropped.
• Test coverage in tests/php/src/Sitemaps_Abilities_Test.php mirrors Monitor_Abilities_Test: abstract getters, Registrar wiring (gate filter, per-ability allow-list, category auto-injection), permission callbacks (admin/editor/subscriber/anonymous matrix), get_status happy path + module-off + news-filter, get_sitemap_entries parsing (sitemapindex → entries, empty/malformed XML, missing-lastmod tolerance), request_rebuild three-state dispatch + idempotency + next_scheduled_at derivation, and the gated-registration contract when the module is inactive. set_up() mirrors tear_down()'s cron/transient/option cleanup so request_rebuild cron assertions are isolated regardless of run order.
• A Sitemaps_Abilities_Test_Stub test double overrides the protected seams (get_master_sitemap_url, get_master_sitemap_xml, count_published) so success-path tests run the real get_sitemap_entries parser against a known document without a librarian / permalink stack / wp_count_posts factory.

⚠️ Registration gate: blog_public must be 1

These abilities are wired from the bottom of modules/sitemaps/sitemaps.php, which modules/sitemaps.php only includes when get_option( 'blog_public' ) === '1':

if ( '1' == get_option( 'blog_public' ) ) {
	include_once __DIR__ . '/sitemaps/sitemaps.php';
}

So the effective gate is Sitemaps module active and blog_public = 1, not the module flag alone. On sites with "Discourage search engines from indexing this site" enabled (blog_public = 0, the default on most local/dev environments) the entire sitemaps codebase — including this registrar — is skipped, and jetpack-sitemaps/* will be absent from wp_get_abilities() / the REST surface even though wp jetpack module list reports the module as Active. This is the module's pre-existing "no sitemaps on private sites" behavior, inherited intentionally; surfaced here because it is the most likely reason the abilities appear "not loading" during local testing.

Test plan

Abilities run via POST /wp-json/wp-abilities/v1/abilities/<name>/run with a JSON body {"input": {}} (the run controller reads input from the input key; an empty/bare body yields 400 ability_invalid_input).

• CI green: PHPUnit (PHP 7.2 → 8.4), PHPCS, Phan.
• Prerequisite for the on-site checks below: wp option update blog_public 1 (otherwise modules/sitemaps.php skips loading the sitemap code entirely and no jetpack-sitemaps/* abilities register, regardless of module status).
• On a site with the Sitemaps module off, GET /wp-json/wp-abilities/v1/abilities does not list any jetpack-sitemaps/* entries.
• On a site with the Sitemaps module on and blog_public = 1:
  • POST /wp-json/wp-abilities/v1/abilities/jetpack-sitemaps/get-status/run (body {"input":{}}) as an editor returns { active, url, post_count, page_count, news_sitemap_enabled, sitemaps } with active=true. When a master sitemap exists, sitemaps lists each child { loc, lastmod } matching the served sitemap.xml; before any build it is [].
  • As a subscriber the same call returns 403 rest_ability_cannot_execute; as an anonymous user, 401.
  • POST /wp-json/wp-abilities/v1/abilities/jetpack-sitemaps/request-rebuild/run as admin, with nothing running/queued, returns dispatched=true, status=queued, and next_scheduled_at ≈ now (ISO 8601 UTC, e.g. 2026-05-19T19:33:20Z). A second immediate call returns dispatched=false, status=queued, same next_scheduled_at (no duplicate cron tick).
  • With the jetpack-sitemap-state-lock transient set (and no pending tick), the same call returns dispatched=false, status=running, next_scheduled_at=null.
• With the Sitemaps module on but blog_public = 0, confirm jetpack-sitemaps/* abilities are absent (documents the inherited gate).

[github-actions]

Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.

• To test on WoA, go to the Plugins menu on a WoA dev site. Click on the "Upload" button and follow the upgrade flow to be able to upload, install, and activate the Jetpack Beta plugin. Once the plugin is active, go to Jetpack > Jetpack Beta, select your plugin (Jetpack), and enable the add/ship-sitemaps-abilities branch.
• To test on Simple, run the following command on your sandbox:

bin/jetpack-downloader test jetpack add/ship-sitemaps-abilities

Interested in more tips and information?

• In your local development environment, use the jetpack rsync command to sync your changes to a WoA dev blog.
• Read more about our development workflow here: PCYsg-eg0-p2
• Figure out when your changes will be shipped to customers here: PCYsg-eg5-p2

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Review, ...).
  
• 🔴 Add testing instructions.
  
• 🔴 Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

🔴 Action required: Please include detailed testing steps, explaining how to test your change, like so:

## Testing instructions:

* Go to '..'
*

---

🔴 Action required: We would recommend that you add a section to the PR description to specify whether this PR includes any changes to data or privacy, like so:

## Does this pull request change what data or activity we track or use?

My PR adds *x* and *y*.

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Make sure to test your changes on all platforms that it applies to. You're responsible for the quality of the code you ship.
3. You can use GitHub's Reviewers functionality to request a review.
4. When it's reviewed and merged, you will be pinged in Slack to deploy the changes to WordPress.com simple once the build is done.

If you have questions about anything, reach out in #jetpack-developers for guidance!

---

Jetpack plugin:

The Jetpack plugin has different release cadences depending on the platform:

• WordPress.com Simple releases happen as soon as you deploy your changes after merging this PR (PCYsg-Jjm-p2).
• WoA releases happen weekly.
• Releases to self-hosted sites happen monthly:
  • Scheduled release: June 2, 2026
  • Code freeze: June 1, 2026

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[jp-launch-control]

Code Coverage Summary

Coverage changed in 1 file.

File	Coverage	Δ%	Δ Uncovered
projects/plugins/jetpack/modules/sitemaps/sitemaps.php	76/222 (34.23%)	-0.31%	2 ❤️‍🩹

1 file is newly checked for coverage.

File	Coverage
projects/plugins/jetpack/modules/sitemaps/abilities/class-sitemaps-abilities.php	132/151 (87.42%) 💚

Full summary · PHP report · JS report