[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:  2nd-opinion         |     Focuses:  performance
--------------------------------+--------------------------

Comment (by knutsp):

 Replying to [comment:82 knutsp]:
 > Todo:
 > 1. Detect where in current functions we can avoid
 `maybe_[un_]serialize()`, for performance
 > 2. Check the implications on db storage size and performace to update
 and get an extra option (when not cached)

 1. Serializing:
  * Serialize (on add/update) should happen for 'array' or 'object', when
 $type os not set, I guess as now.
  * Serialize (on add/update) should also happen is $type is set to
 'arr[ay]' or 'obj[ect]', accoring to principle of implicit and explicit
 type.
  * All existing options/metadata, already serialized, should get 'array'
 or 'object' added as their type, accordingly, on this upgrade.
  * Unserialize (on get) should then only happen when saved type is 'array'
 or 'object'.
  * Before returning, and with a found type row, settype is performed.

 2. By treating 'string' as the default and only saving the
 (implicit/explicit) type when it's not the default, the number of extra
 table rows may be acceptable. This is now in the my concept plugin v2.0.

 I will probably not be landing anything like this with a patch and tests
 for a long time. I've just started looking at the inner workings of the
 basic option and metadata functions to spot where this new logic may fit
 in. So if the principle gets accepted, help needed.

 I observe that when saved options/meta are cached, the PHP type of the
 returned value is intact. Since this type confusion is already here, I
 guess backwards compatibility concerns may be small enough.
 `WP_REST_Meta_Fields` must not be affected.

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