Abilities API: Unify schema conventions across core abilities#11984
Open
gziolo wants to merge 8 commits into
Open
Abilities API: Unify schema conventions across core abilities#11984gziolo wants to merge 8 commits into
gziolo wants to merge 8 commits into
Conversation
…ore/get-environment-info. Aligns both abilities with the pattern already used by `core/get-user-info` by adding a `title` to every output schema property. Titles reuse existing WP Admin translations (e.g. 'Site Title', 'WordPress Address (URL)', 'PHP Version') so clients can display human-friendly labels without introducing new strings. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…elds. Adds the same `fields` input parameter that `core/get-site-info` and `core/get-user-info` accept, so clients can request a subset of the environment payload (e.g. just `php_version`) instead of always receiving all four properties. Unknown field names are rejected by the input schema's enum, matching the existing pattern. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Flips `meta.show_in_rest` to `true` so `core/get-user-info` appears under `wp-abilities/v1/abilities` and can be invoked by REST clients, matching `core/get-site-info` and `core/get-environment-info`. The existing `is_user_logged_in()` permission callback continues to gate access; only the discoverability and REST invocation paths change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…ts in tests. Switches the three remaining sentence-case property titles to Title Case so all schema titles across the core abilities follow the same convention: 'Site Charset' (was 'Encoding for pages and feeds'), 'Environment Type' (was 'Environment type'), and 'Database Server Info' (was 'Database Server version' — the new label is also more accurate, since `$wpdb->db_server_info()` returns a vendor+version string, not just a version). Also aligns the `version` description in `core/get-site-info` with the equivalent `wp_version` description in `core/get-environment-info`. Tightens the registration tests for all three abilities to assert the exact ordered set of fields on both the input enum and the output property keys, so adding a new property to any ability now forces a test update. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
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 Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
gziolo
commented
May 27, 2026
| 'title' => __( 'Database Server Info' ), | ||
| 'description' => __( 'The database server vendor and version string reported by the driver.' ), | ||
| ), | ||
| 'wp_version' => array( |
Member
Author
There was a problem hiding this comment.
It turns out that the WordPress version is included in two site abilities. I’ve aligned the title and description to reflect this.
Test using WordPress PlaygroundThe 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
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
Trims descriptions that only restated the title or duplicated information already encoded in `type`/`enum`, and tightens the few descriptions where a programmatic consumer (e.g. an LLM invoking the ability via REST) actually needs disambiguation: - `environment`: drops the enum re-listing now that the values live in `enum` only. - `url` / `wpurl`: each description now explicitly contrasts with the other, since both fields can carry the same value. - `language` (site-info): notes the dash form (en-US), which differs from `locale` in user-info (en_US). - `id` (user-info): removes "numeric", already implied by `type: integer`. - `description` (user-info): drops the author-page UI reference and notes the empty-string case instead. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…n tests. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…sts. The three tests added in this branch covered behavior introduced under ticket 65355, not 65234. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The three core abilities shipped in 6.9.0 (
core/get-site-info,core/get-user-info,core/get-environment-info) drifted in small but visible ways. This PR aligns them on a shared blueprint so they're predictable to consume from REST clients and easier to extend.titleanddescription, reusing existing WP Admin translations where possible.core/get-environment-infoaccepts the optionalfieldsinput parameter already supported by the other two, with anenumof valid keys.core/get-user-infois exposed via REST (show_in_rest => true) so clients can discover and invoke it under/wp-json/wp-abilities/v1/abilities.db_server_infois relabeledDatabase Server Infosince$wpdb->db_server_info()returns vendor+version, not just a version.title/typeis removed, theenvironmentdescription no longer repeats theenum, and theurl/wpurland site-language/user-localepairs are explicitly contrasted so an AI client can pick the right field and format.enumand the outputproperties, so any future field addition forces a test update.Trac ticket: https://core.trac.wordpress.org/ticket/65355
Test plan
npm run test:php -- --filter=Tests_Abilities_API_WpRegisterCoreAbilitiesis greencore/get-user-infois listed at/wp-json/wp-abilities/v1/abilitiesfor an authenticated usercore/get-environment-infoaccepts{"fields":["php_version"]}and returns only that keyability_invalid_inputerrornpm run env:composer -- lint -- src/wp-includes/abilities.phpreports no violationsnpm run typecheck:phppasses🤖 Generated with Claude Code