Advertisement
  1. Code
  2. Plugins
Code

Communicating With the WordPress.org Plugin API

by
Difficulty:IntermediateLanguages:

Over the last few weeks I have been wondering on how to possibly pull data about my plugins hosted on WordPress.org and display it on my website. The first thing that came to mind was "Web Scrapping" but quite frankly this is a lot of work, feels like going back in time, and is not something a good web citizen should do. In some cases, it could be illegal.

I then came across a plugin called "I Make Plugins", developed by Mark Jaquith, which did just want I wanted by fetching data from the readme.txt file of a plugin. It works great but since WordPress allows us to search for plugins directly from the backend and also to see our favorite plugins, I knew there was a better way (or The WordPress Way) and further searching led me to the WordPress.org API. No detailed documentation on this page, but enough to get started knowing there is an API to do this more efficiently.


WordPress.org Plugins API

The URL where all plugin search / update related calls are made is http://api.wordpress.org/plugins/info/1.0/. To get a quick idea of how this works, open this link in a browser and add your plugin slug at the end, e.g. http://api.wordpress.org/plugins/info/1.0/custom-favicon/ and see what is returned.

This browser-based GET request displayed all plugin information for the plugin "Custom Favicon" in the format below. By replacing the last path of the URL with the slug of your plugin you would be able to see details specific to your plugin.

Not very presentable, but hey, at least this is a good start to test if the API delivers plugin information quickly, which we can then display the way we like.

Until this point, most of what I was doing was just based on random trials. The only resource I could find was http://dd32.id.au/projects/wordpressorg-plugin-information-api-docs/ which tries to explain the various options and arguments that can be used when communicating with this API.

So How Does This Work?

To communicate with http://api.wordpress.org/plugins/info/1.0/ and retrive information you need to make a $POST request with 2 things:

  1. Post Action - such as, $_POST['action']
  2. Post Body - such as, $_POST['body'], which has to be a serialized object

The returned data from the API is an Object in all cases (except when visiting the API link from a browser). Even in case of an error, the returned data is still an object but with a single property, an error string.

My first attempt to retrive plugin information was something like this below example:

Example of Retriving Plugin Information Using wp_remote_post HTTP API

We will explain the code later but for now the above example code will return information about our plugin in the format shown below, in the event that everything works as intended:

If you just wanted to display the download count, you could add like this:

Note: This is just a test example and not intended to be used in actual projects as there is no error checking. If the slug is wrong or the connection to WordPress.org does not take place, the above code will display errors.

We can continue extending this example with error checking but is there a better way? And the answer is yes, with the plugins_api function.


The plugins_api Function

The plugins_api function is defined in wp-admin/includes/plugin_install.php.

Parameters

The plugins_api function accepts 2 parameters: $action and $args:

1. The $action Parameter

Which can be any one of these 3 options below:

  1. query_plugins
  2. plugin_information
  3. hot_tags

2. The $args Parameter

Arguments are optional, and if set, have to be a serialized object. Arguments for each action are different and are explained in detail later in this article.

Data Returned

The data returned depends on the action chosen. The action "plugin_information" returns a single object whereas the other two actions return an array of objects. In case of an error such as the absence of an action or slug parameter, the plugin_api function also returns an object with a single property "error" and a value (string) "Slug not provided" or "action not implemented".

An Example of Using plugins_api Function

We will now try the same example we used earlier but using the plugins_api function instead of wp_remote_post from the HTTP API.

The above code will return the data in the same way our previous example had. As you can see, this requires a few lines of code and a connection to the WordPress.org Plugin API, unserializing the returned object and initial error checking is all handled by the plugins_api function.

In both the examples above, we only used the "plugin_information" action and a slug with no other arguments as our intention was just to retrieve all possible information about our plugin.

2.1 Arguments for query_plugins

2.1.1. browse

It displays the list similar to http://wordpress.org/plugins/browse/popular/. The possible values are:

  • popular
  • new
  • updated
  • top-rated

2.1.2. search

The term to search for.

2.1.3. tag

Search plugins by a tag.

2.1.4. author

Search plugins from an author.

Note: Between browse, search, tag and author only one argument can be used at a time.

2.1.5. page (optional)

The page number of the results.

2.1.6. per_page (optional)

The number of results to display per page.

2.1.7. fields (optional)

Similar to plugin_information fields listed below.

Example of a query for the most popular plugins:

Returns an array of objects similar to what plugin_information returns.

2.2 Arguments for plugin_information

2.2.1. slug

The slug of the plugin for which we need to return information.

2.2.2. fields (optional)

By default all the fields from the readme.txt are displayed along with some additional fields such as the total number of downloads, rating and download link. However if you only need to retrieve just a few fields you can override this by sending in an array of key / value pairs, where the field is the key and true / false as the value depending on whether you wish the field to be returned or not.

Example of overriding fields:

The fields that can be overridden are:

  • added
  • compatibility
  • downloadlink (Note: that the actual key is "download_link" but to not return this data, we need to set the field as “downloadlink”)
  • donate_link
  • homepage
  • last_updated
  • rating
  • require
  • sections
  • tags
  • tested

2.3 Arguments for hot_tags

2.3.1. number

The number of tags to return. The default is 100.

hot_tags action example:

This will return an array of objects with the key being the tag slug and each object would contain:

  • Tag Name
  • Tag Slug
  • Count - The Number of plugins marked with this tag

Summary

Internally WordPress core uses the plugins_api function to display a list of plugins based on the keyword used for search, to retrieve your favorite plugins and also to display information about any specific plugin. By changing the action parameter, you can use the function to perform different tasks.

Information about the WordPress.org API is not widely available and the reason could possibly be to avoid abuse of the system, hence make sure your requests to WordPress.org API are limited and done in the right way. Use Transients to cache the data so you do not have to make a request on every page load.

In a future tutorial we will create a plugin with a shortcode to display your plugin download count.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.