Abilities API: Allow registration after init

[chubes4]

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

What

Allows Abilities API registration through wp_register_ability() and wp_register_ability_category() after the init action has fired.

The wp_abilities_api_init and wp_abilities_api_categories_init hooks remain the recommended deterministic registration points. Callers registering afterward are responsible for doing so before relevant discovery, snapshot, or use. The public wrappers continue to reject genuinely too-early registration before init.

Why

The public wrapper currently treats the Abilities API action as the only valid registration window, even though the underlying registry supports later registration. This makes registration timing stricter than other WordPress registration APIs and pushes consumers that load later toward direct registry calls.

This timing contract was explicitly debated during the original Core merge:

• Aaron Jorbin noted that registration problems are commonly caused by registering too early rather than too late, and recommended did_action() unless a concrete reason required doing_action(): Abilities API: Implement server-side registry with REST API endpoints #9410 (comment)
• The original merge used did_action(), allowing registration after initialization.
• A follow-up deliberately changed the check to doing_action() based on concerns that arbitrary timing might cause less obvious downstream problems: Abilities API: Use stricter doing_action check when registering #10452

This PR revisits that trade-off. It does not claim that downstream consumers are unable to attach registration callbacks earlier. Instead, it follows the block-registration model: provide a recommended deterministic hook while allowing extenders to register later when they do so before the relevant consumer runs.

Existing implementations have independently added post-hook registration paths through the registry:

• Data Machine: https://github.com/Extra-Chill/data-machine/blob/main/inc/Abilities/AgentAbilities.php#L62-L82
• Agents API: https://github.com/Automattic/agents-api/blob/main/src/Runtime/register-runtime-package-run-ability.php#L149-L165
• Static Site Importer: https://github.com/Automattic/static-site-importer/blob/main/includes/abilities.php#L420-L429

Core also permits wp_unregister_ability() and wp_unregister_ability_category() at any time after registration, so completion of the registration hooks does not make the registry immutable: https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/abilities-api.php#L301-L330

Compatibility

This changes the public registration lifecycle. Code registering on the recommended Abilities API hooks continues to work unchanged, and registration before init remains rejected. Code that inspects or snapshots abilities must still run after the registrations it expects to observe.

Tests

Adds coverage that:

• abilities can be registered after wp_abilities_api_init and remain discoverable via wp_has_ability(), wp_get_ability(), and wp_get_abilities();
• ability categories can be registered after wp_abilities_api_categories_init;
• pre-init registration still fails with _doing_it_wrong().

How to test

1. Run npm install.
2. Run npm run env:start.
3. Run npm run test:php -- --group abilities-api.
4. Confirm the Abilities API test group passes, including post-init ability and category registration and pre-init rejection.
5. Run npm run env:stop.

Local verification:

• php -l src/wp-includes/abilities-api.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbility.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• vendor/bin/phpcs --standard=phpcs.xml.dist src/wp-includes/abilities-api.php tests/phpunit/tests/abilities-api/wpRegisterAbility.php tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• git diff --check

Focused PHPUnit was not run locally because this checkout does not have wp-tests-config.php configured. The GitHub test matrix exercises the affected suites.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode via Homeboy
• Model(s): OpenAI GPT 5.5 (initial patch), openai/gpt-5.6-terra (lifecycle review revision)
• Used for: Drafted the implementation, tests, documentation revision, and PR text from the public Core discussions and source-code investigation; the submitter reviewed and remains responsible for the change.

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

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.

[gziolo]

Closing together with https://core.trac.wordpress.org/ticket/65583.

[chubes4]

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

What

Allows Abilities API registration through wp_register_ability() and wp_register_ability_category() after the init action has fired.

The wp_abilities_api_init and wp_abilities_api_categories_init hooks remain the recommended deterministic registration points. Callers registering afterward are responsible for doing so before relevant discovery, snapshot, or use. The public wrappers continue to reject genuinely too-early registration before init.

Why

The public wrapper currently treats the Abilities API action as the only valid registration window, even though the underlying registry supports later registration. This makes registration timing stricter than other WordPress registration APIs and pushes consumers that load later toward direct registry calls.

