The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: mikachan <[email protected]>
Co-authored-by: ramonjd <[email protected]>
Co-authored-by: andrewserong <[email protected]>
Co-authored-by: t-hamano <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

I've been testing Gutenberg and WP and am unsure how to replicate the original bug:

WP 6.8 + Gutenberg branch wp/6.9 (21.9.0)

Note: WP 6.8 doesn't support array types. Only string values work. Array return 400 (expected)

await wp.data.resolveSelect( 'core' ).getEntityRecords( 'postType', 'attachment', { media_type: 'image', per_page: 5 } );

Triggers the API call:

/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&context=edit&media_type=image&per_page=5&_locale=user

With the results

Arrays are not supported in WP 6.9. The following is a 400:

await wp.data.resolveSelect( 'core' ).getEntityRecords( 'postType', 'attachment', { media_type: ['image', 'audio'], per_page: 5 } );

WP 6.8 + This Gutenberg branch fix/media-types-fix

Works as above. Strings but not arrays.

WP 6.8 + Gutenberg trunk

Both strings and arrays are accepted.

Filtering media_type by string

await wp.data.resolveSelect( 'core' ).getEntityRecords( 'postType', 'attachment', { media_type: 'image', per_page: 5 } );

Triggers the API call:

/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&context=edit&media_type=image&per_page=5&_locale=user

Filtering media_type by array

For example:

await wp.data.resolveSelect( 'core' ).getEntityRecords( 'postType', 'attachment', { media_type: 'image,audio', per_page: 5 } );
await wp.data.resolveSelect( 'core' ).getEntityRecords( 'postType', 'attachment', { media_type: ['image'], per_page: 5 } );
await wp.data.resolveSelect( 'core' ).getEntityRecords( 'postType', 'attachment', { media_type: ['image', 'audio'], per_page: 5 } );

Triggers an API call

/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&context=edit&media_type%5B0%5D=image&media_type%5B1%5D=audio&per_page=5&_locale=user

WP 6.9 (Gutenberg deactivated)

All work as above

WP 6.9 + Gutenberg trunk

All work as above

WP 6.9 + Gutenberg branch wp/6.9 (21.9.0)

All work as above

WP 6.9 + This Gutenberg branch fix/media-types-fix

All work as above

What I can see is that #73029 was never backported to Gutenberg wp/6.9

https://github.com/WordPress/gutenberg/tree/wp/6.9/lib/compat/wordpress-6.9

But that only has a bearing on whether arrays AND strings are accepted for media_type.

If a site is running WordPress 6.8 then strings are fine.

What I can see is that #73029 was never backported to Gutenberg wp/6.9

BTW we should do this cc @tellthemachines ?

Thanks @mikachan for getting this PR up so quickly ❤️

Did you manage to reproduce the bug in Core? If so, could you share the testing steps. I'm struggling to reproduce

What I can see is that #73029 was never backported to Gutenberg wp/6.9

Withdraw that please! It was only PHP files and nothing to do with packages.

Did you manage to reproduce the bug in Core? If so, could you share the testing steps. I'm struggling to reproduce

I'm unable to reproduce either. At least in theory, we shouldn't need to check whether it's a string, as the schema should be handling the coercion to an array. I.e. in core, for an array in the schema, rest_validate_array_value_from_schema handles sanitizing the value, which calls rest_sanitize_array, which handles wrapping / parsing into a list via wp_parse_list.... so by the time we're in prepare_items_query, I believe $request['media_type'], if it exists, should already be an array if the original request had media_type as a string (or comma separated list of values)

Thanks so much @ramonjd and @andrewserong for testing this and reporting back in such detail. I'm also struggling to reproduce this bug.

At least in theory, we shouldn't need to check whether it's a string, as the schema should be handling the coercion to an array

Based on this, I don't think we need this PR at all. Sorry for the false alarm!

Based on this, I don't think we need this PR at all. Sorry for the false alarm!

Can we close this PR?