Conversation
| array( 'key' => $name, 'status' => rest_authorization_required_code() ) | ||
| ); | ||
| } | ||
|
|
There was a problem hiding this comment.
I did just run into a problem, I think a lot of devs could run into. When I haven't registered the meta as single and want to update, I end up here. Lets say I run a POST request like this: http://example.com/wp-json/wp/v2/posts/1177?meta[test]=just-a-string
$values would be a string here, but needs to be an array. My workaround was on L170:
if ( ! is_array( $values ) ) {
$values = array( $values );
}
Current coverage is 100% (diff: 100%)
|
|
Coverage is now at 100%, ready for review I think! |
| include: | ||
| - php: 5.6 | ||
| env: WP_TRAVISCI=travis:phpunit WP_VERSION=nightly | ||
| - php: 5.6 |
There was a problem hiding this comment.
We'll still need the tests to work with latest when this is merged to core for wp-api?
There was a problem hiding this comment.
I think we should drop support for 4.6, IMO
lib/class-wp-rest-meta-fields.php
Outdated
| } | ||
|
|
||
| /** | ||
| * Get the settings. |
There was a problem hiding this comment.
Think this docblock might be incorrect?
lib/class-wp-rest-meta-fields.php
Outdated
| } | ||
|
|
||
| /** | ||
| * Update settings for the settings object. |
lib/class-wp-rest-meta-fields.php
Outdated
| * Update settings for the settings object. | ||
| * | ||
| * @param WP_REST_Request $request Full detail about the request. | ||
| * @return WP_Error|array |
| 'prepare_callback' => 'meta_rest_api_prepare_value', | ||
| ); | ||
| $default_schema = array( | ||
| 'type' => null, |
There was a problem hiding this comment.
It might be simpler to set the default type to $args['type'], as you wouldn't then need the double check below.
There was a problem hiding this comment.
Can't do that, as then we can't check if the type was overridden in the user-specified schema below.
|
|
||
| $default_args = array( | ||
| 'name' => $name, | ||
| 'single' => $args['single'], |
There was a problem hiding this comment.
Yep, it has a default in register_meta
lib/class-wp-rest-meta-fields.php
Outdated
| $fields = $this->get_registered_fields(); | ||
|
|
||
| $schema = array( | ||
| 'description' => __( 'Post meta fields.' ), |
There was a problem hiding this comment.
I think this should be Meta fields, as it's used on comments etc too. Also, CPTs are not really called posts in the API.
| } else { | ||
| $rest_args['schema']['type'] = 'array'; | ||
| $rest_args['schema']['items'] = array( | ||
| 'type' => $args['type'], |
There was a problem hiding this comment.
I didn't see anywhere that we are validating / casting the values of multiples based off the type => array, items => { type => 'number' } for example.
|
I've been playing and noticed some things:
I haven't been thorough, not sure if that's the type of thing you're looking for. |
|
@tharsheblows Thanks for the feedback! We're discussing these in slack and the update function definitely needs to be tightened up, that array casting issue is definitely a bug and making the update stricter should address the first item too |
|
There are also a slight issue when deleting multiple identical meta_values for a given meta_key in you'll get an error when you delete / update it because it tries to do all of the 13s one at a time and they all get done at once by delete_metadata I think. I had an issue when updating to multiple identical meta_values but I can't reproduce it. |
I hate this rule.
This is a first pass at new-style meta support for the REST API.
With the new
register_metasupport in 4.6, we can now support meta fully, as it's actually a registered thing instead of being a vague mess.This PR includes a brand new README as well, which documents how to use this. tl;dr set
show_in_rest => truein yourregister_metacall, then use themetafield on the regular endpoints.Important note: this is not ready for merge yet, and still requires security checks and further validation.