This timing contract was explicitly debated during the original Core merge:

• Aaron Jorbin noted that registration problems are commonly caused by registering too early rather than too late, and recommended did_action() unless a concrete reason required doing_action(): Abilities API: Implement server-side registry with REST API endpoints #9410 (comment)
• The original merge used did_action(), allowing registration after initialization.
• A follow-up deliberately changed the check to doing_action() based on concerns that arbitrary timing might cause less obvious downstream problems: Abilities API: Use stricter doing_action check when registering #10452

This PR revisits that trade-off. It does not claim that downstream consumers are unable to attach registration callbacks earlier. Instead, it follows the block-registration model: provide a recommended deterministic hook while allowing extenders to register later when they do so before the relevant consumer runs.

Existing implementations have independently added post-hook registration paths through the registry:

• Data Machine: https://github.com/Extra-Chill/data-machine/blob/main/inc/Abilities/AgentAbilities.php#L62-L82
• Agents API: https://github.com/Automattic/agents-api/blob/main/src/Runtime/register-runtime-package-run-ability.php#L149-L165
• Static Site Importer: https://github.com/Automattic/static-site-importer/blob/main/includes/abilities.php#L420-L429

Core also permits wp_unregister_ability() and wp_unregister_ability_category() at any time after registration, so completion of the registration hooks does not make the registry immutable: https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/abilities-api.php#L301-L330

Compatibility

This changes the public registration lifecycle. Code registering on the recommended Abilities API hooks continues to work unchanged, and registration before init remains rejected. Code that inspects or snapshots abilities must still run after the registrations it expects to observe.

Tests

Adds coverage that:

• abilities can be registered after wp_abilities_api_init and remain discoverable via wp_has_ability(), wp_get_ability(), and wp_get_abilities();
• ability categories can be registered after wp_abilities_api_categories_init;
• pre-init registration still fails with _doing_it_wrong().

How to test

1. Run npm install.
2. Run npm run env:start.
3. Run npm run test:php -- --group abilities-api.
4. Confirm the Abilities API test group passes, including post-init ability and category registration and pre-init rejection.
5. Run npm run env:stop.

Local verification:

• php -l src/wp-includes/abilities-api.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbility.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• vendor/bin/phpcs --standard=phpcs.xml.dist src/wp-includes/abilities-api.php tests/phpunit/tests/abilities-api/wpRegisterAbility.php tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• git diff --check

Focused PHPUnit was not run locally because this checkout does not have wp-tests-config.php configured. The GitHub test matrix exercises the affected suites.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode via Homeboy
• Model(s): OpenAI GPT 5.5 (initial patch), openai/gpt-5.6-terra (lifecycle review revision)
• Used for: Drafted the implementation, tests, documentation revision, and PR text from the public Core discussions and source-code investigation; the submitter reviewed and remains responsible for the change.

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

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.

[gziolo]

Closing together with https://core.trac.wordpress.org/ticket/65583.

[chubes4]

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

What

Allows Abilities API registration through wp_register_ability() and wp_register_ability_category() after the init action has fired.

The wp_abilities_api_init and wp_abilities_api_categories_init hooks remain the recommended deterministic registration points. Callers registering afterward are responsible for doing so before relevant discovery, snapshot, or use. The public wrappers continue to reject genuinely too-early registration before init.

Why

The public wrapper currently treats the Abilities API action as the only valid registration window, even though the underlying registry supports later registration. This makes registration timing stricter than other WordPress registration APIs and pushes consumers that load later toward direct registry calls.

This timing contract was explicitly debated during the original Core merge:

• Aaron Jorbin noted that registration problems are commonly caused by registering too early rather than too late, and recommended did_action() unless a concrete reason required doing_action(): Abilities API: Implement server-side registry with REST API endpoints #9410 (comment)
• The original merge used did_action(), allowing registration after initialization.
• A follow-up deliberately changed the check to doing_action() based on concerns that arbitrary timing might cause less obvious downstream problems: Abilities API: Use stricter doing_action check when registering #10452

