In response to: “If only I had written some.. Sorry! -DD32″ – My tagline i left in the Plugins API for WordPress
(This was a copy-paste job from an email i sent to the wp-hackers list: http://comox.textdrive.com/pipermail/wp-hackers/2009-January/023505.html)
Some basic documentation for the Plugins API: http://api.wordpress.org/plugins/info/1.0/
Note: The request should look something similar to this: $_POST['action'] = The action to perform, $_POST['body'] => A Serialized Object (with properties which are explained below). The return values from the API should be a Object in all cases (Except if you visit it via a browser with a GET request with no valid action, Then it’ll return the bbPress friendly page)
Actions:
query_plugins
plugin_information
hot_tags
query_plugins
Accepts an object with a property of either:
browse – A bbPress View to “browse”, eg, “popular” = http://wordpress.org/extend/plugins/browse/popular/
search – The term to search for
tag – Browse by a tag
author – Browse by an author (Note: .org has a few plugins to extend the author search to include contributors/etc)
Other properties which the object can have:
page – the page of the results (duh..)
per_page – the number of results per page
fields – This is a bit.. odd.. an array of which fields to return, the API has defaults for requests, but it can be overridden from the client, send an array with the field as the key, and true|false as the value to return or not, The fields are: ‘description’, ’sections’, ‘tested’ ,’requires’, ‘rating’, ‘downloaded’, ‘downloadlink’, ‘last_updated’ , ‘homepage’, ‘tags’
return array of objects:
An array of the same object that plugin_information returns
plugin_information
Takes an object with the property:
slug – The slug of the plugin to return the info for
fields – once again, Optional, Same deal as in the previous action, just its got different defaults (ie. this one will return all the sections of the readme, whilst the previous will only return the short description)
return object:
name – The plugins name
slug – the plugins slug
version – The latest version
author – The Author of the plugin – If a URL is available for the author, This will be a link
The following fields are optional, And are returned based on the fields param
requires – The required WordPress version
tested – The highest tested compatible WordPress version
rating – returns the % rating (ie, 10%, 100%) as a number. (This is displayed on .org as a 1-5 scale)
num_ratings – If ratings is requested, this will be returned as well, Its the number of people that have rated the plugin
downloads – the number of times the plugin has been downloaded
last_updated – the date that the plugin was last updated, Excludes the time
homepage – The URL of the plugin
description – The short description of the plugin(s)
sections – An array of readme sections, ie. array( ‘faq’ => ‘FAQ… blah blah my plugin is great.. blah blah’, ‘installing’ => ‘fgfg…. If no readme sections are found, It returns array(‘description’ => (description field here from above) )
downloadlink – The Download Link for the plugin (Theres a bug in this at present, Any version with a space in the URL returns the wrong URL: #8610
tags – an array of array( ‘tag_slug’ => ‘Tag Name, ’slug2′ => ‘Pretty Butterflies’)hot_tags
Takes an object of:
number – The number of tags to return, Defaults to 100
return array of objects: (key will be tag slug)
name – The tags name
slug – The tags slug
count – The number of plugins
Final note, The API may also return an error object in the case of an error, It’ll be an object with a single property:
error – A Error string, ie. “Slug not provided” or “action not implemented”
Does/can the “query_plugins” action also have “downloaded_today”, “downloaded_this_week”, and “downloaded_this_month” parameters?
Or rather, “today”, “yesterday” and “last week” as it appears on a plugin’s stats page: http://wordpress.org/extend/plugins/all-in-one-seo-pack/stats/
No it doesn’t, There was no reason to include it in the API at the time.
Theres an XML file somewhere which the graph pulls the data from, You could probably use that to get the download count for each date..
Hmm, I don’t think that would fly when trying to retrieve stats for multiple plugins.
I’m working on a GET interface for your POST API ( http://api.uproot.us/1.0/ ), and one of my original goals was to be able to show the average downloads from creation date (total_downloads / days_since_creation).
Any chance you could add some of the following parameters to the API’s “query_plugins” action? :: created, downloaded_today, downloaded_yesterday, downloaded_last_week. Maybe we could work something out instead if you’re busy. If I just had SELECT access to the DB, I could fully flesh out / document the GET API and pass you the source. Let me know your thoughts.
Unfortunately, I don’t have access to change the API, and as it is, Its pretty much staying as it is until a new requirement is needed for the next version of the API (And as it is, General users accessing the API doesn’t appear to be a valid use case)
So i don’t think i can help you there :/
You could create a ticket on trac (under the component ‘WordPress.Org’ and see if anyone’s interested..
Ok, thanks.