Adventures in Plugin Authoring

Adventures in Plugin Authoring

In late 2013, I was working on a website for a local band. In the project specs, they made a simple request: display their Instagram feed in the sidebar. Initially I didn’t think much of it, but once the time came to implement that feature, I found myself at a bit of a loss. While many WordPress plugins existed to display Instagram feeds, they were all either broken (due to a recent Instagram API update) or horrendously complicated. Lightbox dependencies, slideshows, carousels; all I wanted to do was display some images. I found a couple premium plugins that seemed to suffice, but who wants to spend money? My dad’s mantra in life is “for that price, I’ll make it myself!” So in the end I decided to take his advice and make my own plugin:

I called it Simple Instagram.

step01

While I’ve used a lot of WordPress plugins, and have plenty of experience in PHP, I had never developed one from scratch before. My first step, then, was to find a good framework to start from. After a big of googling, I came upon an officially-endorsed plugin Boilerplate by Tom McFarlin:

https://github.com/tommcfarlin/WordPress-Plugin-Boilerplate

The boilerplate has a lot of great features, including singletons, built-in security, and a robust file structure. This all seemed like a great fit, so I cloned the boilerplate and got started with my code.

A quick sidenote: in retrospect, I honestly think that the boilerplate may have been overkill for the small plugin I developed. While the built-in security is nice, the granular file separation and structure really wound up being more bloat than anything. If you’re thinking of developing a plugin yourself, I’d recommend reviewing the boilerplate in order to determine if it’s a good fit. If not, there are other, simpler frameworks out there that may be a better choice.

step02

Now that I had my framework, I started work on the basic structure. Instagram uses a pretty standard OAuth setup, which means it involves some redirects and token sending. I wanted to keep all of this on one page, so I decided to have it all occur within an iframe so the user never had to leave the settings page. The whole process can be confusing, especially to a novice user, so I formatted the process as a list of steps. In theory, the user would simply follow the steps from 1-3, and at the end they’d receive a confirmation message that they were connected to Instagram.

With these guidelines in mind, I started work on getting everything set up. In a relatively short amount of time, I had a working prototype. As a user, I was able to follow the steps from start to finish and wind up with a valid connection to Instagram.

One thing I noticed in my tests is that the process involves a lot of copying/pasting of random strings from WordPress to Instagram and vice-versa. Particularly vexing is the redirect URI, which if not copied exactly (including trailing slashes) will cause the whole process to break. I’ve always really liked how GitHub has a “copy to clipboard” button for their clone links, so I decided to use the same functionality for this. As it turns out, there are some security restrictions on Javascript that stop you from accessing the user’s clipboard, so the workaround actually implements a Flash solution (insert shocked face here). While this made me considerably uncomfortable (Flash is hardly a well-supported system any more), I eventually decided that if it’s good enough for GitHub, then it’d be good enough for my plugin.

Once I had the copy-to-clipboad functionality in place, I moved on to making the third step (actually connecting WordPress to Instagram) into an iFrame. This left me with a bit of an issue: for the most part, WordPress pages are generated with dynamic URLs, whereas the redirect URL for Instagram needs to be a static page. I eventually wound up creating a PHP file that included wp_head and using it as my iframe source. I did a few tests and quickly had an easy-to-follow, working system to add Instagram to my WordPress install.

step03

Once I had the connection issues taken care of, it was time to setup ways that the user could actually implement their Instagram feed. I had determined through my own use-cases that I wanted to have both shortcodes and widgets available. The shortcodes were easy enough to set up – all it took was adding a shortcodes includes file and defining the various codes I would use along with their parameters. The widget was a little more involved – I had to set up a custom class with methods for the widget frontend, admin form, and update routines. Thankfully the WordPress Codex has working examples for each of these, so it was a relatively painless process.

Again, my goal with the plugin was to make it as simple as possible. With that in mind, I wound up including the following shortcodes and widgets:

  • Feed – Used to display a set number of images/videos from your personal feed
  • Profile – Used to display your personal profile information (username, avatar, etc.)
  • Popular Posts – Used to display a set number of the most popular posts on Instagram