This PR revisits that trade-off. It does not claim that downstream consumers are unable to attach registration callbacks earlier. Instead, it follows the block-registration model: provide a recommended deterministic hook while allowing extenders to register later when they do so before the relevant consumer runs.

Existing implementations have independently added post-hook registration paths through the registry:

• Data Machine: https://github.com/Extra-Chill/data-machine/blob/main/inc/Abilities/AgentAbilities.php#L62-L82
• Agents API: https://github.com/Automattic/agents-api/blob/main/src/Runtime/register-runtime-package-run-ability.php#L149-L165
• Static Site Importer: https://github.com/Automattic/static-site-importer/blob/main/includes/abilities.php#L420-L429

Core also permits wp_unregister_ability() and wp_unregister_ability_category() at any time after registration, so completion of the registration hooks does not make the registry immutable: https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/abilities-api.php#L301-L330

Compatibility

This changes the public registration lifecycle. Code registering on the recommended Abilities API hooks continues to work unchanged, and registration before init remains rejected. Code that inspects or snapshots abilities must still run after the registrations it expects to observe.

Tests

Adds coverage that:

• abilities can be registered after wp_abilities_api_init and remain discoverable via wp_has_ability(), wp_get_ability(), and wp_get_abilities();
• ability categories can be registered after wp_abilities_api_categories_init;
• pre-init registration still fails with _doing_it_wrong().

How to test

1. Run npm install.
2. Run npm run env:start.
3. Run npm run test:php -- --group abilities-api.
4. Confirm the Abilities API test group passes, including post-init ability and category registration and pre-init rejection.
5. Run npm run env:stop.

Local verification:

• php -l src/wp-includes/abilities-api.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbility.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• vendor/bin/phpcs --standard=phpcs.xml.dist src/wp-includes/abilities-api.php tests/phpunit/tests/abilities-api/wpRegisterAbility.php tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• git diff --check

Focused PHPUnit was not run locally because this checkout does not have wp-tests-config.php configured. The GitHub test matrix exercises the affected suites.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode via Homeboy
• Model(s): OpenAI GPT 5.5 (initial patch), openai/gpt-5.6-terra (lifecycle review revision)
• Used for: Drafted the implementation, tests, documentation revision, and PR text from the public Core discussions and source-code investigation; the submitter reviewed and remains responsible for the change.

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

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.

[gziolo]

Closing together with https://core.trac.wordpress.org/ticket/65583.

[chubes4]

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

What

Allows Abilities API registration through wp_register_ability() and wp_register_ability_category() after the init action has fired.

The wp_abilities_api_init and wp_abilities_api_categories_init hooks remain the recommended deterministic registration points. Callers registering afterward are responsible for doing so before relevant discovery, snapshot, or use. The public wrappers continue to reject genuinely too-early registration before init.

Why

The public wrapper currently treats the Abilities API action as the only valid registration window, even though the underlying registry supports later registration. This makes registration timing stricter than other WordPress registration APIs and pushes consumers that load later toward direct registry calls.

This timing contract was explicitly debated during the original Core merge:

• Aaron Jorbin noted that registration problems are commonly caused by registering too early rather than too late, and recommended did_action() unless a concrete reason required doing_action(): Abilities API: Implement server-side registry with REST API endpoints #9410 (comment)
• The original merge used did_action(), allowing registration after initialization.
• A follow-up deliberately changed the check to doing_action() based on concerns that arbitrary timing might cause less obvious downstream problems: Abilities API: Use stricter doing_action check when registering #10452

This PR revisits that trade-off. It does not claim that downstream consumers are unable to attach registration callbacks earlier. Instead, it follows the block-registration model: provide a recommended deterministic hook while allowing extenders to register later when they do so before the relevant consumer runs.

Existing implementations have independently added post-hook registration paths through the registry:

