My Git Aliases

Git is an awesome tool for version control and has been accepted as the industry standard. However, Git commands can be very confusing and difficult to remember. When I first learned about version control I used something called Mercurial, which had simpler and more intuitive commands (generally speaking). In an effort to tame Git and make it a bit more intuitive, I’ve created a few aliases that I think you might find helpful.

What is a Git Alias?

No, a Git alias isn’t when you commit using someone else’s name… although I’ve done that before. 😉 A Git alias is nothing more than a custom git command that can reference a longer git command or even a custom shell command. Put simply, it is a command-line shortcut.

For example, when I want to perform a git checkout, I actually just type git co because I’ve created co as an alias of checkout.

How to Create a Git Alias

So how do you go about creating an alias? The simplest way is to create one via the command line, like this:

Alternatively, you can manually edit your .gitconfig file in your user directory by adding the following:

The [alias] bit shoult only be in there once, but under that you can add as many aliases as you want. All of your aliases should be indented under the [alias] heading with a single tab.

If you want to quickly start editing your .gitconfig file, just run this command:

My Git Aliases

OK, on to the good stuff. Here are the aliases I use, what they do and a handy copy and paste command for adding the alias to your own .gitconfig file.


The co alias is a shortcut for the checkout command.

To create this alias, just run this command:


The ci alias is a shortcut for the commit command. I think of it as the ‘Check In’ command. While there is no checkin command in Git (or Mercurial), there is in SVN and it is the perfect opposite to the checkout command.

To create this alias, just run this command:


The st alias is a shortcut for the status command, but with a small twist. I prefer to see the status in a condensed mode, so I add the -s flag to opt for the short display. I also add the -b flag so it always shows me the current branch. If you don’t want those flags set, just leave them off when creating your alias.

To create this alias, just run this command:


The in alias is patterned after the incoming command in Mercurial. Basically, it tells me if there are any incoming commits I should pull down. Ultimately, it is not so easy to git this information from Git without a lot of typing. It is also strangely satisfying to type git in.

To create this alias, just run this command:

Note: The ! character at the beginning of a Git alias basically causes the alias to run a shell command. As such, we can really run any command supported by our operating system. In this case, I’m just running two git commands back to back.


The out alias is patterned after the outgoing command in Mercurial. Basically, it tells me if there are any outgoing commits that I should push up. Again, it is also just fun to type git out!

To create this alias, just run this command:


The ready alias is one for which I have to credit my brother David. Basically, it stages all changes and then shows the current status. This is typically what you might do right before a commit, so it is aptly named. This one is also just fun to type!

To create this alias, just run this command:

Note: I’ve applied my personal preferences to the status command by adding the -s and -b flags here. Feel free to customize and make it your own!


The unstage alias will do exactly what you think it does: Unstage any staged changes. While the Git way of doing this isn’t hard, it also isn’t intuitive. I always opt for intuitive where possible.

To create this alias, just run this command:


The rollback alias will undo the last commit. It is patterned after the rollback command from Mercurial. When I first started working with Git, I found myself looking up how to do this all the time. Since Git doesn’t have a rollback command, we can add it ourselves!

To create this alias, just run this command:


The forget alias will make Git forget about one or more files. Again, this is something I used to look up all the time because it isn’t intuitive to do in Git.

This alias isn’t a meant to be used without additional parameters. For example, I wouldn’t just run git forget because it wouldn’t really do anything. However, if I want Git to forget about my huge.log file, I would just run git forget huge.log.

To create this alias, just run this command:


The leaderboard alias is just for fun and credit for this one goes to Kolbe. Basically, it just lists all the authors who have made commits in order by the number of commits they’ve made to the repository. While the number of commits isn’t the best way to judge contributions to a code base, it is a good way to get a feel for activity.

To create this alias, just run this command:


Last but not least, the alias alias is used to list all your aliases! I know that when you have a bunch of aliases it is likely that you will forget about them from time to time. Maybe you need to do something more complicated and know you have an alias to do that, but don’t remember the name of it. Have no fear! Just add this alias and all you need to do to list out your aliases is type git alias!

To create this alias, just run this command:


So there you have it, 11 awesome Git aliases you can start using today! If you don’t want to add them all one at a time from the command line, you can just copy and paste this whole block into your .gitconfig file:

