DevTips – Scripts to Automate WordPress Plugin Development

A couple of weeks ago I read an article that I found extremely amusing (although it’s a couple of years old already): a programmer had written several scripts to automate most of his work, from sending mails to his wife with excuses about why he was still at work to automatically resolving support tickets from this tiresome customer by simply applying a rollback to his database and replying “No worries mate, be careful next time” ?. I have to admit: I’m a huge fan of this guy! Because task automation, my friend, is what any good programmer should always seek.

Why repeat the same action over and over again, if you can have a script that does the work for you? Automation saves you time–time you can devote to other more interesting or productive tasks: attending a customer, learning a new technology, correcting a bug, and so on. Automation also avoids mistakes: when you do the same job over and over again, it becomes tedious, repetitive, and boring, making it more likely to screw up.

In today’s post I would like to share with you some of the scripts we used in Nelio to automate the process of packaging and releasing new versions of our plugins. It’s not rocket science, but I’m sure you’ll find them useful nonetheless–they might also even inspire you to create your own scripts!

Repetitive Tasks when Creating a Plugin

Software creation is a craft. Sure, we apply methodologies in our work and we try to be as rigorous as possible, but writing software requires a certain amount of brilliance and talent–after all, a programmer has to express in a few lines of code the requirements of his users… it’s like poetry! But don’t be fooled by the craftsmanship of our job: many of the tasks you perform while creating and maintaining a piece of software are repetitive and can therefore be automated. Let’s look at some examples you’ve probably met several times before:

1. Minify CSS and JavaScript files. This is a pretty common task, specially if we split our rules and functions into multiple files and we have to concatenate and minify them all.
2. Generate a .pot file containing all the strings to translate. If you want your plugin to be used by anyone, you should definitely consider to follow internationalization rules. Usually, you’ll want to use WordPress’ i18n functions for that.
3. Run unit tests. We’ve discussed several times in this blog the importance of unit testing your code. There’s plenty of tools for doing that (including things like “continuous integration”), but you should at the very least be able to run your test suites effortlessly and make sure that everything works as expected before releasing a new version.
4. Upload and release new versions of your plugin. After a few weeks or even months of work, implementing new features, fixing bugs, and adding several improvements to your plugin, it’s time to release a new version. This means you’ll need to update your WordPress.org SVN repository with the new files, so that your users can see there’s a new version available.

As you can see, all the repetitive tasks you’ll do during the creation of a plugin are extremely simple and repetitive, which makes all of them perfect candidates to be automated. I’ve selected these examples because we already have a few scripts to automate them… and today we’ll share these scripts with you! ?

Time to Automate!

There’s plenty of tools to automate tasks–in our case, we’ll use Gulp and Bash scripts, and the scripts I’ll share will be written in these languages. But, please, feel free to use whatever tools you’re comfortable with–the important thing here is that you automate things, regardless of the specific language or tool you end up using. So, without further ado, let’s get started!

Gulp Scripts for JavaScript and CSS

One of the most common tasks we web developers perform is “script minification”. That is, we basically remove all the unnecessary spaces and characters from our code to save a few bytes. Well, in Gulp this is extremely simple:

Just add the required packages, create a new task that scans all JavaScript files (line 6), minifies them (line 7), generates the .min.js version (lines 8 and 9),  and voilà! Easy peasy! And the same applies to CSS files, of course:

If you take a closer look, though, you’ll realize that the task is slightly more complex than that of JavaScript. That’s because we’re using two different packages: CSS Next and CSS Nano. The former is a small utility that allows us to write CSS using “future rules”–that is, rules and statements that might not still be available in current browser implementations and, therefore, have to be translated to current CSS standards. The latter is the minification package itself.

Moving forward: one of the things that bothers me the most about working with source files and their minified versions is that every time I make a change in one of the source files I have to remember to properly minify it. Fortunately, Gulp includes a tool that detects when a change occurs in one of your source files and executes one or more tasks in response. In other words, I can tell Gulp:”hey, whenever there’s a change in any of these JavaScript or CSS files, minify it properly”:

Cool, huh? And, hey, once you get used to Gulp, there’s no stopping you. For example, I’ve created a couple of tasks to run unit tests in both my PHP and JavaScript files:

as well as to generate the i18n .pot file:

I love it! Here you’ll find the full script, so please feel free to download it, tweak it, and use it in your own developments.

Nelio Unlocker

Switch to WordPress safely while keeping your design and content

Improve your SEO today and boost your site speed by converting your pages into HTML, CSS, and WordPress standards. With zero technical knowledge required, you’ll only pay for what you need.

Try It Now

Bash Script for Releasing a New Version of a Plugin

As you know, after you first submit a new plugin to the WordPress plugin directory and it gets approved, you’ll be given access to an SVN repository from which you can continue its development and where you’ll tag its stable versions. The problem is that nowadays most developers use Git to work on their projects, so they’ll have to copy their plugin files from the Git project to SVN’s. In other words, we’re facing a repetitive task that, again, has to be automated!

The script we need to publish and release new versions of our plugin is pretty simple: we just need to know the new version number we want to use and the location of our SVN directory (we assume that we’re running it from the Git directory):

david@xps:~/vagrant/wordpress/wp-content/plugins/nelio-content/ $ 
./mkversion 1.5.0 ~/svn/nelio-content/

Now let’s have a look at the different phases this plugin has to automate:

1. Update README. Each time you publish a new version, you should update the README file. First you’ll have to modify the Stable Version (even though you might want to do that at the very end of the process, once you’ve made sure everything’s OK). Secondly, you’ll have to add a new section in the Changelog so that users can see the changes the new version includes. Finally, you’ll need to add a short line at the end of README with the Upgrade Notice briefly describing what’s new.

Our automatic script should help us in the previous tasks. First of all, we’ll automatically check if the README file contains an up-to-date Changelog section (that is, if it includes a list of changes for the version we want to tag as stable). If so, we’ll tweak it’s name so that it includes the release date (today) and we’ll update the Upgrade Notice:

Some of the variables (for instance, $version) or functions (like question or error) have been defined at the beginning of our script.

2. Run some basic tasks such as, for example, generating JS and CSS files, extract i18n strings into a .pot file, or updating version numbers in the plugin. Since we already defined most of them in our Gulp script, running them here is pretty straight forward:

3. Copy your Git directory to SVN’s trunk dir. Once everything’s ready it’s time to move the project from Git to SVN. The only important thing to remember here is not to copy some “unnecessary” files, such as the directories .git or node_modules:

4. Create a new version in tags based on trunk. The next step in our release process consists in tagging the current version as stable. In SVN, this is done by copying your trunk folder into a new folder in tags. You might also want to get rid of some “source” files here, just to make sure the size of the plugin is as small as possible:

5. Update SVN indexes so that SVN know which files are new, which files changes, and which files were removed:

Finally, the last step (which is manual) is to commit the project and thus upload it to WordPress.org. And that’s all! Here you’ll find the final script.

Now It’s Your Turn…

I hope you liked this post and that you can benefit from the ideas I shared. Do you have your own automations? Why don’t you share them with us? I’d love to see the tools and scripts you use!

Featured Image by Dominik Scythe on Unsplash.