Themes search API returns invalid result when `per_page=1`

[danielbachhuber]

One of these isn't like the others:

• ​http://api.wordpress.org/themes/info/1.1/?action=query_themes&request[search]=p2&request[per_page]=1
• ​http://api.wordpress.org/themes/info/1.1/?action=query_themes&request[search]=p2&request[per_page]=2
• ​http://api.wordpress.org/themes/info/1.1/?action=query_themes&request[search]=p2&request[per_page]=3

Broke my builds like this: ​https://dl.dropboxusercontent.com/s/5py59qjnnu68qh8/2015-02-12%20at%208.08%20PM%202x.png?dl=0

[obenland]

The API uses a regular BB_Query to get its search results. These results are then checked for exact matches to be bumped to the top. In cases where the exact match happens to be on a subsequent page, that bumping obviously can't take place - leading to the unexpected result.

Unfortunately there is no great solution to this problem. We could ignore the per_page and page argument for search queries and do paging after the results were bumped, which would help in the case of P2 and maybe Responsive. But if there happens to be a theme called Black that is close to two years old, it will be buried under newer themes that might have the word "black" in their description.

[danielbachhuber]

What changed recently to cause this to break?

[obenland]

This: ​https://core.trac.wordpress.org/ticket/31115

The commit message reads:

Remove the overriding of the order_by for the API requests. The existing themes directory has its own code to handle the ordering, and this override was causing bad results by forcing only highest rated themes to the top, rather than best matching themes. The results now should match in the theme directories results on the site and in the returned responses.

[Otto42]

That didn't break this, that fixed a completely different problem.

The underlying issue is indeed that if you set the per-page results too low, then the expected theme won't be in the first page of results, and so it cannot be pushed to the top. So, don't set the per-page results that low. Nothing in core does that.

In the long run, this might be fixed by the new theme directory and new functionality in the API to use that directory (using WP_Query and such), but for now, per_page should probably never be lower than 8 or 10 or so. Core queries expect 30 per-page, I think.

[Otto42]

Also, the result for the per_page = 1 is not an invalid result. You're not asking for info about "p2" here, you're searching for it. The mercury theme is one of those search results. The breakage lies in the re-ordering that fails to properly occur when the per-page is set too low.

[danielbachhuber]

The underlying issue is indeed that if you set the per-page results too low, then the expected theme won't be in the first page of results, and so it cannot be pushed to the top. So, don't set the per-page results that low. Nothing in core does that.

Er, this seems like an API bug to me, not user error.

The breakage lies in the re-ordering that fails to properly occur when the per-page is set too low.

Right. It's a bug in the API.

If it's not a priority to fix, you can say that. I've come up with an alternative for now. I don't think calling it user error is appropriate in this regard though.

[Otto42]

I didn't say it was user error. I was telling you how to workaround it, and why we don't see it in any of the normal queries.

[obenland]

Is this still an issue? The output of all three queries seem fine?

[danielbachhuber]

I don't recall the original cause well-enough to confirm the issue is fixed 100% but the API response used to be incorrect and is now fixed.