Keep reading to find out how to use gulp with your WordPress themes to speed up your development and stay on the bleeding edge.

What is gulp?

gulp is a Node.js based task runner, similar to Grunt, but built for speed and efficiency. gulp uses Node streams, meaning it can build faster as it doesn’t need to read and write temporary files as it pipes things through the tasks. If you want to learn all about streams, check out this great write-up on Github. Breaking it down, gulp allows you to configure your actual tasks, such as processing your styles or processing your JavaScript, with code instead of configuring each option by itself.

It makes sense to look at how it works compared to Grunt, since that’s how I wrapped my head around gulp.

How is gulp different than Grunt?

I first saw a great comparison of Grunt and gulp from Mark Goodyear and my interest was piqued. What really clicked for me was seeing that I’m writing one block of code to process my CSS, one block of code to process my images, and another block of code to process my JavaScript. Compare that to Grunt, where I’m configuring Compass and Autoprefixer separately for my CSS, Uglify and JSHint separately for my JavaScript, and Imagemin for my images. Instead of configuring a plugin, you’re writing short, manageable blocks of code that are logically separated based on what you need to do with your development environment.

Let’s dive right in and see how to use gulp for developing WordPress themes.

Using gulp with WordPress Themes

I have two WordPress starter themes setup that I use and you can watch, fork or download as well: one for use with most WordPress themes and one for use with the Genesis Framework. The master branch on Github currently uses Grunt, as broken down in my article on Using Grunt for WordPress Theme Development and Deployments, but there are separate “gulp” branches for each configured to use gulp tasks (WordPress Starter Theme gulp branch / Genesis Starter Child Theme gulp branch). I plan on merging the gulp branches into the master branch at some point in the near future as I plan on using gulp going forward.

First, make sure Node and gulp are installed on your system, and then create a package.json file in the root of your theme to define your dependencies.

View the code on Gist.

[* Please note, package.json is subject to change. Check my Grunt WordPress and Drupal repositories on Github for the latest versions]

With that in your theme, you can then open the theme folder in your Terminal and run:

npm install

This will tell NPM to download all dependencies and put them in a node_modules folder. Now we’re ready to create our gulpfile.js.

View the code on Gist.

[* Please note, Gruntfile.js is subject to change. Check my Grunt WordPress and Drupal repositories on Github for the latest versions]

We first load all of our plugins and setup the livereload server. You’ll need to install the LiveReload browser extension to connect, which you can get for Chrome, Firefox or Safari. Next, we setup our tasks for our stylesheets. The gulp.src of the tasks defines which files will be processed when the task runs. Here, we specify all SCSS files inside assets/styles/source (but not files in subfolders). We then use Node.js piping to take those files and process them with SASS, run Autoprefixer to put in vendor prefixes as needed, copy the files into a build directory uncompressed, then minify the stylesheets and place them in the theme root, as well as triggering a LiveReload in the browser.

Instead of configuring SASS, Autoprefixer, Minification and LiveReload separately, we have them all piped together in code block for our stylesheets. For me, this is so much more logical and easier to use, maintain and extend. Plus, piping makes it extremely fast!

Separate script processing blocks are setup for vendor plugins and app/site scripts to spit out plugins.min.js and main.min.js files. In those blocks, we’re concatenating plugins and scripts, running them through JSHint to check for syntax issues and Uglify to compress everything, and then copying files to proper destinations and triggering a LiveReload.

Images are processed in the next gulp task, where any new images are passed through Imagemin to compress JPG, GIF and PNG images down before triggering a LiveReload. The cache plugin makes sure that images aren’t processed multiple times, so you don’t need to worry about tasks bogging down every time you add a new image.

You’ll notice that each task has a notify plugin associated at the end, which triggers an operating system notification to let you know the task is complete (in Mac, it’s in Notification Center). You can safely remove them if you don’t want to be bothered every time gulp processes a file.

We next setup our watch task, where we’re monitoring files for changes and triggering our appropriate gulp tasks as needed. Lastly, we define our default task to run each of the tasks initially and then start watching our files for changes.

To get going, fire up your Terminal and navigate to your theme directory and run:

