Themergency fooplugins.com

Plugin Auto Updates From Github

| 2 Comments

This is day 15 of my WordPress Developer Advent Calendar.

I have been uploading a lot of code lately to Github in both my personal and FooPlugins accounts. I love Github. It makes collaboration so easy, and I am starting to move all my WordPress.org plugins over to Github so others can fix bugs and add features. One project on Github which you have to check out is Tom McFarlin’s WordPress Plugin Boilerplate. If you read the docs, you will see that it supports the Github Updater.

Github Updater Showcase Plugin

So I thought I would take this updater for a spin and create a showcase plugin that uses both the Boilerplate and the Github Updater. You can find it on Github : GitHub Updater Showcase. I used my grunt-init generator for the boilerplate to get a head start. These are the steps to follow to create a boilerplate plugin with the github updater integrated:

  1. Create a new directory in your local WordPress install under wp-content/plugins.
  2. In that new directory run grunt-init wp-boilerplate (to get this setup read my previous post).
  3. Follow the prompts to generate a new plugin using the boilerplate.
  4. Download a zip of the github-updater code and extract it somewhere. This project handles updates for themes and plugins but we only care about the plugin updater code.
  5. We only want our plugin to do update checks while in the admin, so we need to copy 2 files from the classes directory in the zip, to our generated directory wp-content/plugins/{{PLUGIN-NAME}}/admin/includes. The files to copy are:
    class-github-updater.php
    class-plugin-updater.php
  6.  Back in the admin directory, open the file class-{{PLUGIN-NAME}}-admin.php (this file is only included and executed while in the admin)
  7. Clear the code that is in the constructor function __construct, and add the following code:
    private function __construct() {
        require_once 'includes/class-github-updater.php';
        require_once 'includes/class-plugin-updater.php';
        new GitHub_Plugin_Updater;
    }
  8. At this point, commit your plugin to a new Github repo.
  9. Copy the Github repo URL and make sure that your plugin header points to the correct URL. In my showcase plugin, it looks like this:
    GitHub Plugin URI: https://github.com/bradvin/github-updater-showcase
  10. Bump the version number in your plugin’s header and commit the changes again.

Test An Auto Update

The plugin updater is a very slick piece of code, and you do not need to play around with git tags and releases at all. It looks at the version number in the plugin header and compares that to your locally installed plugin. So to test this, simply edit the local plugin header and change your version number to something lower than what is in the repo. Then goto your WordPress Updates page in the backend and click “Check Again” (sometimes I have needed to click this button up to 3 times). You should then see something similar to this:

github-updater-showcase

 

Showcase Plugin

If you are lazy and do not want to follow the above steps, then simply download my github-updater-showcase plugin and install it. Then change the version number in the header to 0.0.1 to test it updates to version 0.0.2.

How To Contribute Code To WordPress

| 0 comments

This is day 14 of my WordPress Developer Advent Calendar.

There are a number of ways you can contribute back to WordPress. Tom McFarlin also blogged about it recently, and in summary you can:

  • Contribute to the Codex documentation.
  • Submit a translation.
  • Chime in on the support forums.
  • Participate in the IRC chats.
  • Submit code.

Obviously, the last one interests me the most, as I write code. I mentioned in a previous post that I wanted to contribute some code back to WordPress, to enhance the gallery shortcode. And today, my fellow readers, I finally did what I have been wanting to do for ages - I contributed a patch back to WordPress core!

Steps To Follow

If you want to contribute a new feature, enhancement or bug fix, you can follow these steps that I took:

  1. Create a login for WordPress.org - if you have plugins on WordPress.org or have ever used the support forums then you already have a login.
  2. Install a SVN client - I use Tortoise SVN (Windows) but there are Mac equivalents: SmartSVN or Versions or many others.
  3. Download the latest WordPress source - do an SVN checkout from http://svn.automattic.com/wordpress/trunk.
  4. Install and Run WordPress locally - using the source from step 3, get a local instance of WordPress running.
  5. Make your core changes! - make the necessary additions or changes to the core files and test everything is working as expected.
  6. Create a patch - using Tortoise to make a patch is as simple as right clicking the modified file or folder and choosing TortoiseSVN -> Create Patch.
  7. Submit a Trac ticket - read up on submitting bugs, and then create a new ticket. Be as descriptive as possible.
  8. Upload your patch - immediately after submitting your ticket, add your patch file as an attachment.
  9. Hold on to your pants - now wait to see how your ticket will be received.

My Contribution

I submitted ticket #26623: Make gallery_shortcode more customizable. It’s a small enhancement to the gallery_shortcode function which outputs the HTML for the built-in galleries. I included some code to make it easier to style and also makes it much easier to override from plugins and themes. I went a bit overboard with my ticket and gave a huge explanation including code samples. I also pointed to a Github repo where I have committed a demo plugin which used the newly proposed changes.

Support My Ticket

If you have worked with the gallery at all, then you will understand why I submitted this ticket. It is simply too hard to customize the default gallery at this point in time. Making any changes means you have to override the entire function, including all of it’s logic. My goal with this patch, is to keep this logic in place and hidden, while still allowing for complete customization of the HTML code. Plugin and theme authors should love this change! Support this chance by adding a comment to my ticket.

Make Your WordPress Plugins Extensible

| 0 comments

This is day 13 of my WordPress Developer Advent Calendar.

Sometimes see your plugins being used in the strangest ways. Ways that you never intended it to be used when you initially designed the plugin. It is a good feeling to have, when you see your plugin being used and making customers happy. It gives a great sense of accomplishment. But you can make it even easier for your customers to alter the way your plugin works. All without touching a single line of code in the original plugin, after it has been released.

It all comes down to how you write the plugin and where you provide “hooks” so that it can be extended or changed. There are many plugins that do this already: WooCommerce and Easy Digital Downloads are great examples. The very fact that they have craploads of extensions, tells you that they are very extensible. This is how they do it:

Actions and Filters

Everything you need to know about actions and filters you can read up about on the Codex.

Actions

An action is a PHP function that runs at a very specific time. In a nutshell, actions allow you to “inject” code in between existing code without having to alter the original code. For example, you have some code that publishes a post on your blog, you could “hook” into the save_post action and send an email to all subscribers. You could do this with the following code:

add_action( 'save_post', 'send_awesome_emails_to_the_people' );

So why not allow for the same type of extensibility from your own plugins? For example, your cart plugin processes a discount code. Fire off an action after the code has been applied:

do_action( 'discount_code_applied', $discount_code );

Someone can now write a plugin that hooks into that action and logs each time the discount is applied:

function log_discount_code_usage($discount_code) {
   //do something here with $discount_code
}
add_action( 'discount_code_applied', 'log_discount_code_usage' );

Filters

Actions allow you to run code at specific times. Filters allow you to alter or even replace existing data. So in your plugin scenario, you declare an array of names that you show in a dropdown. Instead of just returning your array, rather wrap the result with apply_filters, for example:

$array = array(
   'Name 1' => 'Bob',
   'Name 2' => 'Jon'
};
return apply_filters('awesome_names', $array);

And then in a separate plugin, you can hook into that filter and add a third name:

function add_third_awesome_name($names) {
    $names['Name 3'] = 'Susan';
}
add_filter('awesome_names', 'add_third_awesome_name');

A Few Actions and Filters Go a Long Way

I hope you can see just how easy this is to do. With very little code, you can make your plugins extremely extensible. It could save you stacks of time from a support point of view, and not to mention, it will keep your plugin lean.

Do not build every new feature your users may suggest. Rather tell them to extend your plugin with their very own extension :)