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

 Replying to [comment:77 azaozz]:
 > So thinking perhaps this can be split into two:
 > - New/updated/improved way to register option and meta value types.
 Seems best to have new functions (that can be called from the existing)
 which would fix and improve the current behavior, will not use PHP
 globals, etc.
 > - Perhaps reconsider the direction of this ticket (again) and repurpose
 it to add a DB table column that would only hold data indicating whether
 the option or meta value is serialized (i.e.
 [https://core.trac.wordpress.org/ticket/55942?replyto=76#comment:1 option
 1 in the first comment]).

 Interesting. Thinking this can be made the opposite way, and still avoid
 changing the table structure of options and all meta tables. When expiring
 transients are saved, an extra row containing the timeout is saved. Could
 we insert row `'_option_type_{$option_name}'` as the PHP type (repeated
 options has same type)?

 The default, at least for now, is to set the actual type of $value, but if
 $type is illegal ('int' allowed) then do not save the type at all, alowing
 for a mixed $value (explicitly unknown type). Change
 `update_option( string $option, mixed $value, string|bool $autoload = null
 ): bool`
 to
 `update_option( string $option, mixed $value, string|bool|null $autoload =
 null, string|null $type = null ): bool`

 Then, if `register_setting()` gets an overhaul to accept PHP type, this
 will be the default when saving, but overrides the db value type for
 `get_option()`. Same logic for meta.
 Then, only if db value type is not set/found (or unknown/illegal type),
 run `maybe_unserialize()`, elseif set to not scalar assume serialized and
 just `unserialize()`. This opens for (later) an explicit pseudo type
 'json', even also 'serialized'. When scalar, convert to type (alias 'int'
 as 'integer').


 1. Reduce calls to `maybe_unserialize()` when type is explicitly a scalar
 type.
 2. No costly database table restructuring
 3. Saved typing by default, first phase PHP types only, second phase maybe
 allow/respect [ 'scalar', 'numeric', 'number', 'serialized', 'json', ...]
 4. Saved typing can be opted out for special cases or som kind of extended
 backwards compatibility.
 5. Should work with centralized registering of sanitizing, validation and
 UI/HTML handling, as saving with type this takes precedence on save,
 registered handling takes precedence on read/returning values.
 6. No new/alternative functions for centralized registering
 7. Future scope as 3. above, plus opens for even other serialization
 methods (CSV maybe?) and even compression.

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