Add a core/settings ability by jorgefilipecosta · Pull Request #691 · WordPress/ai

jorgefilipecosta · 2026-06-09T16:56:18Z

Summary

Adds the core/settings ability to the plugin, matching the equivalent WordPress core change in WordPress/wordpress-develop#12141. Read-only; returns settings flagged show_in_abilities as a flat name => value map (metadata in the output schema), filterable by group or slugs (mutually exclusive). Requires manage_options.

Settings — registers core/settings. Kept near-identical to core's WP_Settings_Abilities (differences marked with // Plugin: comments). It registers at priority 11 and unregisters any core-provided copy first, so the plugin's version wins when both are present.
Show_In_Abilities — seeds the show_in_abilities flag onto a curated set of core settings via the register_setting_args filter, so the ability returns data on a stock site before core ships the flag. Object-type-agnostic, for future reuse (post types, meta).

Test plan

Prerequisite: the client-side Abilities API (@wordpress/abilities) is only loaded in the block editor once an AI experiment is enabled — the experiment's editor script declares the @wordpress/abilities + @wordpress/core-abilities modules as dependencies, which adds them to the editor's import map. So first enable an experiment such as Excerpt Generation and open a new post (post-new.php). Then, in the browser console:

const { executeAbility } = await import( '@wordpress/abilities' );

await executeAbility( 'core/settings', {} );
await executeAbility( 'core/settings', { group: 'reading' } );
await executeAbility( 'core/settings', { settings: [ 'blogname' ] } );

Flat name => value map with typed values
group / slugs filters work; supplying both is rejected
Non-admin (no manage_options) is denied

Integration tests added under tests/Integration/Includes/Abilities/. An end-to-end test (tests/e2e/specs/abilities/core-settings.spec.js) drives the ability through the client-side Abilities API from the editor (with an experiment enabled).

Core PR: WordPress/wordpress-develop#12141

github-actions · 2026-06-09T16:56:31Z

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.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: jorgefilipecosta <jorgefilipecosta@git.wordpress.org>
Co-authored-by: gziolo <gziolo@git.wordpress.org>
Co-authored-by: dkotter <dkotter@git.wordpress.org>

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

Add the core/settings ability, matching the equivalent WordPress core change. Read-only; returns settings flagged show_in_abilities as a flat name => value map, filterable by group or by name, gated on manage_options. The Settings class is kept near-identical to core's WP_Settings_Abilities and registers at priority 11, unregistering any core-provided copy first so the plugin wins when both are present. A generic Show_In_Abilities component seeds the show_in_abilities flag onto a curated set of core settings so the ability returns data on a stock site. Includes a Playwright e2e spec that drives the ability through the @wordpress/abilities client. Keeps the output schema free of unsupported formats and per-property defaults so the client-side validator accepts it and does not inject defaults into filtered results.

…ent enabled The @wordpress/abilities client modules are only added to the editor's import map when an AI experiment is enabled (its script declares them as module_dependencies). Enable Excerpt Generation and drive the test from a new post instead of skipping when the client is unavailable.

github-actions · 2026-06-15T19:25:48Z

✅ WordPress Plugin Check Report

✅ Status: Passed

📊 Report

All checks passed! No errors or warnings found.

🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check

'settings' reads more naturally than 'slugs' for an ability about settings: executeAbility( 'core/settings', { settings: [ 'blogname' ] } ).

Add an e2e sample plugin that registers a setting with show_in_abilities, map it in .wp-env.test.json, and assert the core/settings ability returns it.

gziolo · 2026-06-17T07:53:54Z

@jeffpaul or @dkotter, what are the conditions for this new (and other planned) ability to get included in the AI plugin? Code-wise it's shaping up nicely according to what we discussed in #40 and in https://core.trac.wordpress.org/ticket/64605. The idea would be to land it in the plugin first for early testing, and then put it in WordPress core.

gziolo · 2026-06-17T08:13:36Z

