[wp-trac] [WordPress Trac] #55942: Add a "type" field to the meta and options tables

[WordPress Trac]

#55942: Add a "type" field to the meta and options tables
-------------------------------------------------+-------------------------
 Reporter:  azaozz                               |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Database                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-      |     Focuses:
  testing                                        |  performance
-------------------------------------------------+-------------------------

Comment (by azaozz):

 @petitphp thanks for the patch! Looks pretty good :) Thinking perhaps
 there are too many filters, like the one on the default types, but lets
 talk about that on GH.

 Replying to [comment:22 flixos90]:
 > Is your idea that the new type column value would be set based on the
 data passed to `add_option()` / `update_option()`, or based on the
 registered type of only registered settings?

 Yeah, been (slowly) testing this and thinking how to handle back-compat.
 Still exploring what would be best. You're right, back-compat is pretty
 hard here.

 > plugins today may to do something like `get_option(
 'some_boolean_ish_option' ) === '1'`, which could break following this
 change.

 Right, and it is even more complicated. Currently if a plugin does
 `add_option( 'my_option', true )` and then a bit later during the same run
 does `get_option( 'my_option' )` the returned value will be `true` as new
 and updated options are cached. I.e. `get_option()` will return the proper
 type and value as passed to `add_option()`. However if it does
 `get_option( 'my_option' )` on the next run, the returned value will be a
 string `'1'` the way it comes out of the DB.

 At the same time the biggest win here is to stop using `is_serialized()`
 and `maybe_unserialize()` for arrays and objects. Thinking when an array
 or object is passed to add/update_option or add/update_meta WP should
 automatically set the type. Then on retrieving options and meta it should
 unserialize the values. There won't be any back-compat problems there as
 this is how it works now.

 However for boolean and numeric values it would most likely have to be
 opt-in. Even looking at the patch, the places where `'1'` was replaces
 with `1`, etc. may cause problems in plugins (as many just copy code from
 core).

 In any case, lets try to figure out the back-compat during 6.2 and add
 this. It would be a pretty good enhancement.

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