[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 justlevine):

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

 Hey @jorgefilipecosta I'm not sure I follow why `core/{post?}/get` or
 whatever it end's up shaped like would follow a different pattern than
 settings, that also have a `get`, `update`, `delete`, and potentially more
 like `cache/*` `sync` `migrate` `export` `upgrade`, `some ai use case` etc
 etc.

 But that's not even my primary concern here: if we need to deprecate for
 an improved pattern after the inefficiencies prove themselves justifiable,
 while sad and wasteful, it's still less sad and less wasteful than a lot
 of other prior art, and the API there was designed with intentional
 futurecompat to allow for this discussion and evolution to take place (the
 discussion happening on that ticket).

 The questions raised there are about the holistic process and design form
 - and testing/evolution - the API decisions have gone through before they
 hit core. This is about learning from WordPress 5.0 and the dozens of
 community summits since: We don't have 5+ years to convince folks about
 AI, if we don't have community participation throughout the entire process
 we'll lose no matter how good of an API we build. The only currency that
 matters in the age of AI is '''trust'''.

 > We intentionally kept it simple

 To cc @johnbillion from
 https://github.com/WordPress/ai/issues/40#issuecomment-3909870721, I
 believe the the question being asked is "who is we", i.e. how much
 intentionality and forethought has been given both to the current
 `show_in_abilities` shape, and its future compatibility with whatever
 other possibilities might make more sense. I'm only one of the two
 recorded code reviewers, but I ''personally'' didn't give
 `show_in_abilities` any thought until I was reviewing ''this'' PR, which I
 think validates the concern they're raising and also kinda underlies
 generally it's important to get more eyes and a bit more time and to these
 things holistically, and tie this ''and'' `get-settings` to the discussion
 about namespacing, since that decision can the ideal schema shapes.

 > We already follow a flat naming pattern for similar abilities: core/get-
 site-info, core/get-user-info, core/get-environment-info, etc.

 FWIW I am firmly on record against shipping those for 6.9, and considering
 that I still haven't been shown any compelling IRL use case for `get-
 environment-info` or `get-site-info`, and if we ''do'' go for namespaces,
 we've now got a `core/user/*` to reconcile with `core/get-user-info`, so
 yeah I do think the argument to "learn from the experience" (IMO) and give
 these more than a few weeks to breathe is a good idea, especially if thats
 what seasoned committers are requesting.

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