Make WordPress Core

Opened 5 weeks ago

Closed 3 weeks ago

Last modified 3 weeks ago

#65706 closed defect (bug) (worksforme)

REST API /wp/v2/posts returns empty array when using _fields parameter, even with clean core install

Reported by: liske1 Owned by:
Priority: normal Milestone:
Component: REST API Version: 7.0.2
Severity: normal Keywords: reporter-feedback close
Cc: Focuses:

Description

Environment:

  • WordPress 7.0.2, default theme (Twenty Seventeen active)
  • No plugins active (wp-content/plugins/ is empty except index.php)
  • No mu-plugins present
  • No object-cache.php, advanced-cache.php, or other drop-ins present
  • Application Passwords used for authentication
  • Confirmed reproducible with direct requests to the PHP container, bypassing all reverse proxies/CDN (Nginx, Cloudflare)

Steps to reproduce:

  1. Fresh-ish WP 7.0.2 install with existing published posts (confirmed visible via normal REST request).
  2. Authenticate as administrator via Application Password (Basic Auth).
  3. Request: GET /?rest_route=/wp/v2/posts&_fields=id Result: HTTP 200, body: []
  1. Request without _fields: GET /?rest_route=/wp/v2/posts Result: HTTP 200, full list of posts returned correctly.
  1. Also reproduced with unrelated fields: GET /?rest_route=/wp/v2/posts&_fields=title Result: HTTP 200, body: []
  1. Reproduced with the exact query used by the official WordPress mobile app (wordpress-rs / kotlin-okhttp client) during sync: GET /index.php/wp/v2/posts?rest_route=/&context=edit&page=1&per_page=20

&order=desc&orderby=date&status=publish,private
&_fields=id,modified_gmt,parent,menu_order

Result: HTTP 200, body: []

  1. Removing only the _fields parameter from request #6 (keeping context=edit, status=publish,private, pagination, etc.) returns the full expected dataset.
  1. Confirmed explicitly: request from step 6 without the _fields parameter (but keeping context=edit, status=publish,private, and all pagination params) returns the correct, full dataset. Adding _fields back in — regardless of which field(s) are requested — is the sole change that causes the result to become an empty array.

Expected behavior:
Adding _fields should only limit which keys are present in each returned
object — it should not cause the entire result set to become empty.

Actual behavior:
Any use of _fields (regardless of which fields are requested) causes the
endpoint to return an empty array, despite matching posts existing and being
otherwise retrievable.

Impact:
This breaks the official WordPress mobile app for self-hosted sites, since
the app's sync mechanism relies on sparse fieldsets (_fields=id,modified_gmt,
parent,menu_order) to check for changes efficiently. Users see "no posts" in
the app despite posts existing and being visible in wp-admin.

We've ruled out:

  • Reverse proxy / CDN caching (Cloudflare cf-cache-status: DYNAMIC, confirmed same result testing directly against the origin container on port 81, bypassing Nginx and Cloudflare entirely)
  • Active plugins (none installed)
  • mu-plugins (none present)
  • Object cache / custom drop-ins (none present)
  • Theme interference (default Twenty Seventeen active; leftover files from an unrelated advanced-ads theme folder exist but are not the active theme)
  • PHP fatal errors / warnings (checked docker logs, nothing logged for the failing requests)

Happy to provide further debug info (WP_DEBUG output, wp-config.php contents
minus secrets, etc.) if useful for reproducing/diagnosing this.

Change History (6)

#1 @kadamwhite
5 weeks ago

Thanks for the bug report. @liske1 Can you please provide a more complete test case? I've checked on one existing 7.0.2 site and two local environments (one using a custom Docker setup, one using wp-env) and in all three cases, _fields is behaving as expected when authenticating using an admin content token.

Any further details about your environment would help, because as it is I'm not able to reproduce this.

Edit: You specify "Twenty Seventeen active". Can you test on one of the twentytwenty series themes to rule out a theme-specific bug, please?

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

#2 @mindctrl
4 weeks ago

  • Keywords reporter-feedback added

I'm unable to reproduce on a fresh install of 7.0.2 with Twenty Seventeen, or any other theme, active.

#3 @kadamwhite
4 weeks ago

  • Keywords close added

Thank you for the additional reproduction attempt, @mindctrl.
@liske1 Leaving this open for a bit in case you can provide a clear reduced test case.

#4 @liske1
3 weeks ago

  • Resolutionfixed
  • Status newclosed

I don`t know what are you doing, but now mobile application works great, and nothing more I need now.

Thank you for resolve this issues even you nothing to do :D

#5 @jeremyfelt
3 weeks ago

  • Resolution fixedworksforme

#6 @sabernhardt
3 weeks ago

  • Milestone Awaiting Review
Note: See TracTickets for help on using tickets.