Displaying Information of a WordPress.org Plugin on Your Website

In the first part of this article, we discussed how to use built-in functions to communicate with WordPress.org and retrieve plugin details.

In this tutorial we will put the theory in action to create a simple plugin which will allow us to display details of any plugin hosted on WordPress.org on our WordPress website using shortcodes.


Getting Started

I'm assuming that you are a plugin developer and know the basics, but if in doubt, I suggest reading the following two articles:

What Are We Making?

With this plugin we want to create a shortcode such as [mpi slug='my-plugin-information' field='version'] that can accept two attributes: "slug" and "field", then based on that we then retrieve and display information of any plugin hosted in the WordPress.org repository.

Creating the Plugin Base

Lets start by creating a folder named my-plugin-information in your wp-content/plugins directory. Inside it, create a file named my-plugin-info.php and paste the below code in it:

What Did We Do?

In the above code, we have created and initialized our plugin class DOT_MyPluginInfo. Inside it are the general blocks of any plugin, for example the __construct() method.

The function init_my_plugin_info is hooked to the init action so that it runs after WordPress is loaded but before any headers are sent. Inside the function init_my_plugin_info we have registered our shortcode using the add_shortcode function.

Note: To read more about add_shortcode, check out the Codex.

The above plugin now has enough code to be recognized by WordPress from the plugin dashboard. If you have already created a file as instructed you can now visit the Plugins page and activate this plugin.


Setting Up the Shortcode

Since we want the flexibility to choose which information we want to display about a plugin, we created a shortcode with two attributes. The first called "slug" will be used to specify which plugin's data needs to be retrieved. The second attribute "field" will be used to specify which exact piece of information about a plugin we need to display.

So, for example, if we want to display the number of times this plugin has been downloaded, we simply need to add the text below the post editor and the end result should be something like "Downloaded 100 times."

Using add_shortcode we registered our shortcode so that whenever the shortcode is found in the post content, the function render_mpi() will be called to process it. From now on, the rest of the code will be placed inside this function to handle our shortcode.

Processing the Shortcode With render_mpi()

To display plugin information we first need to process the shortcode to get the attributes. Add the code below inside the render_api function:

This extracts the two attributes "slug" and "field" if they are provided. Before going forward, we first check if values for "slug" and "field" exist, and if they don't, then we stop processing further.

The code above will check if "slug" exists, and if it doesn't, then it will return false. If "slug" does exist, it will proceed towards checking the "field" attribute. Since we are only creating a shortcode to display a specific piece of information about a plugin, checking if both attributes exist before processing further will save unnecessary calls to the WordPress.org plugins API.

Now if values for "slug" and "field" attributes are provided in the shortcode, we proceed forward by first sanitizing both values.

Storing Plugin Data in Transients

To avoid sending a request to WordPress.org every time a page containing this shortcode loads, we need to save the plugin information locally. This way, if you have placed more than one shortcode to display different details of the same plugin, we can then speed up the process by displaying data from the information saved locally on your website.

But what if the plugin updates and we continue showing old data? Well to sort that out, the quickest possible option is to save our individual plugin data using the Transients API and setting an expiry date on the data.

Another issue would be if you have shortcodes that are retrieving data about different plugins. If we store them with a single transient name, the result could be unexpected. To tackle this we give a unique name to the saved transients using the "slug" attribute.

Why Go Through All of This?

  • To save information about each plugin separately
  • To make fewer requests to WordPress.org
  • To load data faster by serving it directly from your own website

Let's proceed by first creating a variable $mpi_transient_name to save unique transient names based on the "slug" attribute.

Next we check, if the transient already exists:

If the transient exists, we then proceed towards displaying data based on the "field" attribute or else we use plugins_api to connect to WordPress.org and request the plugin information.

In the code above, we did three things:

  1. We connected to WordPress.org and requested the plugin information. The request is then saved in a variable named $mpi_info
  2. We then do error checking to ensure if data was returned without error
  3. Lastly we created a new transient with an expiration date of one hour

Now if the value of the slug attribute was "my-plugin-information" then the name of the transient that stores the plugin information would be "mpi-my-plugin-information".

Note: To learn more about plugins_api refer to the first article of this series, shown at the top of this post.

Displaying Plugin Information

The last step involves returning specific information based on the value of the "field" attribute. To do this we simply use individual checks.


Wrapping Up

Complete plugin code:

This plugin code is available on GitHub and you can also download it from WordPress.org


Putting It Into Action

Now you can simply go to your post editor and add a shortcode like:

And it will display:

Example Shortcode to Display Other Information About a Plugin

By replacing the value of the "field" attribute you can display different information such as:

  • Plugin Name: [mpi slug='my-plugin-information' field='name']
  • Plugin version: [mpi slug='my-plugin-information' field='version']
  • Plugin Slug: [mpi slug='my-plugin-information' field='slug']
  • Plugin Author (returns a name and link): [mpi slug='my-plugin-information' field='author']
  • Author Profile (returns the profile address): [mpi slug='my-plugin-information' field='author_profile']
  • Last Updated: [mpi slug='my-plugin-information' field='last_updated']
  • Download Link: [mpi slug='my-plugin-information' field='download_link']

Improvements

To keep things simple, I've used transients to save plugin information. Transients however, were never meant to be used for saving important data. An alternative method would be to save plugin data either using the Options API, add_options(), or as post meta and then schedule a cron task to update the data hourly.


What Next?

Using plugins_api we have demonstrated how easy it is to communicate and retrieve information of any plugin hosted on WordPress.org.

You might also want to look at other plugins such as Plugin Info (which also uses plugins_api, and I Make Plugins, to see how they have accomplished the same task.

Tags:

Comments

Related Articles