[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:71 flixos90]:

 > I'm sorry but this is not correct. You're referring to what
 register_setting() was intended for use originally, but that hasn't been
 the case since 4.7, so at this point for longer than 6 years. The function
 is also responsible for...

 Yea, you're right. I think I understand where you're coming from.
 Unfortunately the "expansion/refactoring" in 4.7 made this a "try to do
 everything" type of function which is pretty bad design from software
 architecture point of view. So now it has many flaws and mixes up settings
 for HTML form elements with settings for the REST API and with settings
 for the retrieval of data from the database. Thinking it is a bad idea to
 continue to expand its scope.

 > what is your concern with handling the database type for an option
 centrally?

 Because it is mostly useless to try to "handle" it outside of the
 database. The initial idea of this ticket was to store the type of the
 option/meta value in the database. I.e. it is not possible to change and
 is set by the data type of the last `update_option()`. This would have
 fixed some of the "weirdness" with the options and meta APIs.

 Unfortunately it became clear that this is pretty much impossible to
 implement without breaking back-compat, and would introduce edge cases
 with caching. Trying to use external "register" comes with pretty much the
 same strings attached, and in addition there is a chance for it to become
 out of sync with the values in the DB. That would be a disaster :)

 @knutsp
 > > No much difference, just a bit cleaner way to write it.
 > Cleaner that common, plain PHP, by adding an extra argument to make the
 function convert types?

 Yea, imho it is a bit cleaner. Also reduces calls to `maybe_unserialize()`
 when the expected type is not array or object.

 > If not centrally registered, not in the database, it's guessing what the
 type was (intended to be) before saving.
 > ...
 > To do it correctly, as the entity that saved the data in the first
 place,

 Hmm, this is a good question. What is the expected functionality here,
 what do you call "correct"? Do you think it is a good idea for plugins to
 continue to type-cast the `get_option()` calls? From a plugin's point of
 view it doesn't matter what was the type when the value was saved in the
 DB, it matters what the type is when the plugin is going to use that
 value. So type-casting remains a quite viable solution regardless of any
 DB changes or registrations.

 > To handle maybe serialized array/object without sniffing will require
 data with structural types that need serialization to be registered
 centrally...

 Nah, this doesn't seem like a good idea. Any separate or "central"
 registry (where the type is not saved in the same table row as the value)
 can get out of sync. For example a plugin that registers something gets
 deactivated.

 > A refined register_setting/register_meta or two new, simpler
 register_setting_type/register_meta_type that work in some logical
 connection with each other, could be a way forward.

 Not sure about that. In addition to not being backwards compatible a
 "central registry" would not add any value for core or plugins that just
 need to save some data to the DB (option or meta). On the opposite, it
 will be a hindrance as once registered they will not be able to change the
 data type as that may break other plugins' expectations. In addition other
 plugins may break when the original plugin is deactivated.

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