+	 */
+	public static function settings_map(): array {
+		return array(
+			// General.


Noting that some settings will get duplicated between core/get-site-info and core/settings.

It seems like we will have to follow up in WP core to replicate show_in_abilities check inside core/get-site-info once that concept is there.

More broadly, show_in_abilities might probably need more variety, for example:

`show_in_abilities` => true, `show_in_abilities` => false, `show_in_abilities` => 'read', `show_in_abilities` => 'write',

Yah show_in_abilities will pass by some evolution in some cases like show_in_rest it may also need to pass schema information, and read/write distinction may also be a good approach. Would you want me to already include read/write distinction as part of this PR or do you think this is something for the future?

@SInCE

- Simplify the input schema: replace the group-XOR-name `oneOf` with optional, combinable `group` and `fields` filters (rename `settings` -> `fields`, matching core/get-site-info). Default to an empty object so the type:object schema default serializes as {}. - Memoize the exposed settings so the input/output schema and execute() derive from a single walk of get_registered_settings(). - Cast object-typed values to objects so they serialize as {} (not []) and satisfy the output schema validated by execute(). - Drop the redundant `site` ability-category fallback (core registers it and the plugin requires WP 7.0). - Use __() instead of esc_html__() for ability strings, and @SInCE x.x.x per CONTRIBUTING.md. - Harden value handling so the new code passes PHPStan at the strictest level. - Tests: assert keys order-insensitively and cover combined group+fields filtering.

@SInCE

Mirrors the fixes from the core/settings review (#691) that also apply here: - Memoize the exposed post types so the input schema and the permission/execute callbacks derive from a single walk of the registered post types. - Default the input schema to an empty object so the type:object default serializes as {}. - Use __() instead of esc_html__(), and @SInCE x.x.x per CONTRIBUTING.md. - Harden input/value handling (type guards, capability resolver, non-negative int helper) so the new code passes PHPStan at the strictest level. The `content` ability-category fallback is kept on purpose: unlike `site`, `content` is a new category not present on the plugin's minimum WordPress (7.0).

jorgefilipecosta · 2026-06-17T16:26:23Z

Hi @gziolo, thank you a lot for the review I think I applied/answered all the feedback.

dkotter · 2026-06-17T21:09:44Z

@jeffpaul or @dkotter, what are the conditions for this new (and other planned) ability to get included in the AI plugin? Code-wise it's shaping up nicely according to what we discussed in #40 and in https://core.trac.wordpress.org/ticket/64605. The idea would be to land it in the plugin first for early testing, and then put it in WordPress core.

No real condition here, other than we typically like to utilize the things we're adding within the AI plugin (instead of just adding something others can use).

But that said, if the goal here is to help prove this concept out so we can get movement upstream, that's also a fine goal and works for me.

I've held off on reviewing things here as it seemed like it was till a work in progress but let me know when things are settled and I'm happy to review and get this moving along for our next release.

jorgefilipecosta force-pushed the add/core-settings-ability branch from 4c74702 to 413c6a4 Compare June 12, 2026 14:58

gziolo self-requested a review June 15, 2026 12:31

jorgefilipecosta force-pushed the add/core-settings-ability branch from 413c6a4 to 7d9a1b2 Compare June 15, 2026 16:51

jorgefilipecosta added 2 commits June 15, 2026 20:18

jorgefilipecosta force-pushed the add/core-settings-ability branch from 52920c8 to a431013 Compare June 15, 2026 19:19

jorgefilipecosta added 2 commits June 15, 2026 20:30

Rename the core/settings 'slugs' input to 'settings'

7a2f0a0

'settings' reads more naturally than 'slugs' for an ability about settings: executeAbility( 'core/settings', { settings: [ 'blogname' ] } ).

Test that core/settings exposes settings registered by other plugins

8970d2d

Add an e2e sample plugin that registers a setting with show_in_abilities, map it in .wp-env.test.json, and assert the core/settings ability returns it.

This was referenced Jun 16, 2026

Abilities API: Add a core/settings ability WordPress/wordpress-develop#12141

Open

[in progress] Add a core/content ability #738

Closed

[in progress] Add a core/content ability #739

Draft