[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:69 spacedmonkey]:

 > If we were to use `register_setting()`

 As I mentioned three times already, `register_setting()` is intended for
 use in the UI. That means it is for "settings" from HTML form elements. It
 doesn't make sense to use it for lower level APIs like options and meta.

 > This imply that you are using your own option doesn't it.

 Not only. It is intended for use with code you trust, like your own code,
 core code, "respected" plugins that are known to follow WP best practices,
 etc.

 > What if you are using a option from a plugin written by another
 developer. What if that developer changes the value from a string to a
 boolean when updating the plugin.

 Sure, lets explore this case:
 1. If you use a DB option added by another plugin, and the other plugin's
 author decides to change a DB option value type from `string` to
 `boolean`, and the type is "globally registered", your code may throw a
 fatal error. This is the same as changing the type of the return value
 from a function. Expecting one type of data by a third-party code and
 getting another signifies a badly written code. That's all.

 However if the type of the option value is not "globally registered" but
 instead is passed when retrieving the value (like the current patch), your
 code will not throw a fatal error. You will get an empty string if the
 third-party plugin author suddenly switched the option to a boolean.

 Then there is the case of the third-party plugin being deactivated, so the
 DB option is no longer "globally registered". What then? It just reverts
 to the old behavior of returning string equivalents? More chances for
 fatal errors...

 > No, if we are going to do this, types need to be defined in one place.
 Register settings is the logical place for that.

 No. That's wrong on two counts. See above :)

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