[wp-trac] [WordPress Trac] #55942: Add a "value type" parameter to get_option() and get_metadata()
WordPress Trac
noreply at wordpress.org
Fri May 12 10:55:50 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: 2nd-opinion | Focuses: performance
--------------------------------+--------------------------
Comment (by knutsp):
Replying to [comment:81 knutsp]:
> I made a plugin to demonstrate. See file `functions.php` for mye idea
for the typing logic and saving. I also propose to base canonical type
naming on `get_debug_type()` in PHP 8. This can be polyfilled.
> https://github.com/knutsp/core-ticket-55942
From the readme:
# add_option
Current signature: `add_option( string $option, mixed $value = '', string
$deprecated = '', string|bool $autoload = 'yes' ): bool`
Proposed signature: `add_option( string $option, mixed $value = '', string
$deprecated = '', string|bool $autoload = 'yes', ?string $type = null ):
bool`
Alternatively: No change, use `update_option()` to save type?
# update_option
Current signature: `update_option( string $option, mixed $value,
string|bool $autoload = null ): bool`
Proposed signature: `update_option( string $option, mixed $value,
string|bool $autoload = null, ?string $type = null ): bool`
## Logic
If $type is given and not null, use as explicit $type.
else detect the type of $value, use as implicit $type.
Add or update the option value in db
If successful, add or update an extra option, with a prefixed $option as
"_option_type_$option" with the value of $type.
# get_option
Current siganture unchanged: `get_option( string $option, mixed
$default_value = false ): mixed`
## Logic
$type is fetched from a prefixed $option as "_option_type_$option"
After the $value is fetched, and the $type is found and valid, perform
`settype( $value, $type )`before returning it
# add_metadata
(todo)
# add_meta
(todo)
# update_meta
(todo)
# update_{$object_type}_meta
Current signatures: `update_{$object_type}_meta( int $term_id, string
$meta_key, mixed $meta_value, mixed $prev_value = '' ): int|bool|WP_Error`
Proposed sigantures: `update_{$object_type}_meta( int $term_id, string
$meta_key, mixed $meta_value, mixed $prev_value = '', ?string $type = null
): int|bool|WP_Error`
## Logic
If $type is given and not null, use as explicit $type.
else detect the type of $value, use as implicit $type.
Update the meta value in db
If successful, add or update an extra meta_key, with a prefixed $meta_key
as "_meta_type_$meta_key" with the value of $type.
# add_{$object_type}_meta
Current signatures: `add_{$object_type}_meta( int $term_id, string
$meta_key, mixed $meta_value, bool $unique = false ): int|false|WP_Error`
Proposed signatures: `add_{$object_type}_meta( int $term_id, string
$meta_key, mixed $meta_value, bool $unique = false, ?string $type = null
): int|false|WP_Error`
## Logic
If $type is given and not null, use as explicit $type.
else check if the $type already exists
else detect the type of $value, use as implicit $type.
Add the meta value in db
If successful and ( $type did not already exist or have expplicit $type
given),
add or update an extra meta_key, with a prefixed $meta_key as
"_meta_type_$meta_key" with the value of $type.
In other words: To change the stored type of a meta_key that already
exists, explcit type must be used, implicit type will only be added if
type did not exist
------
Todo:
1. Detect where in current functions we can avoid
`maybe_[un_]serialize()`, for performance
2. Check the implications on db storage size and performace to update and
get an extra option (when not cached)
If my proposed solution is not ruled out by the above, and the principle
is interesting or acceptable:
1. Do we need a way to have a way not to save type, like when installing
default options?
2. Keep `add_option()` as is, or change accordingly?
3. Or should new, prefixed functions that calls the current ones, be
created, like `wp_update_option()`?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/55942#comment:82>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list