• Data Machine: https://github.com/Extra-Chill/data-machine/blob/main/inc/Abilities/AgentAbilities.php#L62-L82
• Agents API: https://github.com/Automattic/agents-api/blob/main/src/Runtime/register-runtime-package-run-ability.php#L149-L165
• Static Site Importer: https://github.com/Automattic/static-site-importer/blob/main/includes/abilities.php#L420-L429

Core also permits wp_unregister_ability() and wp_unregister_ability_category() at any time after registration, so completion of the registration hooks does not make the registry immutable: https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/abilities-api.php#L301-L330

Compatibility

This changes the public registration lifecycle. Code registering on the recommended Abilities API hooks continues to work unchanged, and registration before init remains rejected. Code that inspects or snapshots abilities must still run after the registrations it expects to observe.

Tests

Adds coverage that:

• abilities can be registered after wp_abilities_api_init and remain discoverable via wp_has_ability(), wp_get_ability(), and wp_get_abilities();
• ability categories can be registered after wp_abilities_api_categories_init;
• pre-init registration still fails with _doing_it_wrong().

How to test

1. Run npm install.
2. Run npm run env:start.
3. Run npm run test:php -- --group abilities-api.
4. Confirm the Abilities API test group passes, including post-init ability and category registration and pre-init rejection.
5. Run npm run env:stop.

Local verification:

• php -l src/wp-includes/abilities-api.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbility.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• vendor/bin/phpcs --standard=phpcs.xml.dist src/wp-includes/abilities-api.php tests/phpunit/tests/abilities-api/wpRegisterAbility.php tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• git diff --check

Focused PHPUnit was not run locally because this checkout does not have wp-tests-config.php configured. The GitHub test matrix exercises the affected suites.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode via Homeboy
• Model(s): OpenAI GPT 5.5 (initial patch), openai/gpt-5.6-terra (lifecycle review revision)
• Used for: Drafted the implementation, tests, documentation revision, and PR text from the public Core discussions and source-code investigation; the submitter reviewed and remains responsible for the change.

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

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.

[gziolo]

Closing together with https://core.trac.wordpress.org/ticket/65583.

[chubes4]

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

What

Allows Abilities API registration through wp_register_ability() and wp_register_ability_category() after the init action has fired.

The wp_abilities_api_init and wp_abilities_api_categories_init hooks remain the recommended deterministic registration points. Callers registering afterward are responsible for doing so before relevant discovery, snapshot, or use. The public wrappers continue to reject genuinely too-early registration before init.

Why

The public wrapper currently treats the Abilities API action as the only valid registration window, even though the underlying registry supports later registration. This makes registration timing stricter than other WordPress registration APIs and pushes consumers that load later toward direct registry calls.

This timing contract was explicitly debated during the original Core merge:

• Aaron Jorbin noted that registration problems are commonly caused by registering too early rather than too late, and recommended did_action() unless a concrete reason required doing_action(): Abilities API: Implement server-side registry with REST API endpoints #9410 (comment)
• The original merge used did_action(), allowing registration after initialization.
• A follow-up deliberately changed the check to doing_action() based on concerns that arbitrary timing might cause less obvious downstream problems: Abilities API: Use stricter doing_action check when registering #10452

This PR revisits that trade-off. It does not claim that downstream consumers are unable to attach registration callbacks earlier. Instead, it follows the block-registration model: provide a recommended deterministic hook while allowing extenders to register later when they do so before the relevant consumer runs.

Existing implementations have independently added post-hook registration paths through the registry:

• Data Machine: https://github.com/Extra-Chill/data-machine/blob/main/inc/Abilities/AgentAbilities.php#L62-L82
• Agents API: https://github.com/Automattic/agents-api/blob/main/src/Runtime/register-runtime-package-run-ability.php#L149-L165
• Static Site Importer: https://github.com/Automattic/static-site-importer/blob/main/includes/abilities.php#L420-L429

Core also permits wp_unregister_ability() and wp_unregister_ability_category() at any time after registration, so completion of the registration hooks does not make the registry immutable: https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/abilities-api.php#L301-L330

Compatibility

This changes the public registration lifecycle. Code registering on the recommended Abilities API hooks continues to work unchanged, and registration before init remains rejected. Code that inspects or snapshots abilities must still run after the registrations it expects to observe.

