Opened 22 months ago
Closed 22 months ago
#54989 closed defect (bug) (reported-upstream)
Download stats API returning unexpected results
Reported by: |
|
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
@
22 months ago
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
#2
@
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:
- https://api.wordpress.org/stats/plugin/1.0/qdsdqsd returns an empty array.
- https://api.wordpress.org/plugins/info/1.0/ebufskjfskdf returns a 404 with a helpful error message.
- https://api.wordpress.org/translations/plugins/1.0/?slug=eqfhuesffkhdsk returns an object with a single empty array.
#3
@
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!
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?