gulp

Gulp could use more tasks

One thing you might notice that’s missing from gulp here compared to my Grunt setup is deployments. Right now, there is no rsync task for gulp to deploy files. There is a really nice FTP deployment task from Sindre Sorhus that’s available to use if FTP is your deployment tool. Being that gulp is still early in its life cycle, the plugin community is still growing and developing content that people need. I fully expect all of the best Grunt plugins to be ported over to gulp shortly as it seems that the JavaScript community is moving in that direction.

Wrap Up

I’m really enjoying gulp as a task runner, particularly for speed and efficiency of setting up the gulpfile. Yes, WordPress Core uses Grunt for development now, and the beauty of both systems is that you can use either wherever you choose. I have both installed on my Mac and use both daily for multiple projects. Grunt v0.5 looks to bring Node.js streams and piping into play, which will make the JavaScript task runner landscape even more interesting. For now, I’m a big of gulp!

This post "Using Gulp for WordPress Theme Development" was featured on Matt Banks - thoughts on web development

View the code on Gist.

If you want to target IE7 or below, you can add those classes in as well (I’m only targeting IE8 here since I don’t support IE7 and below).

This code is part of my base Genesis Child Theme on Github as well.

This post "Adding Conditional Classes to the HTML Tag in Genesis 2.0" was featured on Matt Banks - thoughts on web development

Theme Links

WordPress Starter Theme on Github

Genesis Starter Child Theme on Github

Drupal 7 Starter Theme on Github

All three use SCSS and Compass for preprocessing and are setup with the same Gruntfile and folder structure to keep things clean. If you’re looking for recommended plugins/modules, check out the Readme’s for each repository for what I use on most projects. More information and instructions can be found there as well.

Feel free to clone, fork, create an issue and send pull requests with anything you’d like to see changed or added!

Using Grunt with the WordPress and Drupal Themes

Just as a quick recap, to use Grunt with the themes, open the theme directory in your Terminal and run

npm install

Once that installs all dependencies, just run

grunt

which will start the watch tasks to monitor and update your files as you go along. Your SCSS will be processed and your JavaScript will be linted, concatenated and minified. Image optimization and rsync deployments are there as well – refer back to my article on using Grunt for WordPress deployments for how that works.

If you have any questions or suggestions for using Grunt with your CMS, leave a comment or send me a message on Twitter or App.net.

This post "WordPress and Drupal Starter Themes Using Grunt on Github" was featured on Matt Banks - thoughts on web development

There are plenty of options if you’re looking to use CSS preprocessors and JavaScript linting in your development workflow, but none as flexible and extensible as Grunt. In the past, I used CodeKit to handle all of this work, but Grunt has since taken over, giving me additional options such as deployments with greater control over the entire process. With one JavaScript file in the root of my WordPress theme, I can control Compass output paths, JSHint options, UglifyJS concatenation and minification, setup browser live reloading and multiple server deployments, allowing for easy expansion and adaption as things continue to change and grow.

Keep reading to find out how to use Grunt with your WordPress themes to speed up your development and allow you to deploy your code to your servers.

What is Grunt?

Grunt is an elegant task runner from Ben Alman written in Node. In it’s latest version 0.4, Grunt has become an elegant wrapper for any task you can imagine. There is a large community behind Grunt with many  contributed plugins that you can add to your projects. Whether you’re looking to create a full build process or just watch files for changes, Grunt has you covered.

I’m not going to get too in depth on how to install Grunt – check out their Getting Started guide for getting up and running on your system.

What Can Grunt Do?

There are countless tasks that Grunt can do for you, but in this case, we’re going to focus on those that will help our WordPress theme development: Compass preprocessing, JSHint to check out JavaScript, UglifyJS to concatenate and minify all JavaScript files, Watch to watch files for changes, trigger our tasks and LiveReload the browser, ImageMin to optimize all PNG and JPG images, and Rsync to deploy our files to remote servers.

All of this is accomplished by adding two files to your theme, a package.json to define which Grunt plugins to use as dependencies, and a Gruntfile.js to define our tasks and options. For more information on getting that all setup, my friend Jonathan Christopher has a great article about using Grunt with WordPress.

