No matter which tool you’re using, building, testing, packaging and deploying a WordPress plugin should be one command. That way when you’re dev testing, you are actually testing the whole process, including installation, activation and deactivation of the plugin’s zip file. grunt-shell and wp-cli are your friends. Use wp option liberally in your dev deployment code.

My Gruntfile.js describes all the steps needed between my code sitting in my working directory and the same code running in my WordPress dev environment.

Grunt alias tasks let you define this process hierarchically. Use them! I aim to model the process so that at some level it has some resemblance to steps from the waterfall model: build, package, test, and deploy are verbs that I always aim to define in my script. Then, at a lower level I can define which grunt plugins actually accomplish each step.

When you have defined the steps in this way, then you can begin to create builds of varying quality or for various purposes. Testing takes too long to run every time in your development cycle? Create a quick build that excludes it. Want to have separate builds with and without documentation included? Define another package verb. Want to create a deliverable package but not deploy it? Create a task that omits the deploy verb.

The following is from an actual project I’m working on. Don’t worry about the details. You have your own workflow. All I’m saying is that you will benefit from structuring your script hierarchically.

Here’s my increasingly verbose meme. Make it viral!

The post 🐗 Building WordPress plugins with an increasingly verbose Gruntfile appeared first on Alexandros Georgiou.

Don’t forget to add the TracGit link

Who doesn’t use git? Nobody, that’s who. And who doesn’t use trac? Well, actually, a lot of people. Nowadays Joomla seems to be all the rage. But trac is pretty cool and I use it for all the things! TracGit lets you setup your git repos so that you can link to your source from the trac tickets and wiki pages.

As we all know by now, it’s a very, very good habit to link to your source changes when you close a ticket. In fact, I get to do that all the time. And whether it’s a single commit, or a merge from an entire branch of commits, it’s almost always the last change that you want to link to. So here’s a bash alias that gives you the exact trac syntax that you can copy from the shell and paste into your ticket.

alias git-trac='echo [changeset:$(git log -1 --format="%h")/$(basename $(git rev-parse --show-toplevel))];';

It’s nothing fancy, but I find myself using it all the time so I decided to share. Add it to your ~/.bashrc, or better yet, to ~/.bash_aliases, if you’re the organized type.

One less step…

If you’re anything like me, you’re way too busy to copy and paste stuff. If only you could skip one of those two steps and save valuable time…

Luckily, you can automate the copy to clipboard part! First install xclip:

sudo apt-get install xclip

Then, your alias becomes:

alias git-trac='echo [changeset:$(git log -1 --format="%h")/$(basename $(git rev-parse --show-toplevel))] | xclip -selection clipboard';

Unfortunately, you’ll have to paste the string into trac yourself. If you’re thinking about automating that part, well, then I’ve got to ask, what’s wrong with you?

The post Bash alias to create a TracGit link to your latest commit appeared first on Alexandros Georgiou.