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

WordPress Trac noreply at wordpress.org
Sun May 7 19:59: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):

 Thinking more about this. Part of the original idea here was to have an
 indicator in the DB of whether
 [https://core.trac.wordpress.org/ticket/55942#comment:1 the data was
 serialized]:

 > The most basic: `0` would be default and undefined, `1` would mean the
 data was not serialized when storing it, `2` would mean the data was
 serialized.

 This, of course, will not fix the current "weirdness" with the options and
 meta APIs where you save `true` but get back `(string) 1` (which is the
 same as when you save `(int) 1`). However it will eliminate calls to
 `maybe_unserialize()` for updated and newly added options and meta values.
 I'm personally not a big fan of this, but it is a viable solution too.

 This would also open the door to consider JSON encoding all values except
 class instances when storing them in the DB. That would "enforce" strict
 types because JSON encoding preserves the data type (`$data = json_encode(
 true )` then `json_decode( $data )` would return `true`). This will fix
 the above mentioned "weirdness".

 There would be a tiny bit of increase in resources used, but it would
 probably be negligible as `json_decode()` for arrays seems faster than
 `unserialize()` and for `int` and `bool` is super fast. Haven't tested
 with production databases but expecting the faster decoding of arrays will
 compensate the need to decode boolean, integer and float values.

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


More information about the wp-trac mailing list