[wp-trac] [WordPress Trac] #55942: Add a "value type" parameter to get_option() and get_metadata()

[WordPress Trac]

#55942: Add a "value type" parameter to get_option() and get_metadata()
-------------------------------------------------+-------------------------
 Reporter:  azaozz                               |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  6.3
Component:  Options, Meta APIs                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-      |     Focuses:
  testing                                        |  performance
-------------------------------------------------+-------------------------

Comment (by azaozz):

 Replying to [comment:65 spacedmonkey]:
 > What assumptions were weird there?

 Well, this is completely off-topic here but to me it seems pretty weird
 the way default meta values were implemented (sorry I was away at the time
 and couldn't review it). Pretty complex and soo much code, and so many
 repeated filters for a relatively simple concept. Because of that this
 functionality seems harder to use.

 Also the assumptions about `$single` after the filters seem to be able to
 introduce edge cases/inconsistencies. The same place is buggy/inconsistent
 after the "pre" filters in get_metadata() but the behavior is slightly
 different.

 > Barring number, which IMO, is just a float value,

 Yea, these look good although it seems it may have been better to use the
 PHP types in there and "convert" `float` to `number` in the REST API. Also
 a bit more docs about why one was chosen over the other and how to
 use/what to expect :)

 > I am really against adding new parameter to the signatures of meta and
 options functions and believe we should explore register_meta and
 register_settings.

 As I mentioned above `register_meta()` and `register_setting()` are not
 suitable for the lower level meta and options APIs. They add specific
 requirements and expectations that do not make sense in many cases when
 core or a plugin wants to save and retrieve an option or some meta.

 For example `register_setting()` is targeted at adding a setting or an
 "option" (checkbox, text field, etc.) to the wp-admin UI, not at saving an
 option in the options table. It was later adapted for use in the REST API
 by requiring a schema, etc. which doesn't make sense when adding a simple
 option to the DB.

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