Skip to content

Abilities API: Add a core/manage-settings ability#90

Open
jorgefilipecosta wants to merge 2 commits into
add/core-settings-abilityfrom
add/core-manage-settings-ability
Open

Abilities API: Add a core/manage-settings ability#90
jorgefilipecosta wants to merge 2 commits into
add/core-settings-abilityfrom
add/core-manage-settings-ability

Conversation

@jorgefilipecosta

Copy link
Copy Markdown
Owner

What

Adds a write-oriented core/manage-settings ability to the Abilities API, the write counterpart to the read-only core/settings ability from WordPress#12141.

WP_Settings_Abilities already reserved a register_manage_settings() slot; this fills it in, reusing the exposed-settings snapshot and the shared helpers (get_exposed_settings(), value_schema(), cast_value()).

  • Input: a map of setting name → new value (at least one). The input/output schemas reuse each setting's own value schema, with additionalProperties: false.
  • Output: a map of each updated setting name → its stored value.
  • Permission: manage_options (shared with core/settings).
  • Annotations: readonly: false, destructive: false, idempotent: true.

Read = write

A truthy show_in_abilities flag grants both read (via core/settings) and write (via core/manage-settings); there is no separate writable flag. No changes to option.php or the exposed-settings helpers are needed.

Atomic, all-or-nothing

The Abilities API validates the input against the registered input schema before execute_manage_settings() runs, so an invalid or unknown value aborts the whole call before any update_option() fires — matching WP_REST_Settings_Controller::update_item(), which rejects the entire request when any value is invalid. Accepted values are sanitized against their schema, stored, then read back and cast for the response.

Tests

Adds Tests_Abilities_API_WpRegisterCoreManageSettingsAbility covering registration/annotations, the mirrored input schema, updating and returning typed values, all-or-nothing aborting on an invalid value, rejection of unknown keys and empty input, the manage_options gate, and writing a setting registered by another plugin. Full --group abilities-api run: 351 tests passing.

Stacked PR

Stacked on WordPress#12141 (base branch add/core-settings-ability); that PR was rebased on latest trunk first. Intended to open against WordPress/wordpress-develop:trunk once WordPress#12141 lands.

Implements the write-oriented `core/manage-settings` ability that
WP_Settings_Abilities reserved a slot for. It reuses the exposed-settings
snapshot built for `core/settings`, so every setting flagged with
`show_in_abilities` is both readable (`core/settings`) and writable
(`core/manage-settings`), and the input/output schemas reuse the same
per-setting schemas.

The Abilities API validates the input against those schemas (with
`additionalProperties` disabled) before execution, so an invalid or unknown
value aborts the whole call before any option is written -- matching the
all-or-nothing behavior of the REST settings controller. Each accepted value
is sanitized against its schema, stored, then read back and cast for the
response.
Covers registration and writable annotations, an input schema that mirrors
the exposed settings with additionalProperties disabled, updating and
returning correctly typed values, all-or-nothing aborting on an invalid
value (the valid sibling must not persist), rejection of unknown keys and
empty input, the manage_options permission gate, and writing a setting
registered by another plugin.
@semanticdiff-com

Copy link
Copy Markdown

Review changes with  SemanticDiff

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant