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

 Replying to [comment:76 flixos90]:

 > Looking back, I would have preferred a separate function (e.g.
 `register_option()`?) to keep low-level option registration logic separate

 Yes, same here.

 > That said, the underlying functionality itself is crucial to have, and
 we cannot just stop working on it

 Yea, of course. As the options and meta APIs are some of the most used
 code in WP, thinking it'd be very good to revisit and improve these
 functions. New `register_option()` or maybe even `register_option_type()`
 or `register_option_value_type()` function makes sense imho.

 Then the current problem with `register_setting()` where the type is
 filtered/changeable by third-party code can be fixed too. Also the
 possibility to unregister and re-register option and meta value types
 doesn't sound like a good idea. The registered types should work as if
 they were set in the DB imho, third-party code should not be able to
 interfere with them. (Sorry, getting a bit OT here.)

 > Originally, the focus was on avoiding `maybe_unserialize()`, and FWIW
 that is also the only thing here that has to do with performance.

 The original idea was two-fold:
 - Add a way to get "strict" option and meta values. I.e. the PHP type of
 the data when it was saved in the DB.
 - To reduce number of calls to `maybe_unserialize()` (which would have
 happened as a result of implementing strict types).

 > For example, `get_option( $option, $default, 'int' )` is not really
 better or worse than `(int) get_option( $option, $default )`.

 Yep, it's about the same. The only difference is that the first would skip
 the call to `maybe_unserialize()` as the return value will be an integer.

 > today the return value from `get_option()` may be an integer (if the
 default is returned or somehow filtered) or a string (if coming directly
 from the database). Telling WordPress explicitly that this option is
 ''not'' serialized will avoid the call to `maybe_unserialize()`...
 >
 > I'm basically proposing that options can centrally ''opt out'' of being
 attempted to be unserialized when it's clear they'll never use serialized
 data in the first place.

 Right, this will work too, perhaps with a minimal possibility of sync
 errors. However ideally the "serialized/not-serialized" bit of info should
 be stored on the same row as the option or meta value in the DB. In
 addition that would happen automatically when adding or updating options
 and meta, and will be completely transparent to the code that uses these
 APIs.

 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]).

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