Tests

Adds coverage that:

• abilities can be registered after wp_abilities_api_init and remain discoverable via wp_has_ability(), wp_get_ability(), and wp_get_abilities();
• ability categories can be registered after wp_abilities_api_categories_init;
• pre-init registration still fails with _doing_it_wrong().

How to test

1. Run npm install.
2. Run npm run env:start.
3. Run npm run test:php -- --group abilities-api.
4. Confirm the Abilities API test group passes, including post-init ability and category registration and pre-init rejection.
5. Run npm run env:stop.

Local verification:

• php -l src/wp-includes/abilities-api.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbility.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• vendor/bin/phpcs --standard=phpcs.xml.dist src/wp-includes/abilities-api.php tests/phpunit/tests/abilities-api/wpRegisterAbility.php tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• git diff --check

Focused PHPUnit was not run locally because this checkout does not have wp-tests-config.php configured. The GitHub test matrix exercises the affected suites.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode via Homeboy
• Model(s): OpenAI GPT 5.5 (initial patch), openai/gpt-5.6-terra (lifecycle review revision)
• Used for: Drafted the implementation, tests, documentation revision, and PR text from the public Core discussions and source-code investigation; the submitter reviewed and remains responsible for the change.

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

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.

[gziolo]

Closing together with https://core.trac.wordpress.org/ticket/65583.

[chubes4]

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

What

Allows Abilities API registration through wp_register_ability() and wp_register_ability_category() after the init action has fired.

The wp_abilities_api_init and wp_abilities_api_categories_init hooks remain the recommended deterministic registration points. Callers registering afterward are responsible for doing so before relevant discovery, snapshot, or use. The public wrappers continue to reject genuinely too-early registration before init.

Why

The public wrapper currently treats the Abilities API action as the only valid registration window, even though the underlying registry supports later registration. This makes registration timing stricter than other WordPress registration APIs and pushes consumers that load later toward direct registry calls.

This timing contract was explicitly debated during the original Core merge:

• Aaron Jorbin noted that registration problems are commonly caused by registering too early rather than too late, and recommended did_action() unless a concrete reason required doing_action(): Abilities API: Implement server-side registry with REST API endpoints #9410 (comment)
• The original merge used did_action(), allowing registration after initialization.
• A follow-up deliberately changed the check to doing_action() based on concerns that arbitrary timing might cause less obvious downstream problems: Abilities API: Use stricter doing_action check when registering #10452

This PR revisits that trade-off. It does not claim that downstream consumers are unable to attach registration callbacks earlier. Instead, it follows the block-registration model: provide a recommended deterministic hook while allowing extenders to register later when they do so before the relevant consumer runs.

Existing implementations have independently added post-hook registration paths through the registry:

• Data Machine: https://github.com/Extra-Chill/data-machine/blob/main/inc/Abilities/AgentAbilities.php#L62-L82
• Agents API: https://github.com/Automattic/agents-api/blob/main/src/Runtime/register-runtime-package-run-ability.php#L149-L165
• Static Site Importer: https://github.com/Automattic/static-site-importer/blob/main/includes/abilities.php#L420-L429

Core also permits wp_unregister_ability() and wp_unregister_ability_category() at any time after registration, so completion of the registration hooks does not make the registry immutable: https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/abilities-api.php#L301-L330

Compatibility

This changes the public registration lifecycle. Code registering on the recommended Abilities API hooks continues to work unchanged, and registration before init remains rejected. Code that inspects or snapshots abilities must still run after the registrations it expects to observe.

Tests

Adds coverage that:

• abilities can be registered after wp_abilities_api_init and remain discoverable via wp_has_ability(), wp_get_ability(), and wp_get_abilities();
• ability categories can be registered after wp_abilities_api_categories_init;
• pre-init registration still fails with _doing_it_wrong().

How to test

1. Run npm install.
2. Run npm run env:start.
3. Run npm run test:php -- --group abilities-api.
4. Confirm the Abilities API test group passes, including post-init ability and category registration and pre-init rejection.
5. Run npm run env:stop.

