[wp-trac] [WordPress Trac] #43392: Support 'object' and 'array' types in register_meta()

[WordPress Trac]

#43392: Support 'object' and 'array' types in register_meta()
-------------------------------------------------+-------------------------
 Reporter:  diegoliv                             |       Owner:
                                                 |  TimothyBlynJacobs
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  5.3
Component:  Options, Meta APIs                   |     Version:  4.9.4
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests dev-        |     Focuses:  rest-api
  feedback 2nd-opinion                           |
-------------------------------------------------+-------------------------

Comment (by mnelson4):

 Thanks for the patches @TimothyBlynJacobs !

 > 1. Do we want to enforce that the value is valid in addition to it not
 being a non-jsonserializable PHP object? I think we'd only be able to
 apply this treatment for object and array meta types for BC reasons.
 Importantly, I think this would only happen in the default
 prepare_callback, so any custom preparation of values wouldn't be
 effected.

 We discussed a bit in chat today, and thought it's probably rare that
 developers are registering meta AND providing a schema AND providing
 values that don't match that schema. Plus, the current behaviour could be
 considered a bug ("I provided a schema, and you're not enforcing it.
 What's up with that WP??") so a BC-breaking change could be seen as a
 bugfix, and so more palatable.

 With that in mind, I think we should enforce that values should match the
 schema on reading and writing, even for scalar values. BUT we could
 probably be merciful if the data is just of the wrong type (eg providing a
 numeric string instead of a number, an object instead of an array etc).


 > 2. Do we want to sanitize the output value?

 If that's what settings controller is doing, sure. It'd probably be safer.
 Just be careful to not escape things twice.

 > 3. ...Do we want to do a check before validation and return a 500 error
 instead?

 A 500 error would probably be more expected, but a 400 isn't the end of
 the world.

 > What if the invalid value is omitted by the client? This would currently
 delete the value, do we instead want to reject any update multi request
 when there is an invalid value stored in any of the meta entries?

 Oh, so what if the API client automatically removes the null value before
 sending it? Surprise deletion. That would be a bit annoying. And if we
 rejected "any update multi request when there is an invalid value stored
 in any of the meta entries", clients could still fix those invalid meta
 entries by issuing a query to update single items. So they'd have a
 workaround (albeit possibly inconvenient), and no accidental deletions. So
 ya rejecting those would probably be good.

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