REST API index does not respect fields

[spacedmonkey]

Follow on from [53760].

The REST API index, that can be found at /wp-json, does not respect fields param.
Take this API request for example.

/wp-json?_fields=name

Links are still prepared and returned.

{
  "name": "Test site",
  "_links": {
    "help": [
      {
        "href": "https://developer.wordpress.org/rest-api/"
      }
    ]
  }
}

[spacedmonkey]

Pinging @dlh who worked on the original patch in [53760].

[dlh]

Thanks for the ping! I agree, this seems like an oversight in [53760]. I'm going to assign it to myself to try to address in 6.3.

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

## Description
This PR introduces validation for the _links field in the _fields query parameter. If the _links field is present, it will be appended to the response object. Otherwise, it will not be included.

#### Test Case

###### Case 1

• URL - /wp-json?_fields[]=name&_fields[]=_links
• Name & link both available

###### Case 2

• URL - /wp-json?_fields[]=name
• Name available

###### Case 3

• URL - /wp-json?_fields=name
• Name available

###### Case 4

• URL - /wp-json?_fields=name,_links
• Name & link both available

[niravsherasiya7707]

Hello @dlh , I have verified and applied the patch. Kindly review it on your end and let me know if any further changes are required. Thank you.

[spacedmonkey]

@dlh Where are we with this ticket? Do you think we can get this in 6.3?

[dlh]

@spacedmonkey I've reviewed the latest PR, and it still doesn't seem like the right direction to me, but I haven't taken a closer look yet. I'm hoping to do that after wrapping up #41692. Since this is a bugfix, do we have a bit more time before it has to be punted?

[oglekler]

I have doubts that it can land into 6.3. From my point of view, we need to cover this with a unit test, and also I left a comment for PR.

@spacedmonkey please consider what needs, possible and realistic this moment.

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

[spacedmonkey]

@oglekler @dlh I put together a quick PR for this. Took a little longer than I thought.

​https://github.com/WordPress/wordpress-develop/pull/4784

CC @dlh01

Tests fail.

I'm interested in the fact that this patch seeks to prevent the links being added (which is convenient, since we already have access to the current $request in this code), whereas ​https://github.com/WordPress/wordpress-develop/pull/4483 comes at it by trying to avoid generating the links. Do we need some code on both sides?

If we can get the tests passing on this patch, I'm 👍 on at minimum not _adding_ them when we can avoid it, regardless of whether we also pursue something more like the other patch later on.

@kadamwhite Sorry for pushing up unit test fails. Should be fixed now.

The idea of this ticket is two fold.

1. Respect _fields=links and not return that in the response.
2. No prepare the links in the first place, saving database / cache lookups.

See ​https://github.com/WordPress/wordpress-develop/commit/b7bae6936a9ad54f85bad7e5a73a9d110190d927 for referennce, where we did this for other endpoints.

[mukesh27]

Thanks @spacedmonkey for PR, it looks good at first glance, but upon further review, there are some changes and feedback that need to be addressed.

[spacedmonkey]

Assigning to @kadamwhite for final review.

Isn't this a breaking change? If someone used ?_fields=xyz before, they got the links for free. Now they have to use ?_fields=xyz,links to get the same behavior.

This was already a problem in 6.1 when this was added to all the other REST controllers.

I'd be wary of making such a breaking change that late in the cycle.

Isn't this a breaking change? If someone used ?_fields=xyz before, they got the links for free. Now they have to use ?_fields=xyz,links to get the same behavior.

This was already a problem in 6.1 when this was added to all the other REST controllers.

I'd be wary of making such a breaking change that late in the cycle.

@swissspidy
The fact that links are returned even when they are not requested, is a bug. You do not request this data and is generated and returned anyway. If you don't do anything, just hit the index, you still will get links. The only change is behaviour here, is if you request /wp-json?_fields=name, links will not be returned. By why would expect the links to be there, you didn't request them.

The only change is behaviour here, is if you request /wp-json?_fields=name, links will not be returned. By why would expect the links to be there, you didn't request them.

Because that was the existing behavior ever since WordPress 4.7.0. It just worked. This bug fix will break this behavior, simple as that. Even if it's not documented and not intended.
If you remember, we had the exact same problem with 6.1.0 when this change broke REST API usage in the Web Stories plugin. But that ship has sailed now.

Don't get me wrong, I don't have a problem with making this change, as it was already changed for all the other controllers and the index controller isn't used as much. I just like to point out that now is very late to do this change. I suggest doing this early in the 6.4.0 cycle instead.

[spacedmonkey]

After a slack conversion with @swissspidy @TimothyBlynJacobs, it seems like this is too late to commit in WP 6.3. I am punting to WP 6.4 and adding early.

[hellofromTonya]

I'm doing an audit of all tickets marked 6.4 early. What is early ​The handbook explains the keyword as:

This keyword should only be applied by committers. The keyword signals that the ticket is a priority, and should be handled early in the next release cycle.

early means the commits need to happen during the early part of the Alpha cycle; else, the ticket gets bumped.

A change here could have impacts. A longer period of time is needed for extenders awareness and to test and give feedback. The longer period helps to raise confidence while giving time for further adjustments if additional changes are needed.

Thus, yes, I do think this ticket is an early candidate.

[spacedmonkey]

Now we are in 6.4, can we look to review and commit this ? CC @swissspidy @TimothyBlynJacobs

[spacedmonkey]

In 56566:

REST API: Avoid unnecessarily preparing item links REST API index.

Building upon the changes introduced in [53760], this commit refines the behavior of the REST API index. Specifically, it addresses performance concerns related to the unnecessary preparation of item links, such as site icon and logo links.

Prior to this update, the index controller was invoking the prepare_links method regardless of whether the _links or _embedded fields were requested in the response. This led to unnecessary database lookups and decreased overall performance.

In this commit, we implement a more efficient approach. Now, the prepare_links method will only be called when the _links or _embedded fields are explicitly requested in the response. This optimization ensures that we prepare links only when they are intended for inclusion in the API response, reducing unnecessary overhead.

By implementing this improvement, we enhance the overall efficiency and performance of the WordPress core REST API index controller.

Props spacedmonkey, niravsherasiya7707, dlh, mukesh27, costdev, swissspidy.
Fixes #57902.

Committed https://core.trac.wordpress.org/changeset/56566

Committed https://core.trac.wordpress.org/changeset/56566

[spacedmonkey]

This change should be called out in dev notes / field guide.