Deploying WordPress Plugin With Github Using Transients

Share on Facebook
Share on Twitter
Share on Google+
Share on LinkedIn
Pin to Pinterest
Share on StumbleUpon
What's This?

Being a wordpress developer, you may have tried to write a plugin and most of you guys do that to develop a custom theme or make your code better. I think your goal is catch the attention of a lot of people with your plugin. As you have an opportunity to use the WordPress Subversion repository, you could host a plugin yourself. By doing this you may provide something better to your users. In that case you need something to have your users’ code in sync in different sites. All I am saying is you should use a Git workflow not Subversion. So, here I am telling you how to deploy wordpress plugin with Github using transients.

Whatever you want to do, the first thing important is to know what exactly you are doing and how you want to proceed. In this article you will know how you should do things step by step. The first step is to know about transients and how they are connected with WordPress. After that a PHP class will be built to house all of your code. The next job is to connect the plugin to Github. After all of these the interface elements will be created to have your users getting access to your plugin. After finishing this article hopefully you will be able to create a proper plugin that will update directly with the help of Github releases. Let’s get to it.


Let’s Know About WordPress Transients 

If you don’t know what wordpress transients are then let me tell you that they are entry of data and their duration is fixed. That means they have an expiration time and they get removed when they are expired. Particularly they are used by WordPress to store data about all of the plugins that are installed. WordPress repeatedly refreshes the stored data for checking the Subversion repository for updated plugins.


Let’s Start

Setting up the updater class:

Create a class name and a constructor at first. As we are updating a wordpress plugin, we need to know some basics about it. The version number is important. We will pass the path of main plugin file into our updater. The reason to do it is WordPress use the main plugin file’s path as a unique identifier to store plugin information. Then we assign the value to a property. The code for that process is given below:

Set Up GitHub 

Setting up GitHub should be started by creating a repository for the plugin. The dictionary structure is important because the files will be pulled from here. The plugin folder should not be the root of your repository, be careful about it. Earlier in this article I’ve said that knowing the version number is important. You should know how to check it on GitHub in various ways. It may be done by pulling the main file and looking over the contents. But the best way to do it is using the built-in release functionality of GitHub.4

In that case you need to fill out some fields. Among those fields the Tag Version field is most vital where the current release version of the plugin will be put. After that we need to use the semantic versioning format for our field and the main plugin file. After doing the jobs accordingly you will get your release. Then you will create a zip file by clicking the Publish Release button that wil be used in our updater script. You may repeat this process for a new plugin release how many times you want. At last for checking the version number we’ll use the GitHub API.


Connecting Updater To GitHub 

We need to add some codes to do complete the connection. At first some more properties are needed to hold the repo information and another one  for holding the response from GitHub.

After that setters will be added for the new properties:


The setters we added helps us to update usernames and repositories without disturbing the updater class. If you want your user to register, all you need to do is change the repo to a pro version of the plugin. In that case you need to add a conditional statement. Let’s see:

To get the version tag from GitHub we need to write the code below:


Modify WordPress 

After collecting information about our plugin and connecting to the repo we need to modify WordPress so that we may find our new data and put it where it belongs. To complete the task at first we should modify the output of the WordPress update transient. Then we have to update the WordPress interface in order to show our plugin informations properly. Last of all we need to make sure that our plugin is working properly after the update. But before, we have to know how to hook into the transient.


How to Hook Into the Update Transient 

Two filters and two actions to inject our code:


The main difference between the tags is the word site. This distinction changes the scope of our injected code which is why it is important. Without the word site tags will only work on single-site installations of WordPress; and with that word tags work on both single and multi site installations. You will choose which one is needed for you.

Look at our initialize function:


Three filters were added in the example. We talked about three steps earlier to update to modify WordPress. In the example above we can see that all the three steps were maintained accordingly. Then this method is needed to be called in our plugin to initialize the updater script. The code is given below:


After writing the code the method will run and the filters will be active. If you want your plugin to update automatically then the initialize method is a good option for you.


Write the Code for Filters 

Let’s start with the modify_transient method:


In this case the version number is taken from our main plugin file. Then it is compared to the number that we gave our release on GitHub. If the number is higher than it understands that newer version is available. 12

If you tries to see the version details then you will get an error message from WordPress. Because  WordPress is trying to find it’s detailed information from it’s repositories. We have to put the information by ourselves. Now look at the next method, plugin_popup:


This is a normal thing. It’s about checking if WordPress is looking for data about our plugin if it does, returning the array of data. We received the data from the GitHub response. In that array of data you may put any information you like including HTML.


Take a look at our final method, after_install:

Two things happened here. One of them is setting of an argument named destination, which is simply the directory that keeps our new code installed. We are delivering the main plugin file’s data to be root of the plugin. And secondly, a checking is done to find out if the plugin was activated using the property set by us earlier. If it is active before updating, it will be reactivated by our method.



At the end of this article I am hoping that you are able to update your plugin Just remember that your plugin’s version must update to match the latest release which is in the main plugin file. If you didn’t update your version in the comments your plugin will always look for updates. So, be careful and happy coding


Share on Facebook
Share on Twitter
Share on Google+
Share on LinkedIn
Pin to Pinterest
Share on StumbleUpon

Leave a Reply

Your email address will not be published. Required fields are marked *