[wp-trac] [WordPress Trac] #64616: Abilities API: Add core/update-settings ability

[WordPress Trac]

#64616: Abilities API: Add core/update-settings ability
--------------------------------------+---------------------
 Reporter:  jorgefilipecosta          |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  AI                        |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by jorgefilipecosta):

 Hi @justlevine, thank you so much for the thorough review! I really
 appreciate the detailed feedback and will apply the suggested changes on
 the PR.

 > Left some feedback on the PR. That said, we might want to consider
 holding on this (and reverting #64605) if we can't get
 https://core.trac.wordpress.org/ticket/64596 resolved in time.

 Regarding the potential revert, I believe that independently of the
 nesting discussion, `core/get-settings` and `core/update-settings` should
 still keep these names. While nesting may make sense for posts, where
 grouping by post type feels natural (e.g., `core/post/get`,
 `core/page/get`) — settings don't really have that same need for
 hierarchy.

 We already follow a flat naming pattern for similar abilities: `core/get-
 site-info`, `core/get-user-info`, `core/get-environment-info`, etc. So
 `core/get-settings` and `core/update-settings` are simply consistent
 additions to that existing convention.

 > Is show_in_abilities: bool|array{schema:array<string,mixed}, or are we
 in an awkward place where show_in_abilities is a bool, but we're going to
 infer any schemas from show_in_rest['schema'] ? I'm also not seeing
 anywhere in this or that PR where's we're loading/coercing the existing
 schema, am I missing it or was it left out for some reason?

 Regarding `show_in_abilities` and schemas, Great point! For now,
 `show_in_abilities` is a simple boolean: `true` means the setting is
 exposed in abilities, `false` means it isn't. We intentionally kept it
 simple because we don't support things like renaming settings for
 abilities, which I don't think is needed and could confuse agents.
 Ideally, we should use the raw setting names that map directly to what
 `get_option` / `update_option` expect in core.
 That said, you raise a valid point, some settings do have richer schema
 definitions (like enums) in REST that we're currently not carrying over
 for abilities I agree that `show_in_abilities` should support
 `bool|array{schema: array<string, mixed>}` rather than being limited to
 just a boolean, as I believe you're suggesting. I'll put together a commit
 for that. Thanks for flagging it!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64616#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform