[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                           |
-------------------------------------------------+-------------------------
Changes (by TimothyBlynJacobs):

 * keywords:  needs-patch => has-patch has-unit-tests dev-feedback 2nd-
               opinion


Comment:

 I've added a first go at a patch to support this.

 One question/potential issue I'd like to highlight is when there is
 invalid data stored in the metadata.

 In the settings controller, if the option value does not validate
 according to the schema, the value is set to `null` in the response. On
 update, if a setting's value is `null` and the stored data is invalid, the
 option is not deleted, instead a `WP_Error` is returned.

 In meta, we aren't currently that strict. The only time we set a value to
 null is if a PHP object that does not implement `JsonSerializable` is
 stored. There is no protection on update to return an error instead of
 deleting the value. Additionally, we do not require the value to be valid
 according to it's schema, nor sanitize it when preparing the value in the
 default `prepare_callback`.

 This gives us a couple of questions.

 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.
 2. Do we want to sanitize the output value? Right now, the only
 sanitization applied to outgoing values is to cast it to the correct type.
 We could again call `rest_sanitize_value_from_schema` in the default
 prepare callback, and again probably only for `object` and `array` types.
 3. When updating a `single` meta value with `null` when the stored value
 is invalid is easy to reject as a `500` error ( matching the behavior in
 the settings controller ). However, when one value in a list of multiple
 is `null`, the request is rejected at the validation stage with a 400
 error since `null` is not supported according to the schema. Do we want to
 do a check before validation and return a `500` error instead? 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?


 1 & 2 Prepare Callback Reference: https://github.com/WordPress/wordpress-
 develop/blob/df9caed81bd3189dd05ea49d044cae7a233cef41/src/wp-includes
 /rest-api/fields/class-wp-rest-meta-fields.php#L459

 3 Request References:

 {{{#!php
 add_post_meta( $post_id, 'object', [ 'project' => 'WordPress' ] );
 add_post_meta( $post_id, 'object', (object) [ 'project' => 'bbPress' ] );
 }}}


 This would be rejected as a 400 error because `meta.object[1]` does not
 match the schema type of `object`.
 {{{
 {
   "meta": {
     "object": [
       {"project":  "WordPress"},
       null
     ]
   }
 }
 }}}

 This would delete the second value.
 {{{
 {
   "meta": {
     "object": [
       {"project":  "WordPress"}
     ]
   }
 }
 }}}

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