[wp-trac] [WordPress Trac] #43392: Support 'object' and 'array' types in register_meta()
WordPress Trac
noreply at wordpress.org
Thu May 23 16:22:12 UTC 2019
#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
More information about the wp-trac
mailing list