[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