Using Grunt with WordPress Themes

Before we begin, I’d like to note that I have two WordPress starter themes setup that you use: one for use with most WordPress themes and one for use with the Genesis Framework. Both utilize all of the Grunt tasks we’re going to go talk about in this article, with plenty of theme functions and grids to get you started.

Let’s get going, shall we? Make sure Node and Grunt are installed on your system, and then create a package.json file in the root of your theme to define your dependencies.

View the code on Gist.

[* Please note, package.json is subject to change. Check my Grunt WordPress and Drupal repositories on Github for the latest versions]

With that in your theme, you can then open the theme folder in your Terminal and run:

npm install

This will tell NPM to download all dependencies and put them in a node_modules folder. Now we’re ready to create our Gruntfile.js.

View the code on Gist.

[* Please note, Gruntfile.js is subject to change. Check my Grunt WordPress and Drupal repositories on Github for the latest versions]

We first setup the livereload task, but give it no options (you can change the port here if you feel the need). [Update: This is now handled the Watch task.] You’ll need to install the LiveReload browser extension to connect, which you can get for Chrome, Firefox or Safari. Next, we give JSHint our options for how to lint our JavaScript and tell it which files to check in the all setting, followed by configuring Uglify to create source maps and concatenate and minify our files. In my setup, I have it automatically pull assets/js/source/plugins.js and all files inside assets/js/vendor other than Modernizr and put them into assets/js/plugins.min.js, as well as taking our main.js script and minifying.

Next, we tell Compass to use the settings in our external config.rb file for processing our SCSS. I chose to break config.rb out into a separate file instead of putting the options directly inside the Gruntfile.js in case I wanted to use the Compass ruby gem directly or use CodeKit, as both will work using the config.rb file.

The next section sets up Regarde for our watch task to monitor for changed files and triggering our tasks. The reason for using Regarde instead of Grunt Watch is that Watch doesn’t give access to changed files because it spawns tasks in subprocesses, which doesn’t play nice with LiveReload. It’s essentially a drop-in replacement, so swapping back to Watch won’t be an issue if the way it spawns processes changes. We tell Regarde to fire the compass and livereload tasks whenever an SCSS file is changed, and to fire jshint, uglify and livereload whenever a JS file is changed.

[Update: Watch now works with LiveReload and has it built in, so the above Regarde code is swapped out for Watch. It’s essentially the same code, we’re just adding an option to LiveReload the browser.]

The last task for this section is imagemin, which doesn’t automatically run as file are changed, but run manually with:

grunt imagemin

This will run OptiPNG and jpegtran on your images to optimize them before you deploy to save on bandwidth.

At the end of the Gruntfile.js, we load all our tasks and register our default task. To run Grunt, at the terminal, just enter

grunt

Now, let’s get right on the most fun part: using Grunt to deploy your theme to your servers.

Deploying Your WordPress Theme with Grunt

There are a number of deployment choices when it comes to Grunt tasks. You can use SSH to connect and run commands or transfer files over SFTP, you can use FTP to transfer files if you don’t have SSH access, or you can use Rsync to sync up your directories over an SSH connection. After trying all three, I settled on Rsync as it provided the best and quickest way to update my theme files on the servers I use most. I typically have SSH or SFTP access, so it’s not an issue for me, but if you have only have FTP access, it’s trivial to swap out the Rsync plugin with the FTP plugin for your deployments. I’ve used this method for client sites in the past and it works seemlessly.

In our Gruntfile.js, we have two servers setup: staging and production. Each sets the source as the root of our theme project locally and sets a destination and hostname for our remote server. Setting recursive tells rsync to traverse all subdirectories to make sure we’re getting all of our files, and syncDest will delete any files on the remote server that no longer exist in your local repository. I’m excluding a number of files as they aren’t needed for the theme to run on the server.

To trigger a deployment, at the Terminal, enter:

grunt rsync:staging

or

grunt rsync:production

And like that, you’ve now deployed your files to your server!

Wrap Up