Have you already been using Git aliases? If so, let me and everyone else know by sharing the ones that have helped you the most!

Async or Defer JavaScript Files in WordPress

There are a lot of articles out there about how to async or defer scripts in WordPress, but they assume you’ll be writing all the code or using one of the bloated plugins to make it happen.

In my case, I just needed the ability to async or defer a few scripts in a custom plugin or theme. Sure, I could add all the filters every time to make that work, but I’m a programmer. Why should I have to constantly write the same code over and over again? Why not create a simple module to handle this for me and allow me to async and defer scripts in a truly WordPress way? So I did just that.

Introducing the WordPress Async/Defer Scripts Module

A Composer library for asynchronously loading or deferring scripts in WordPress. View on GitHub or Packagist.


  • PHP 5.3+
  • WordPress 4.2+


Add the module to your code base via Composer:

Be sure to require the Composer autoloader in your project:


Asynchronously load a script using the wp_scripts()->add_data() method:

Defer loading of a script using the wp_scripts()->add_data() method:


In most cases, you can simply follow the installation instructions and things will just work. However, if you are including this library outside of a WordPress plugin or theme, you may have to manually initialize the class:


I’d love to see simple async and defer functionality added to WordPress core, but in the meantime, this has worked out quite well for my own personal projects and I thought I’d share it with you. What do you think?

WordPress Post Expiration Module

WordPress plugins are great, but sometimes you want to avoid having additional settings screens or giving a client access to make changes that could break functionality on their website.

If you aren’t a coder and you want to automatically expire a post in WordPress, I’d recommend that you check out the Post Expirator plugin. However, if you want a nice and simple way to expire posts without having to deal with extra admin configuration, then you should check out my WordPress Post Expiration module.

Composer Installation

All the Composer users out there can just run

to add the module to your WordPress project.

If added to a WordPress theme or plugin, the only code you will need to add is a line of code for each post type that should support expiration:

You can also just add ‘expiration’ to the ‘supports’ array when defining a custom post type.


You now have a meta box on all posts that allow you to set an expiration date and time. If no date is set, then the post will live on forever. Otherwise, it will use the WordPress cron functionality to run a task every hour and automatically trash any posts that have an expiration date in the past.

Manual Installation

Not using Composer? Just download the module into your project, require the PostExpiration.php file. Then, add this line of code:

Be sure to add the ‘expiration’ post type support to the desired post types and you are good to go!

View wpscholar/wp-post-expiration on Packagist.

New Plugin Release: Simple Website Redirect

Piggybacking off of my last post regarding how to redirect an entire website except for the WordPress admin, I’m announcing the release of a new plugin: Simple Website Redirect.

After being asked by someone “Where do I put the code?”, I went looking knowing I would find a plugin that does the same thing that I could recommend for a non-developer type. However, what I found is that there isn’t a single plugin in the plugin repository that made it easy for people to redirect an entire website.

This plugin allows you to set the URL you want to redirect to, select whether to use a permanent or temporary redirect and toggle the redirect functionality on and off from a very simple admin screen.

When enabled, redirects happen on the front end of the site while still allowing the WordPress admin to be accessible. All redirects will retain the URL path and query string for further handling on the new site.

Since it is a plugin, it doesn’t matter what web server you are running, it will just work. The only word of caution I have is to make sure and test things with the ‘Redirect Type’ in ‘Temporary’ mode first. Otherwise, your browser will cache the redirects and things will appear not to work correctly as you continue to make changes.

Go ahead, download the plugin and give it a try!

Redirect Entire Website Except WordPress Admin

I get asked a lot about how to handle different types of website redirects. Usually, someone wants to redirect an entire site, or maybe just redirect a subdomain.  Other times, they want to do simple one-off redirects.

Many web servers that run WordPress use Apache, which means that .htaccess rules will work. Other web servers like Nginx don’t look at your .htaccess file at all. So the most reliable way of creating a redirect regardless of the web server is to implement it in the WordPress code itself. After all, in this scenario, you want to keep the WordPress admin available… so you obviously aren’t getting rid of the old domain or site instance.

The code snippet above will get the job done and will make sure that the path the user was trying to go to is kept so you can properly handle any further redirects on the new site.