Local verification:

• php -l src/wp-includes/abilities-api.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbility.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• vendor/bin/phpcs --standard=phpcs.xml.dist src/wp-includes/abilities-api.php tests/phpunit/tests/abilities-api/wpRegisterAbility.php tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• git diff --check

Focused PHPUnit was not run locally because this checkout does not have wp-tests-config.php configured. The GitHub test matrix exercises the affected suites.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode via Homeboy
• Model(s): OpenAI GPT 5.5 (initial patch), openai/gpt-5.6-terra (lifecycle review revision)
• Used for: Drafted the implementation, tests, documentation revision, and PR text from the public Core discussions and source-code investigation; the submitter reviewed and remains responsible for the change.

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

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.

[gziolo]

Closing together with https://core.trac.wordpress.org/ticket/65583.

[chubes4]

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

What

Allows Abilities API registration through wp_register_ability() and wp_register_ability_category() after the init action has fired.

The wp_abilities_api_init and wp_abilities_api_categories_init hooks remain the recommended deterministic registration points. Callers registering afterward are responsible for doing so before relevant discovery, snapshot, or use. The public wrappers continue to reject genuinely too-early registration before init.

Why

The public wrapper currently treats the Abilities API action as the only valid registration window, even though the underlying registry supports later registration. This makes registration timing stricter than other WordPress registration APIs and pushes consumers that load later toward direct registry calls.

This timing contract was explicitly debated during the original Core merge:

• Aaron Jorbin noted that registration problems are commonly caused by registering too early rather than too late, and recommended did_action() unless a concrete reason required doing_action(): Abilities API: Implement server-side registry with REST API endpoints #9410 (comment)
• The original merge used did_action(), allowing registration after initialization.
• A follow-up deliberately changed the check to doing_action() based on concerns that arbitrary timing might cause less obvious downstream problems: Abilities API: Use stricter doing_action check when registering #10452

This PR revisits that trade-off. It does not claim that downstream consumers are unable to attach registration callbacks earlier. Instead, it follows the block-registration model: provide a recommended deterministic hook while allowing extenders to register later when they do so before the relevant consumer runs.

Existing implementations have independently added post-hook registration paths through the registry:

• Data Machine: https://github.com/Extra-Chill/data-machine/blob/main/inc/Abilities/AgentAbilities.php#L62-L82
• Agents API: https://github.com/Automattic/agents-api/blob/main/src/Runtime/register-runtime-package-run-ability.php#L149-L165
• Static Site Importer: https://github.com/Automattic/static-site-importer/blob/main/includes/abilities.php#L420-L429

Core also permits wp_unregister_ability() and wp_unregister_ability_category() at any time after registration, so completion of the registration hooks does not make the registry immutable: https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/abilities-api.php#L301-L330

Compatibility

This changes the public registration lifecycle. Code registering on the recommended Abilities API hooks continues to work unchanged, and registration before init remains rejected. Code that inspects or snapshots abilities must still run after the registrations it expects to observe.

Tests

Adds coverage that:

• abilities can be registered after wp_abilities_api_init and remain discoverable via wp_has_ability(), wp_get_ability(), and wp_get_abilities();
• ability categories can be registered after wp_abilities_api_categories_init;
• pre-init registration still fails with _doing_it_wrong().

How to test

1. Run npm install.
2. Run npm run env:start.
3. Run npm run test:php -- --group abilities-api.
4. Confirm the Abilities API test group passes, including post-init ability and category registration and pre-init rejection.
5. Run npm run env:stop.

Local verification:

• php -l src/wp-includes/abilities-api.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbility.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• vendor/bin/phpcs --standard=phpcs.xml.dist src/wp-includes/abilities-api.php tests/phpunit/tests/abilities-api/wpRegisterAbility.php tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• git diff --check