step04

From here it all came down to tightening up the workflow and polishing the display. Since the plugin is free, I wasn’t too concerned with making it overly beautiful, so I opted for a simple, plain display with some subtle borders and light backgrounds.

Once I had everything looking as I wanted and had put the plugin through some testing, it was time for what was (to me) the most anxiety-inducing part: getting ready to submit the plugin to the WordPress Plugin Repo. Since I was using the boilerplate, there were several functions built in that I wasn’t using, as well as some replacement tokens that I needed to get rid of, so I went through and trimmed out as much as I could.

Finally, WordPress requires a fairly standardized Readme.txt file with every plugin, so I grabbed a template and filled it out as best as I could. One note about the Readme file: WordPress uses it’s own version of Markdown, so be sure to look it up in the codex before writing your readme. I used standard MD syntax and had to go back and change everything, so it’s much easier to just get it right the first time.

step05

At long last, with files zipped and Readme in hand, I logged onto WordPress.org and, mouse trembling, submitted my precious code for review. There was a decent-sized queue waiting to be reviewed, so I settled in for a long wait.

The next morning, I awoke to find an email from the Plugin Review team in my inbox. I nervously opened it, trying to keep my hopes in check but secretly wishing for the best. Then I saw it:

“Unfortunately, at this time…”

My heart sank as I had flashbacks to pretty much every girl I asked out in highschool. My plugin had failed. It was the end. WordPress just wanted to remain friends. All that work down the drain.

Then I kept reading.

“Unfortunately at this time we recommend that plugins not include any templates which require wp_head as it can cause issues if the user has an alternate file structure. Instead we recommend displaying the iframe with content from an Ajax call. Please update this template and reply with the new code for further review.”

Relief flooded over me. It was a relatively simple fix. I updated it, zipped up my new code and sent it on. Within a couple hours I received another email, this time with the holy grail: my access credentials for the WordPress Plugin Repo.

My plugin has been on the Repo for a few weeks now, and so far it’s been a great experience. People seem to be using it fairly often, and I’ve received a few positive reviews. There were a few hiccups – the plugin would error out if you tried to deactivate it (whoops), secure sites had issues with the redirect, etc., but overall it’s been going really well.

While building the plugin, I learned a lot of things. Obviously I learned a lot about coding and file structure, but I also learned a lot about the WordPress community as a whole. The plugin reviewers are friendly and helpful; users appreciate quick support responses and will reciprocate with positive reviews; advanced users are legitimately willing to review your code and offer advice on how to improve it. I could go on and on.

The overall experience was incredible, and is one I recommend to anyone looking to sharpen their WordPress skills. Plus, at the end of the day you wind up producing something that has the potential to really help people out while becoming closer to a great community of developers. It’s a true win-win.

You can find the Simple Instagram plugin on the official WordPress Plugin Repository.

  • I recently made my first ‘proper’ WordPress plugin too and can relate to a lot of what you are saying. However, mine’s was ‘premium’ but had to go through a third party approval stage too. Mockingbird is a post relationship plugin that allows you to manually display related posts.

    I tried to create some in depth documentation, to help more basic users as well as more knowledgable ones. The plugin provides a sort of mini API, for developers to be able integrate it into a theme or set up custom instances etc. I found this process in particular helped me develop a better plugin. Not only in creating better code, but in terms of how I thought users would want to use it and what options/features they might want. I actually ended up taking longer than expected, through thinking of extra features and improvements as I was documenting.

    Another thing I had to contend with was the WordPress 3.8 update, which was released practically the day before I was planning on submitting to CodeCanyon. Functionality wise everything worked ok, it was really just styling issues I had to address (CSS changes, using icon font etc.), and ended up making it pre-3.8 compatible.

Leave a Reply

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

Sign Up

Sign Up for our newsletter here. We’ll send you cool WordPress tips, tricks, and news. No spam, we promise.

  • This field is for validation purposes and should be left unchanged.