Not a coder? Don’t worry, you can download the Simple Website Redirect plugin which will do the same thing!

First Steps to WordPress Security

WordPress security is an important consideration, but often site owners don’t think about it until it is too late. Like most things, the Pareto principle applies: If you can do a few simple things (20%), you can prevent most security issues (80%). In addition to prevention, you can also take a few simple steps that will help ensure you are able to restore your site in the event that it is compromised, corrupted, or even just accidentally deleted.

This article isn’t really targeted at developers, but rather non-technical site owners who want to make sure they have at least done the bare minimum when it comes to security. On that note, here are my quick and dirty recommendations:

  • Keep WordPress up to date. – Older versions of WordPress are more likely to be hacked as they don’t include many of the security fixes that newer versions do. Just be sure you update all of your plugins as well as your theme before upgrading WordPress core to avoid potential issues when upgrading.
  • Keep your theme and plugins up to date. – Again, older versions are more likely to be hacked as they don’t include many of the security fixes that newer versions do.
  • Only use quality themes and plugins. – WordPress core is very secure and most often it is a bad theme or poorly coded plugin that makes your site vulnerable. Make sure that the software you install is of reasonable quality. If you are using a theme or plugins from the WordPress repository, you can do a little checking to see the last time it was updated, what types of reviews its had and how many downloads or active installs its had. For premium themes and plugins, you’ll just have to do more research on the company and ask experienced WordPress developers and/or users if the company and plugin are reputable. As a rule of thumb: Never download free plugins that aren’t listed in the WordPress repository.
  • Set a secure password and change it often. – You should change your password about once every one to three months. Hackers have scripts that will try to guess your password. A more secure password will be harder to guess and changing your password occasionally will ensure that they have to start the guessing process over again and aren’t given an unlimited amount of time to discover your password. If an easy to remember password is important to you, then create an admin user with a super-complicated password and then create another user that has the ‘Editor’ role. You can then use that ‘Editor’ role to log in and do your normal content publishing. However, I’d recommend just using a tool like LastPass to help you keep track of your passwords.
  • Backup your site regularly. – If your site is ever hacked or otherwise lost, at least you will be able to restore it. Obviously, your backup schedule will depend on how often you update the site and/or perform software upgrades. Be sure that you backup not only the filesystem, but also the database. There are some great tools out there for handling backups, like these:
  • Make sure your site backups are stored offsite. – In other words, don’t count on or trust backups from your web host or backups that are stored on your site’s server. Your data needs to be somewhere that a hacker isn’t likely to delete it if they gained access to the server. Ideally, your web host will also provide backups so that you have some built-in redundancy.

If you do these things, you will be well on your way to securing your site and will be able to easily recover if something does happen. This is by no means an exhaustive list, so once you’ve taken care of these things be sure to check out the Next Steps section below.

If you are technical enough to add a line to your wp-config.php file, you will get bonus points for adding this line to disable the WordPress file editor:

define('DISALLOW_FILE_EDIT', true);

Next Steps

The tips listed here cover just a few things you can do to improve security. Here are a few resources to help you take security to the next level:

Add Helper Classes to WordPress Navigation Menus

WordPress automatically outputs many helpful CSS class names for menus. If you use the wp_nav_menu() function to display your menus, as all good themes should do, you don’t have to settle for just the default class names.

The wp_nav_menu() function calls the wp_nav_menu_objects filter, which allows you to manipulate the menu objects before being converted into HTML and displayed on the site. One of the things you can do is add a few custom class names, like this:

This adds a menu-item-first class to the first menu item and a menu-item-last class to the last menu item. These extra utility classes are helpful when styling menus in a custom theme.

Prevent Directory Browsing with .htaccess

Directory browsing allows visitors to your site to see and browse through the contents of folders on your web site. Anyone on the web could potentially visit a directory on your site, see what files exist there and open them at will. Typically, web hosts disable directory browsing for security reasons. However, there are still plenty of web hosts out there that don’t disable it.

Basically, if directory browsing is enabled and you don’t have an index.html or index.php file in a given directory, the web browser will display the contents of the directory along with a link back to the parent directory.

