[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:  6.1
Component:  Database                      |     Version:
 Severity:  normal                        |  Resolution:
 Keywords:  needs-unit-tests needs-patch  |     Focuses:
------------------------------------------+---------------------

Comment (by azaozz):

 Replying to [comment:16 barry.hughes]:

 > Native JSON support simply means there would be support for a safer (but
 also more limited) form of serialization with different 'performance'
 characteristics (I'm using that a little loosely to mean not just runtime
 costs, but space requirements -- JSON tends to be more compact).
 >
 > The big win here in my opinion though is safety (object injection not
 being possible with JSON), and I think there is value in WordPress
 offering that safer path.

 Yep, I agree. I'm only uneasy about adding that support at the same
 place/same level where PHP types are added/defined.

 > > If a plugin wants to use JSON, it would be pretty easy to encode the
 value before passing it to the API.
 >
 > Yep, also true, and it doesn't close off a future where some kind of
 wrapper for JSON-encoded options is supported by WP (out of scope here).

 Actually... Why not add such wrapper/helper functions now.

 As far as I imagine it, it would only accept arrays. Then JSON encode
 them, and save as strings. Then the corresponding method will JSON decode
 the string from the DB. The values will be PHP arrays after decoding.
 Think that would work quite well :)

 > from a back-compat perspective, I'd have thought null (PHP) would map to
 'original Options API behaviour'

 Yes, implementing this enhancement will change the returned type and in
 some cases the returned value. For example saving `true` as option value
 would currently return string `"1"`, but not if the option is checked
 immediately after adding. Then it would return the proper type.

 Been thinking how to handle the back-compat here, may turn out to be more
 problematic than expected. Seems in the worst case scenario we can add
 another param to `get_option()`, etc. functions to specify whether to use
 strict types. (I'd hate to do that but seems it may be needed). Lets look
 in this again after there is a patch and tests :)

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