I’ve changed over my deployments to using Grunt now instead of setting up Git post-commit hooks and bare repositories. Having the general framework in Grunt makes it quicker than configuring post-commit hooks on multiple servers, and it works just as well. With so many tasks available to extend and customize Grunt, it’s an invaluable tool for any development process.

This method can be easily tweaked to work with any development process, from Drupal themes to ExpressionEngine sites to static site builds and use in other systems. I love the flexibility of Grunt and plan to keep using and evolving my Gruntfile going forward. I hope you do the same!

This post "Using Grunt for WordPress Theme Development and Deployments" was featured on Matt Banks - thoughts on web development

Old Process: Write each theme from scratch

Back in the old days, I would create a new folder and start coding a theme from scratch, adding every file as needed. Thinking back, I want to smack myself for writing the Loop in every template over and over, but I was young and things were just starting out for me in WordPress. Some of you may still be in this boat, and I would recommend moving up as soon as possible to speed up your development.

Moving in the right direction: My starter theme

It didn’t take long for me to create a starter theme to use on all sites. At first it just lived in a folder on my computer, then in Dropbox, and then it went up on Github when I started using git for version control (which everyone should be doing). It’s gone through many iterations, adding new functionality, refactored code, and streamlined the whole process.

In its current form, my starter theme uses Compass and SASS (specifically SCSS) for all of the CSS wizardry – preprocessors make things so much easier, so I recommend checking them out if you haven’t yet. I added in a responsive grid framework from Chris Coyier, broke out most of the content into template parts, and built out theme functions to define everything I think is needed as a starting point for a new theme. Feel free to clone or fork it on Github and send pull requests with anything you think might make it better!

This technique has worked well for me, but then I found Genesis and it will be powering the vast majority of projects going forward.

Genesis Framework: My new process

Enter Genesis Framework, the core theme from StudioPress. After hearing great things on Twitter from well respected WordPress developers such as Bill Erickson and Jared Atchison, I decided to pick up a copy for myself. I grabbed the Minimum child theme with it (which is what powers this site) and went to town digging into the documentation, reading the source code, and adding functionality. I immediately loved what I saw – Genesis is rock solid!

In addition to the security and speed of the platform, it offers a full grid setup that I can easily implement to speed up theme development. With the numerous hooks available, it’s easily to drop in any additional content or modify things for any output needed. You can also change the page layout on the fly on a per-post/page basis, which makes it very easy for clients to tweak settings without breaking their site. It’s updated frequently, adding features, hooks and functions to make developing with Genesis even better.

To make things even quicker, I adapted my WordPress Starter Theme for Genesis and put it up on Github – fork it and contribute with anything that might make it better for everyone!

Genesis fits my development style perfectly. The support included when you buy Genesis is also top notch, so if run into any issues, StudioPress is there to help you out.

Where do we go from here?

The one current limitation of Genesis for my development style is that it doesn’t have native HTML5 support. In my Genesis Starter Child Theme, I have an HTML5 doctype in place, but it’s still not using header, nav, section, aside, footer and other HTML5 elements I typically use. There are ways to override each area in Genesis to use the elements, but I decided to leave it be since these are all coming in version 2.0 in the near future, so this won’t be an issue for much longer. My plan going forward is to use Genesis on every WordPress project I can, which should be all of them once full HTML5 support comes in version 2.0.

I would highly recommend buying a copy of Genesis if you do theme development for clients or yourself. It’s only $59.95 and you get updates and support for the life of the product, which is worth every single penny!

This post "Genesis Framework: My new WordPress Starting Point" was featured on Matt Banks - thoughts on web development

I read a lot of code examples and blog posts while searching for this technique and a few things never clicked for me, so I wanted to highlight the process for anyone that might have been in the same boat as me.

Before we start, let’s get some requirements out of the way:

• You have SSH access to your server (if you have shared hosting, make sure you can get SSH access)
• Git is installed on your local machine and on your server
• You have a local git repository already setup with your code (I’ll be using a WordPress theme as an example)

I’m using a Mac for local development, so if you’re using Windows, things will be slightly different in how you access the command line.

What’s this Capistrano thing?