Obviously, revealing the inner workings of your website to the public could entice hackers or at least make their job easier. Hackers can perform Google searches to find sites with directory browsing enabled and then choose sites which have known vulnerabilities based on their findings.

How to Check Your Site

You can check to see if directory browsing is enabled on your site by creating a folder and adding a basic text file. If you visit the directory in your web browser and it displays a link to the text file, then directory browsing is enabled. If you get a ‘Page Not Found’ or ‘Forbidden’ message, then directory browsing is disabled.

Web Host Checklist

If you find that your web host has directory browsing enabled, leave a comment below and we’ll start a running list. Meanwhile, if your web host uses an Apache server, you will want to apply the fix at the end of this article.

Directory Browsing and WordPress

By default, a self-hosted installation of WordPress has a built-in safeguard against directory browsing. A new WordPress installation will contain a blank index.php file in each folder so that a user visiting a folder, such as the plugins directory, will be presented with a blank screen. However, many WordPress plugins don’t do this. This means that hackers can likely see what plugins, and versions of those plugins, that you have installed on your site.

Securing Access to your Directories with .htaccess

The easiest way to disable directory browsing is to add a line to your site’s .htaccess file. Just be aware that this only works for sites running on an Apache web server.

Keep in mind that you can have .htaccess files in multiple locations, but you want to make your change in the .htaccess found in the root directory for your domain. This will cause the change to take place across your entire site.

Here is what you will need to do:

  • Download your .htaccess file and make a copy. You should always keep a copy of your .htaccess file when making changes, for when things don’t work as planned.
  • Add these lines to your .htaccess file:

  • Upload the new .htaccess file and overwrite the existing one.
  • Verify that directory browsing is disabled. You can visit a folder that previously allowed you to view the directory contents and be sure you are getting a ‘Page Not Found’ or ‘Forbidden’ error message.

Browser Caching of 301 Redirects

Many people don’t realize that browsers cache 301 redirects. A 301 redirect is a permanent redirect from one URL to another. It only makes sense that a browser should cache a 301 redirect, after all, it is permanent.

Our natural tendency after setting up redirects is to check and see if they are working properly. However, if you made a mistake and had to tweak one of your 301 redirect rules, guess what is going to happen when you go to test your change? Yep. Your browser is going to send you to the same place it redirected you to last time.

Clear your browser cache each and every time you make a change to a 301 redirect.

If you put a 301 redirect into operation, that redirect will be cached in the browser for any visitor’s on your site. You can’t clear the browser cache for your users, so if you need to change or undo a 301 redirect, the old redirect is still going to be in effect until their cache expires.

Never put a 301 (permanent) redirect in place unless it is truly permanent!

When you are setting up redirects and aren’t sure if they work yet, do you really want them to be permanent? No, you still need to test them! As a best practice, you should always implement 302 (temporary) redirects first. This way you will avoid having to constantly clear your browser cache and you will never have a situation where a subset of your users are constantly redirected into oblivion because their browser cached a bad redirect.

Always implement 302 (temporary) redirects first, then change them to 301 (permanent) redirects once you’ve tested them!

Web Redirects and the Law of Specificity

A common mistake when setting up multiple redirects for a website is failing to put them in the correct order. Typically, the person setting them up realizes that order is important; but it isn’t always clear how the redirects should be ordered.

Let’s take a look at a simple use case where there are multiple redirects:

The first redirect can actually live anywhere in the file since there is no competing rule.

However, the other two redirects are competing rules. You can easily find competing rules by finding any redirects where the ‘from’ portion of the path is the same.

In our example, the second redirect will pick up a request for /our-team/john-doe and send it to /about/john-doe. Since a redirect triggers immediately once a matching rule is found, our last redirect is never hit.

The Law of Specificity

The Law of Specificity states:

Web redirects should always be ordered by specificity. The most specific redirect rules should always come first and the more general rules should come last.

Let’s reorder our previous example according to this new insight:

As you can see, now that we’ve placed the more specific rule first, the /our-team/john-doe request will get forwarded to /john-doe as expected and any other requests to the /our-team path will be appropriately redirected within the /about path.

On a side note, I’ve decided to separate all of my non-competing rules from my competing rules. For competing rules, I like to group them based on their shared ‘from’ path.