Plugins search with countdown keyword does not work

[adamskaat]

Today I tried the search with one keyword (Countdown) but it's return nothing you can check this URL ​https://wordpress.org/plugins/search/countdown/

[netweb]

I believe this is most like as noted in #3327:

https://meta.trac.wordpress.org/ticket/3327#comment:3

...these plugins are not showing at or near the top for the same reason: they don't have the Tested up to: header set.
Setting that to a recent WordPress version (after testing of course!) should restore the expected behaviour.

https://meta.trac.wordpress.org/ticket/3327#comment:5

If a plugin doesn't have proper headers, and it hasn't been updated in a while, then it should be harder to find

The ​https://wordpress.org/plugins/countdown/ hasn't been updated in 6+ years

https://meta.trac.wordpress.org/ticket/3327#comment:6

I hear all the arguments for not wanting to surface older plugins to people who aren't looking for them. But there's still this specific case of knowing which plugin you want to install, and not being able to find or install it.

Searching ​https://wordpress.org/plugins/search/countdown/ results in no results found

I'm leaning towards that the search results should surface the countdown plugin rather than return no results though how that impacts search as a whole I'm not sure of and will defer to the meta eam members familiar with this.

[gibrown]

Should be all fixed now, and I've reindexed all plugins. Sorry for the slow fix I wanted to make sure I got enough review of the fix since it affects all of our indexing.

The root cause is kinda crazy.

The cause is:

1. A doc with post meta of "2e47eb" (this was on the beeketing plugin for the color code of the header ​https://wordpress.org/plugins/beeketing-for-woocommerce/)
2. In addition to indexing the string, we try to index all meta as a long and a float.
3. When php converts to a float, we get 2e47 (Whee!)
4. When php outputs 2e47 it becomes 200000000000000008769168609015239470926809530368.0 in the json. (Ugh!)
5. ES indexes this fine, it doesn't fail. (Hmmm)
6. Our search queries request a couple of fields beyond just post_id. Some of these fields are not "stored" so ES has to take the original _source json and reparse it to fulfill the request
7. The JSON parser for extracting fields though apparently does not handle these large values in the same way as the indexing parser. So 200000000000000008769168609015239470926809530368.0 is unparsable because it is so large and an error is thrown.

Ultimately the fix is to have better boundary checking on the fields when indexing.

Basically any search that was returning the beeketing plugin in the results was triggering this failure. "countdown" just happened to be one case. It looks like there was at least one other plugin that had this problem also. I can see from query logs that this fix has cleaned up a number of query failures (they were pretty rare, but had been getting more common). Not seeing any query failures now.

Thanks for reporting this.