Scheduled Updates abilities: register schedule CRUD + run-now via Registrar#48738
Scheduled Updates abilities: register schedule CRUD + run-now via Registrar#48738enejb wants to merge 1 commit into
Conversation
|
Are you an Automattician? Please test your changes on all WordPress.com environments to help mitigate accidental explosions.
Interested in more tips and information?
|
|
Thank you for your PR! When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:
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: 🔴 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: Follow this PR Review Process:
If you have questions about anything, reach out in #jetpack-developers for guidance! |
Code Coverage Summary1 file is newly checked for coverage.
|
Summary
Registers Jetpack Scheduled Updates abilities with the WordPress Abilities API so AI agents can manage plugin update schedules through the standard
wp-abilities/v1REST surface. Implements RSM "Abilities Everywhere" plan §4.2 for the scheduled-updates package.Abilities
All slugs are namespaced under the new
jetpack-scheduled-updatescategory. All five share the same permission gate (current_user_can( 'update_plugins' )), mirroringWPCOM_REST_API_V2_Endpoint_Update_Schedules.jetpack-scheduled-updates/list-schedules{ id, plugins, schedule, last_run_status, last_run_timestamp, active }shape. Supports an optionalidfilter; unknown ids return an empty array (never aWP_Error).jetpack-scheduled-updates/create-schedule{ id, schedule }. Idempotent only at the id level (same plugin list collides).jetpack-scheduled-updates/update-schedule{ id, changed, changed_fields }; replaying with the same values returnschanged=falsewith an emptychanged_fields.jetpack-scheduled-updates/delete-schedule{ id, deleted, changed }; deleting an already-gone schedule returnsdeleted=true, changed=false.jetpack-scheduled-updates/run-schedule-nowwp_schedule_single_event()a few seconds out — the recurring cadence is unaffected. Re-running queues another run.Cross-consumer wiring
The scheduled-updates package is consumed by
jetpack-mu-wpcomand (indirectly) by the main Jetpack plugin. Wired via a newprojects/packages/scheduled-updates/actions.phpregistered in composer'sautoload.files. The file uses the canonical guarded pattern fromprojects/packages/publicize/actions.phpso it stays safe when autoloaded beforeadd_action()is available, and double-checks thejetpack_wp_abilities_enabledfilter before touching the registrar class.Why this shape
The abilities go through
rest_do_request()for create/update/delete so they reuse the full WPCOMupdate-schedulescontroller pipeline (schema validation,is_plugin_installedchecks, sync option write, firedjetpack_scheduled_update_{created,updated,deleted}actions) exactly as a public REST caller would.run-schedule-nowqueues a one-off cron event directly because the REST surface has no equivalent.Test plan
composer phpunit -- --filter Scheduled_Updates_Abilities_Test(29 tests, 123 assertions, all passing)composer phpunit(92 tests, 511 assertions, all passing)jetpack_wp_abilities_enabledfilter is opened on a test site