Make WordPress Core

#54989 closed defect (bug) (reported-upstream)

Download stats API returning unexpected results

Reported by: pyves's profile pyves Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: HTTP API Keywords:
Focuses: Cc:

Description

The download stats API endpoint documented [here](https://codex.wordpress.org/WordPress.org_API) is returning unexpected results.

Consider the following API requests:
https://api.wordpress.org/stats/plugin/1.0/downloads.php?slug=definitely-not-a-real-plugin
https://api.wordpress.org/stats/plugin/1.0/downloads.php?slug=100
https://api.wordpress.org/stats/plugin/1.0/downloads.php?slug=sadikovtdjoiybvjtdoivgrdjashc

As you'll probably have guessed, none of the above plugins exist, yet the API is indicating up to several hundred daily downloads. This makes me wonder whether the API can be trusted at all, even for valid plugin slugs.

Change History (3)

#1 @Otto42
22 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

There is no valid reason to request data for a plugin slug that does not exist. Therefore, it doesn't matter what we return for such requests.

So, if we intentionally return fake or nonsense data for fake or nonsense requests, what is the actual problem?

#2 @pyves
22 months ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

Requesting data for a plugin slug that does not exist is not necessarily intentional.

As an example, I'm looking at badges provided by Shields.io (https://github.com/badges/shields). We support one that displays the number of WordPress plugin downloads (e.g. https://img.shields.io/wordpress/plugin/dd/bbpress). When building the badge URL, users may make a typo or a mistake when copy-pasting the slug from somewhere. After all, they're only human.

As the Wordpress API isn't returning a 404, an empty response, or a 0 download result, we've got no way of telling whether the returned data is trustworthy. As pointed out, it may be fake or nonsense in a non-explicit manner. We could have surfaced the user mistake by displaying a badge stating "plugin not found", like we do for dozens of other services we integrate with. Instead we've got little choice but to render a healthy-looking badge, which is misleading and a poor user experience.

Worth noting that only the downloads stats API seems to behave like this. All other Wordpress endpoints I've checked do something more sensible when an erroneous plugin/theme slug is provided:

#3 @SergeyBiryukov
22 months ago

  • Resolution set to reported-upstream
  • Status changed from reopened to closed

Hi there, welcome to WordPress Trac! Thanks for the ticket.

Please note that this Trac is used for enhancements and bug reporting for the WordPress core software. Any issues on WordPress.org sites, including the plugin APIs, should be reported on https://meta.trac.wordpress.org.

I've transferred the report to #meta6061. Thanks again!

Note: See TracTickets for help on using tickets.