[wp-trac] [WordPress Trac] #55942: Add a "value type" parameter to get_option() and get_metadata()
WordPress Trac
noreply at wordpress.org
Sun Apr 30 19:33:27 UTC 2023
#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:53 knutsp]:
> 'number' should be treated as union type int|float (PHP 8.0) and pass
the `is_numeric()` test.
The problem here is how to match PHP data types to REST data types (as
implemented in WP). Seems REST's `number` should match PHP's `float`. So
when retrieving registered meta of type `number`, it will have to do
`get_metadata( $meta_type, $object_id, $meta_key, $single, 'float' );`
(It's a bit confusing that the REST data types (as used in WP) seem to
come from JSON data types, however JSON doesn't have `integer` type
according to [https://www.rfc-editor.org/rfc/rfc8259.html#section-1 RFC
8259].)
> Both `register_[setting|meta]()` and typed
`[get|update]_[option|meta]()` could be enhanced support both 'number',
'int[eger]' and 'float'.
Thinking it would perhaps be better to keep it simple and limit the "data
type translation" to one place. I.e. replace `number` with `float` in
`register_setting()` and `register_meta()`.
> The register functions are for full and flexible sanitation and
validation...
Yes, and the possibility to retrieve strict data types from `get_option()`
and `get_metadata()` would compliment that.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/55942#comment:58>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list