Capistrano is a terrific deployment tool build on Ruby. You can use it to automate deployments, quickly roll back to previous versions, etc. I spent a good part of a day learning Capistrano and what it can do, only to find out it won’t work with shared hosting environments very well. Why is that?

Well, Capistrano creates a directory structure in your deployment location (using /public_html as an example):

public_html
-- releases
-- shared
-- current (symlink pointing to your latest deployed code in /releases)

The problem here is that to effectively use Capistrano, you need to change your Apache settings to point the DocumentRoot to /public_html/current, which isn’t possible with most shared hosts (or most hosts running cPanel). So, while it’s a great tool, it’s not the tool for what I need.

Git Remotes to the Rescue

You should be aware of git remotes by using Github, Bitbucket or some other repository management system. It’s a way to push your code changes somewhere offsite for sharing, collaboration, backup, etc. With any repository, you can add as many remotes as you’d like. So let’s get right to it.

In this example, I’m going to use a WordPress theme as my deployment code. I’m not using the entire WordPress structure as the repository for a few reasons (simplicity in the case of this example, and also for needs of the client website that I’m developing).

Here’s a look at the local repository:

To create your repository, open Terminal (or iTerm 2, which I strongly prefer) and navigate to your code directory:

cd your-project
git init
git add .
git commit -m "initial commit"

We’re now ready to create a remote repository. I’m using a shared hosting environment with Bluehost for this example deployment, where I have an SSH connection setup with public key authentication. The big thing to remember here, which took me a while to grasp, is that the remote repository you’re going to push to will be a separate directory than the actual WordPress theme we’re deploying. Locally, the repository is always the code directory, but for remote deployments, we need to do things a bit differently.

So, let’s connect to our server (replace your user details and directory structure). We’re going to a create a folder named repos outside of the public_html directory that will house our remote repositories.

ssh user@example.org
mkdir repos && cd repos
mkdir your-project.git && cd your-project.git
git --bare init

We’ve now created a bare repository on our web server that we will use as our remote location. Still with me? We’re getting closer! The next step is to setup our post-receive hook. This is a script that will run every time you push code to the remote repository. Here’s how to set that up (I’m going to use vim, but you can use any editor you choose – you’ll run this while still connected to your server by SSH):

vim hooks/post-receive

Now, put this code into your post-receive file (replacing the path with the full path to where you want the code deployed).

#!/bin/sh
GIT_WORK_TREE=/home/myuser/public_html/wp-content/themes/mytheme git checkout -f

After that’s done, you’ll need to give the post-receive file execute rights so it’ll actually do the work:

chmod +x hooks/post-receive

[UPDATE: Thanks to Martin Sjåstad for pointing out I forgot the chmod +x line!]

That’s it! We’re now ready to deploy our code by just using:

git push

Let’s Deploy that WordPress Theme

Back on our local machine, let’s add our server to the git remote (replace myserver with whatever name you’d like to give the remote and add your login credentials):

cd your-project
git remote add myserver ssh://username@your-website.com/~/repos/your-project.git
git push myserver +master:refs/heads/master

Your code will now be pushed to the bare repository you created, and then the post-receive hook will checkout the code to the location you specified. In my case, that’s my theme directory:

/public_html/wp-content/themes/mytheme

To update your code later with a new push, just run:

git push myserver

That wasn’t so bad, was it?

While it might be daunting for those new to version control, it’s really a quite simple process once you wrap your mind around keeping your bare repository separate from your deployed code. I’ve used services like Beanstalk in the past for deployments, but decided I didn’t want to pay for that when I can do it myself easily from the command line.

Hopefully this helped some of you that were in the same position I was while setting up remote deployments. A lot of credit is due to an article I found from Abhijit Menon-Sen. Also thanks to Mubashar Iqbal, Jack McDade and Jonathan Christopher for tips. If you have thoughts on how to do this better, by all means let me know in the comments or send me a message on Twitter (@mattbanks).

This post "Managing WordPress Theme Deployments with Git" was featured on Matt Banks - thoughts on web development