Focused PHPUnit was not run locally because this checkout does not have wp-tests-config.php configured. The GitHub test matrix exercises the affected suites.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode via Homeboy
• Model(s): OpenAI GPT 5.5 (initial patch), openai/gpt-5.6-terra (lifecycle review revision)
• Used for: Drafted the implementation, tests, documentation revision, and PR text from the public Core discussions and source-code investigation; the submitter reviewed and remains responsible for the change.

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

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.

[gziolo]

Closing together with https://core.trac.wordpress.org/ticket/65583.

[chubes4]

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

What

Allows Abilities API registration through wp_register_ability() and wp_register_ability_category() after the init action has fired.

The wp_abilities_api_init and wp_abilities_api_categories_init hooks remain the recommended deterministic registration points. Callers registering afterward are responsible for doing so before relevant discovery, snapshot, or use. The public wrappers continue to reject genuinely too-early registration before init.

Why

The public wrapper currently treats the Abilities API action as the only valid registration window, even though the underlying registry supports later registration. This makes registration timing stricter than other WordPress registration APIs and pushes consumers that load later toward direct registry calls.

This timing contract was explicitly debated during the original Core merge:

• Aaron Jorbin noted that registration problems are commonly caused by registering too early rather than too late, and recommended did_action() unless a concrete reason required doing_action(): Abilities API: Implement server-side registry with REST API endpoints #9410 (comment)
• The original merge used did_action(), allowing registration after initialization.
• A follow-up deliberately changed the check to doing_action() based on concerns that arbitrary timing might cause less obvious downstream problems: Abilities API: Use stricter doing_action check when registering #10452

This PR revisits that trade-off. It does not claim that downstream consumers are unable to attach registration callbacks earlier. Instead, it follows the block-registration model: provide a recommended deterministic hook while allowing extenders to register later when they do so before the relevant consumer runs.

Existing implementations have independently added post-hook registration paths through the registry:

• Data Machine: https://github.com/Extra-Chill/data-machine/blob/main/inc/Abilities/AgentAbilities.php#L62-L82
• Agents API: https://github.com/Automattic/agents-api/blob/main/src/Runtime/register-runtime-package-run-ability.php#L149-L165
• Static Site Importer: https://github.com/Automattic/static-site-importer/blob/main/includes/abilities.php#L420-L429

Core also permits wp_unregister_ability() and wp_unregister_ability_category() at any time after registration, so completion of the registration hooks does not make the registry immutable: https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/abilities-api.php#L301-L330

Compatibility

This changes the public registration lifecycle. Code registering on the recommended Abilities API hooks continues to work unchanged, and registration before init remains rejected. Code that inspects or snapshots abilities must still run after the registrations it expects to observe.

Tests

Adds coverage that:

• abilities can be registered after wp_abilities_api_init and remain discoverable via wp_has_ability(), wp_get_ability(), and wp_get_abilities();
• ability categories can be registered after wp_abilities_api_categories_init;
• pre-init registration still fails with _doing_it_wrong().

How to test

1. Run npm install.
2. Run npm run env:start.
3. Run npm run test:php -- --group abilities-api.
4. Confirm the Abilities API test group passes, including post-init ability and category registration and pre-init rejection.
5. Run npm run env:stop.

Local verification:

• php -l src/wp-includes/abilities-api.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbility.php
• php -l tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• vendor/bin/phpcs --standard=phpcs.xml.dist src/wp-includes/abilities-api.php tests/phpunit/tests/abilities-api/wpRegisterAbility.php tests/phpunit/tests/abilities-api/wpRegisterAbilityCategory.php
• git diff --check

Focused PHPUnit was not run locally because this checkout does not have wp-tests-config.php configured. The GitHub test matrix exercises the affected suites.

AI assistance

• AI assistance: Yes
• Tool(s): OpenCode via Homeboy
• Model(s): OpenAI GPT 5.5 (initial patch), openai/gpt-5.6-terra (lifecycle review revision)
• Used for: Drafted the implementation, tests, documentation revision, and PR text from the public Core discussions and source-code investigation; the submitter reviewed and remains responsible for the change.

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

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.

[gziolo]

Closing together with https://core.trac.wordpress.org/ticket/65583.