[wp-trac] [WordPress Trac] #55942: Add a "type" field to the meta and options tables
WordPress Trac
noreply at wordpress.org
Fri Oct 21 18:33:33 UTC 2022
#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
More information about the wp-trac
mailing list