I’ve been using WordPress for a number of years now. What started as hobby has turned into a business, as Kernel Creative Media uses WordPress for the majority of our projects. Seeing as I’m constantly writing PHP, CSS and JavaScript to extend and customize the content management system, I figured it’s about time I start giving back. Yesterday, I decided that I would begin contributing to WordPress core. What all does that mean? A lot, actually.

History with WordPress

My first foray with WordPress came about 7 years ago, before I really knew much about the platform. I wanted to write a blog, which no one ended up reading (hopefully people read this, but that’s another can of worms). Then I started Loot Ninja, a video game reviews and editorial website, and we chose WordPress as our platform. It was pretty sparse at first, just grabbing some off the shelf themes and plugins. As time went on, I wrote a couple custom themes, functions and plugins to suit the site’s needs. Fast forward to today, where client projects for Kernel Creative Media are bending and shaping WordPress in ways I never would have imagined in those early days. I’ve used more content management systems than I’d care to count and I always come back to WordPress as my go-to favorite.

Deciding to contribute wasn’t just an “oh, I’ll do that” decision. It requires time and dedication to make the platform and code better. The first thing I did was read up on the ways to contribute to WordPress. I already participate in the IRC chat (I’m “mattbanks” on Freenode), and post occasionally in the Support Forums, but I wanted to do even more, so I decided I would take a look at WordPress Core and see if I could work and test any patches. There are some caveats if you’re in a similar situation, which are all fine by me. You have to be familiar and comfortable working from the command line. You have to be able to articulate and document bugs and patches. You have to be patient enough to know that anything broken can be fixed. I feel it’s time for me to help.

As you’re reading this, keep in mind that I’m a beginner at contributing to WordPress. If you’re a seasoned vet, you’ll know this already, but I wanted to document my experiences so others might join in and contribute as well.

Subversion on Mac – It’s Just That Easy

If you’re running Windows, I’m sorry. I’m a big Mac fan and use them both at work at home. Things are just easier and the tools you need are readily at your disposal. And with a Mac, checking out the source code with Subversion is a snap. One of the WordPress lead developers, Mark Jaquith, has a lovely tutorial for getting setup quickly on his blog. The gist of is that you want to create a folder to house the WordPress files (I made one on Dropbox so I can use multiple machines easily), and then run the following command from Terminal:

svn co http://svn.automattic.com/wordpress/trunk/ .

Note the space and period at the end there. When I first ran the command without them, a sub-folder called “trunk” was created to separate the trunk branch from any other branches I might check out. Since I’ll only be working from trunk, having it an extra folder level deep isn’t necessary, so I started over. Once I had the files downloaded, it’s just a matter of updating my local files before I start any work. A simple command from Terminal takes care of that:

svn up

So why use Terminal for all of this instead of an app like Versions or Cornerstone? Being a comfortable git fan who uses Tower, Github’s Mac App as well as the git command line, my first instinct was to grab a copy of either Versions of Cornerstone and go to work, but Andrew Nacin, another core developer for WordPress, let me know about issues with patching and creating diff files with the Mac software.

@mattbanks There isn't a good one out there, AFAIK. Versions can't create patches. Most tough it out and use the CLI: http://t.co/aSI2Hkvy

— Andrew Nacin (@nacin) December 10, 2011

Patching, Diffs, and the World of Contribution

So what are these diff files? When you change something to create a patch, you want to create a diff file to send the differences to the WordPress Trac for testing. This patch allows other developers to test what you’ve just written to make sure it’s secure, has good performance, and actually fixes what you say it does. Creating diff files is easy with Subversion in Terminal. You can either make a patch for a particular filename:

svn diff filename.php > filename.diff

Or you can make a big patch for all the files you’ve changed:

svn diff > big_patch.diff

Once you’re ready, post an issue over at the WordPress Trac with your diff file to queue it up for testing. You’ll get responses form other developers, possibly some debate on whether the change is necessary, and it’ll either get approved or not.

Many times, though, you’ll be testing other people’s patches. Reading through the issue list is a great way to find out what needs fixing. If something needs a patch, hop in and code it if it you can, or test a patch that someone else submitted. Again, it’s a simple process at the command line. Download the file, place it in the WordPress directory you cloned earlier, and drop this bad boy into Terminal (obviously, with all of these examples, you need to replace paths and filenames to suit your environment):

