The process of building a plugin (a one day challenge)

Building plugins is fun, especially the smaller ones. Today I thought it would be a good challenge to build one whilst documenting the process; I’m actually writing this post as I plan and build the plugin itself with the hope of having it finished by the end of the day.

What am I building? A small post-series plugin so I can group all of my #WTBFB posts and allow navigation between them on my blog.

Bring on the challenge!

The planning stage

Probably the post important stage is planning – it can be tempting to start coding right away, but that’s not wise. I usually scribble down a rough plan, or at least the requirements, before coding. This saves time and confusion later on and gives you a set specification to work towards.

One other thing to check while you are planning things is the plugin name. I usually ensure I’ve picked a suitable name and checked if the repository is available prior to staring, otherwise you end up needing to go back and rename code, variables, and textdomains if the name is unavailable. I’m going with the plugin name wp-post-series which wasn’t taken amazingly.

So, the plan. I’ll be adding a new taxonomy called ‘post_series’. This taxonomy will be non-hierarchical, and will need to have a 1:1 relationship with posts. To summarize the requirements:

  • we need a new taxonomy called post_series.
  • we will need a meta box to assign a series term to a post with 1:1 relationship (a post can be in one series only). I’m thinking a select box.
  • add an admin column for showing the series assigned to the post.
  • add a filter on the posts admin page to filter by series.
  • ensure post # in the series is determined by date.
  • posts in a series will show an info box above or below the content, also with a next/previous navigation link and a description which will come from the term.
  • include basic styles only.

I’ll be keeping this plugin lightweight and simple, and I’ll be building it within a single class/file.

Building a minimum viable product

Next step is to get coding. It doesn’t have to be perfect at this stage and can be a MVP (minimum viable product) including only the key features needed. Just get something together which you can later test/enhance/polish/gather feedback for, before launching.

As I code, I commit my work to Github to keep things backed up and to keep a record of my development. For this project I made a public repository.


From start to finish I recorded my screen for fun. You can watch this below if you want (sped up).

You may notice I jump to and from windows a lot whilst coding; I re-use code from my projects a fair amount to save time. The more plugins you build, the more you’ll find yourself doing this because it doesn’t make much sense to rewrite everything every time.

I also have some snippets setup for common blocks of code, such as the plugin header. Easy to setup and saves some time. I use textexpander for this, and SublimeText also has some auto complete support for WordPress functions if you install an addon.

As I developed the plugin I did tests locally using Vagrant – basically just checking if what I was coding was working and ensuring there were no errors as I went.

You can view the full source code on Github here:

Final tweaks and testing

After coding, test, test, test. Enable WP_DEBUG mode, check for notices/warnings, sanity check your function and variable names, ensure the plugin is localised, and add any missing features you think would be beneficial in the final plugin.

You’ll also need to ensure you’ve written a readme.txt file containing details about the plugin before you can release it. This should be validated with the readme validator.

During this stage I did some more testing on my Vagrant install and wrote the readme file – feature wise, there was nothing more I needed to add at this stage.

The end result

You can actaully see the plugin working on now for any post I’ve made for the ‘blogging for benjamin’ competition. Look above the content. You’ll see it shows the name of the series, the series description, and links for other posts in the series. I’ve styled it using CSS to match my theme, but aside from the styling it’s all down to the plugin.

Lauching it publically

After coding it’s time to get it on To do this you need to go to the ‘add’ page which is here. You’ll need a link to your plugin’s zip file, and a readme in order to submit your plugin for approval.

I submitted a request for a repository and while waiting approval I created my plugin banner ready to commit:


When the repository was approved, I tagged my release on Github, then pushed it manually to SVN trunk (as well as uploading the screenshot and plugin banner to an ‘assets’ directory. This is what my repository looked like at that stage:

2013-12-30 at 23.22

Then it was just a case of ‘duplicating’ the trunk to tags/1.0.0 and does the rest. It is now live:

WP Post Series on


Post launch I’ll just be monitoring bug reports and seeing if there is any feedback which could shape the future direction of the plugin. I’ll be using it on my site for future series too which will ensure it’s well maintained. Job done 🙂

Challenge yourself

Building a plugin in a day is a neat challenge because it really makes you think hard about the ‘core’ features needed – you don’t have time to add bloat, so you are more likely to build something lightweight and to the point. Plus, it can really help you brush up your skills and get some time-saving tricks in place. I personally discovered some bits in core, such as the meta box callbacks, I never knew existed so I’ve learnt a lot.

Bare in mind, I could have used an existing plugin for post series, but I really wanted something lightweight and tailored to my own needs. I’m sure others may find it useful too, even if it’s just to hack apart and see how it works.

Next time you need a feature for your site, give it a go!