#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:
- Fresh-ish WP 7.0.2 install with existing published posts (confirmed visible via normal REST request).
- Authenticate as administrator via Application Password (Basic Auth).
- Request: GET /?rest_route=/wp/v2/posts&_fields=id Result: HTTP 200, body: []
- Request without _fields: GET /?rest_route=/wp/v2/posts Result: HTTP 200, full list of posts returned correctly.
- Also reproduced with unrelated fields: GET /?rest_route=/wp/v2/posts&_fields=title Result: HTTP 200, body: []
- 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: []
- Removing only the _fields parameter from request #6 (keeping context=edit, status=publish,private, pagination, etc.) returns the full expected dataset.
- 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)
#2
@
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
@
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.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
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?