patch -p0 < patch.diff

If you find problems applying the patch or bugs afterwards, posting back in Trac lets everyone know. It’s a fairly simple process if you’re comfortable with all of the tools.

What’s in it for Me?

So why did I decide this was for me? Like I said earlier, I wanted to give back and help make the system I use on a daily basis better for myself and all of its users. I had a patch ready to go for a bug I’ve been noticing (rel=”category tag” causing HTML5 validation errors), but someone beat me to it and patched it in already. I tested the patch and am moving on to some other issues that I’d like to assist with. Overall, it just makes me feel good.

If you know how to write code and love WordPress like I do, why don’t you jump on it and help in the development process? You just might end up getting your name in the Credits page on everyone’s dashboard!

This post "Contributing to WordPress Core – It’s Time to Give Back" was featured on Matt Banks - thoughts on web development

Mortal Kombat Gameplay, Story Mode and Online Play

While I did cover everything in my review at Loot Ninja, I didn’t go extremely in depth in each area of the game. We had a short-form review system at the site, which works perfectly for reviews (who really wants to sit and read an overly long multi-page review and not just get to the point?), so writing on my own blog gives me the chance to go a bit more in-depth into each of my favorite areas. The gameplay itself in Mortal Kombat is some of the most balanced, intuitive and deep fighting gameplay I’ve ever experienced. Many fighting games excel in one of those areas, but Mortal Kombat nails the whole spectrum. Beginners can hop in and enjoy themselves while seasoned vets can perfect their combo juggling forever. It’s setup perfectly to cater to everyone while still being insanely fun – enough credit cannot be given to Ed Boon and his team at NetherRealm Studios.

Story Mode in Mortal Kombat is one of the areas where I spent the most amount of time initially. While being the best Story mode in any fighting game, it serves an even greater purpose – you are forced to use and get used to almost every character. While some my scoff at the idea, being handed each character to try is something many people just don’t do in a fighting game (or at least use more than once). Having four or more fights each gives you a chance to hone your skills and find out which Kombatants are your cream of the crop. Had I not played through the Story mode, I don’t think I would have been nearly as proficient with some of the characters as I am now (more on that later). There isn’t a whole lot of replay value to Story Mode, even at higher difficulties, but it did give me reason to use some new Kombatants in the Arcade Ladders.

Online play has always been odd in fighting games on consoles – multiplayer is where fighting games shine, but lag and disconnects kill it right from the start. Mortal Kombat has its fair share of both (even moreso right now as we’re awaiting a patch to fix a DLC-related issue), but overall I’ve had a better time online with this game than others recently. Super Street Fighter IV is good, but Mortal Kombat is better – aside from not having a Spectator mode, which annoys the crap out of me. King of the Hill does the best job I’ve seen of replicating the arcade experience of earlier days in the online realm and excels when you have a private room with all your friends. Just keep taunting each other while you perform Fatalities left and right. It’s a blast.

The Krypt

I’m usually not a completionist in games, but The Krypt has taken hold of me and won’t let go. I initially started with going section by section unlocking things in order, but decided after spending 40,000 Coins to cherry-pick my way through the disturbing unlockables. Watching birds peck open a distended undead corpse stomach to let loose a green ball of whatnot is both blood-curdling and yet addicting. Anyway, I went online and found a terrific guide to The Krypt from Ripten that highlights all the areas of major importance, particularly the Fatalities and costumes. I’m 95% done with unlocking everything and will be playing through more of the Challenge Tower (another amazing fighting game mode) to get enough Coins to finish.

My Favorite Kombatants

