Make WordPress Core

Opened 5 years ago

Last modified 4 weeks ago

#50012 assigned defect (bug)

REST API: Fields filter does not work with "object" collection responses

Reported by: timothyblynjacobs's profile TimothyBlynJacobs Owned by: sirlouen's profile SirLouen
Milestone: Future Release Priority: normal
Severity: normal Version: 4.7
Component: REST API Keywords: has-patch has-test-info has-unit-tests dev-feedback
Focuses: Cc:

Description

As reported in #core-restapi, trying to use the _fields parameter with the wp/v2/taxonomies route does not return the expected result. Instead, an empty set is returned.

http://trunk.test/wp-json/wp/v2/taxonomies?_fields=name

Looking into it, this happens with both the taxonomies and types route because they return an "object" collection response. That is, instead of returning an array, they return an object keyed by the taxonomy or post type slug.

{
  "category": {
    "name": "Categories",
    "slug": "category"
  }
}

instead of...

[
  {
    "name": "Categories",
    "slug": "category"
  }
]

This means that the wp_is_numeric_array check in rest_filter_response_fields to try and determine whether this is a collection response fails and it treats the response as a single object, and then ends up removing all the properties.

It appears that the _fields check inside of the controller itself work, it is just the "fallback" filtering that doesn't work and ends up corrupting the response.

A possible fix would be to somehow mark that a response has already been filtered, and rest_filter_response_fields does not need to be run. This would probably also be a performance benefit.

Change History (12)

This ticket was mentioned in Slack in #core-restapi by timothybjacobs. View the logs.


5 years ago

This ticket was mentioned in PR #250 on WordPress/wordpress-develop by johnwatkins0.


5 years ago
#2

Trac ticket: https://core.trac.wordpress.org/ticket/50012

This fixes support for the _fields parameter in REST requests for taxonomies and post types. These REST responses take the form of objects rather than arrays -- e.g. { category: { ...data }, post_tag: { ...data } } -- and the _fields filter was being applied to that final data set, filtering out the top-level items.

The _fields parameter is also applied earlier in the get_items logic to the nested objects themselves. This fix removes _fields from the request after that occurs and before the final response is processed.

### Alternatives

One alternative option is here: https://github.com/johnwatkins0/wordpress-develop/commit/b81852609627f32bd841754d005ccbea68495053 This adds a couple of new methods to the WP_REST_Request class. Another possibility I looked at was adding a filter at the beginning rest_filter_response_fields and adding a filter callback in the endpoint classes that have the nested object structure. But both those options do essentially the same thing as this PR with much more code.

The drawback to this approach is it doesn't automatically apply to new endpoints that have similar structures, but the other approaches I thought of don't either. It might be worth exploring an option in register_rest_route or somewhere similar to indicate that get_items for a given endpoint returns an object rather than an array and _fields filtering should not be applied to the final object, but I also think anyone building custom endpoints at this level can figure out their own workarounds.

#3 @TimothyBlynJacobs
4 years ago

#53543 was marked as a duplicate.

#4 @JeffPaul
22 months ago

  • Keywords has-patch needs-testing added

This ticket was mentioned in PR #8891 on WordPress/wordpress-develop by @SirLouen.


6 weeks ago
#5

  • Keywords has-unit-tests added

This is a refresh of #250

Trac ticket: https://core.trac.wordpress.org/ticket/50012

#6 @SirLouen
6 weeks ago

  • Keywords needs-unit-tests has-test-info added; needs-testing has-unit-tests removed

IMPORTANT NOTE

Please, if you are reading this before 6th of June 2025: don't solve this issue
I want to have it available for WordCamp Europe 2025 Contributors day (6th June 2025)

Test Report

Description

🟠 This report can't fully validate that the patch works as expected.

Patch tested: https://github.com/WordPress/wordpress-develop/pull/8891.diff

Environment

  • WordPress: 6.9-alpha-60093-src
  • PHP: 8.2.28
  • Server: nginx/1.27.5
  • Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
  • Browser: Chrome 137.0.0.0
  • OS: Windows 10/11
  • Theme: Twenty Twenty 2.9
  • MU Plugins: None activated
  • Plugins:
    • Test Reports 1.2.0

Testing Instructions

As explained in the OP message:

  1. Simply run /wp-json/wp/v2/taxonomies?_fields=name
  2. 🐞 Result: An empty JSON

Expected Result

  1. It should provide a key:value format with the stored name for each taxonomy available.

Actual Results

  1. ✅ Issue resolved with patch.
  2. 🟠 Unit tests are not providing coverage to the issue

Additional Notes

  • Unit tests are testing for the general case, but not for the specific case this issue is being reported

#7 @davidbaumwald
6 weeks ago

  • Owner set to SirLouen
  • Status changed from new to assigned

#8 @SirLouen
5 weeks ago

  • Keywords has-unit-tests dev-feedback added; needs-unit-tests removed

Improved Unit Tests to cover the issue in this report.

#9 @sandeepdahiya
5 weeks ago

Test Report

Description

✅This report validates that the indicated patch works as expected.

Patch tested: Patch-8891

Environment

  • WordPress: 6.9-alpha-60093-src
  • PHP: 8.2.28
  • Server: nginx/1.27.5
  • Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
  • Browser: Firefox 139.0
  • OS: Windows 10/11
  • Theme: Twenty Twenty-Five 1.2
  • MU Plugins: None activated
  • Plugins:
    • Test Reports 1.2.0

Actual Results

  1. Before the patch:returned empty results.
  2. ✅ Issue resolved with patch. Request to /wp-json/wp/v2/taxonomies?_fields=name returns
"category": { 
"name": "Categories" 
}, 
"post_tag": { 
"name": "Tags" 
}, 
"nav_menu": { 
"name": "Navigation Menus" 
}, 
"wp_pattern_category": { 
"name": "Pattern Categories" 
}

Additional Notes

Last edited 5 weeks ago by sandeepdahiya (previous) (diff)

#10 @SirLouen
5 weeks ago

  • Version changed from 4.8 to 4.7

I've been able to hunt this down to 4.7

This ticket was mentioned in Slack in #core by sirlouen. View the logs.


4 weeks ago

#12 @SirLouen
4 weeks ago

6.9.0 Milestone proposed during today's <bug-scrub>
More information

Note: See TracTickets for help on using tickets.