I quickly found that some of my old favorites just didn’t do the trick in the new Mortal Kombat. Mainstays of my Mortal Kombat 2 days included Lui Kang, Baraka and Sub Zero. However, their move sets, timings and combos just didn’t jive with how my fighting style has evolved. I’m not saying they’re bad, because I’ve seen some amazing fights with those characters, but they just don’t work for me right now. Thanks to the Story mode throwing me in the shoes of other Kombatants, I was able to fall in love with Kitana, Cyrax and Smoke. I’ve become pretty deadly with chaining together some massive combos with Kitana, so watch out if we play online. A few others I’m dabbling in of late include Kung Lao, Ermac, Noob Saibot, and Scorpion. I like to keep a stable of 4-5 characters to rotate and keep things fresh, along with making sure I have the best weapons at my disposal given each opponent’s character choice.

DLC – Bring it On

Some may poo-poo DLC on all fronts, but I’ve always been a fan… if priced right. Warner Bros. announced the Mortal Kombat Season Pass, but made it an Xbox 360 exclusive, which was rather disappointing. Being someone who plays all fighting games on PS3 due to the superior D-pad on the controller, I would have loved to save some cash to get all four characters. Oh well, we got Kratos, who is much better than every other outsider I’ve played in a fighting game.

As of now, I haven’t purchased any DLC. I plan to buy Kenshi when he’s released on the PlayStation Store tonight – I was always a fan of him in the previous generation’s Mortal Kombat titles. His sword-play and move-set look to be fairly unique and should be a nice addition to the fighters I already use. While I haven’t purchase Skarlet yet, I do plan to buy her DLC as well tonight as I’ve seen more and more that indicates she’s not just a skin-swap of Kitana (where she originated as glitch). With a vast move list and ability to create massive combos, she might be good to have around. I’m hoping Rain turns out to the same and not just a skin-swap of Smoke and other ninjas, but we’ll have to wait and see. Who knows who the fourth character will be, but I’ll most likely buy him or her too. Keep bringing it on and I’ll keep buying it. Costumes on the other hand, I won’t buy.

With the plethora of gameplay modes to keep me busy along with the fun online play, I can see myself dumping countless hours into Mortal Kombat over the Summer and Fall. There are quite a few other games in the wings waiting to be played – inFAMOUS, inFAMOUS 2, Mass Effect 2 and Red Dead Redemption are all currently waiting at home, while I’ve already preordered Uncharted 3, Gears of War 3 and Battlefield 3 – but I have a feeling even when I move on to those games, I’ll still keep coming back to Mortal Kombat. Not having to keep pressing forward in gaming can be good thing sometimes, it seems. In this case, I’m happy I can devote a metric ton of time into a single game. If you want to show your skills online on the PS3, drop me a line and we’ll throw down.

This post "I’m Addicted to Mortal Kombat – My Favorite Fighting Game Ever" was featured on Matt Banks - thoughts on web development

It’s been a rough day. If you didn’t hear, today we shut down Loot Ninja, my now former video game news, editorial and review website. It’s been my baby for almost six years, but it’s time to say goodbye.

With Loot Ninja gone, I’ll be writing more here – something I’ve been meaning to do for quite a long time. Now I’ll have time to write about things outside of video gaming (and some games too, for sure). Stay tuned!

And if you have any suggestions for things for this site, by all means let me know. I’m using WooThemes wonderful Canvas theme as the basis for my new WordPress theme. They have an amazing framework to build from, so this should be fun

This post "Please Excuse the Mess – Working on a New WordPress Theme" was featured on Matt Banks - thoughts on web development

One of the big apps I needed for this coverage is a Flickr app to upload all of my photos to post at Loot Ninja. With that not yet available, I’m stuck bringing my laptop to display all of my imagery. Sure, the iPhone app will run on the iPad, but it’s overly cumbersome and doesn’t offer much in the way to grabbing images to put into WordPress. To the same extent, the WordPress app for iPad is a buggy mess – crashing at will if you so much as think about another platform. Since those are key elements to covering these events, I have little choice than to pack my laptop for the trip.

I have a lot of faith in the development community that all the apps will come and/or get updated in fair amount of time. But for now, the iPad won’t serve the purpose as a video game conference coverage beast in my travel bag. I’ll still it use as an eBook reader, movie viewer, internet browser and game player, but all of my major writing and photo uploading will be relegated back to the Mac. One day… one day.

This post "I Love my iPad, but it’s Incomplete" was featured on Matt Banks - thoughts on web development