What is Git?

Git is a open-source code managemen tool; it was created by Linus Torvalds when he was building the Linux kernel. Because of those roots, it needed to be really fast; that it is, and easy to get the hang of as well. Git allows you to work on your code with the peace of mind that everything you do is reversible. It makes it easy to experiment with new ideas in a project and not worry about breaking anything. The Git Parable, by Tom Preston-Werner, is a great introduction to the terms and ideas behind Git.

Why Should I use Git?

You should definitely use a revision control system; as we already said, this gives you the freedom to do whatever you want with your code and not worry about breaking it. So if you’ve realized the benefits of using a revision control system, why should you use git? Why not SVN or Perforce or another one? To be honest, I haven’t studied the differences too closely; check out WhyGitIsBetterThanX.com for some helpful info.

How do I Get Set Up?

Git is pretty easy to get: on a Mac, it’s probably easiest to use the git-osx-installer. If you have MacPorts installed, you may want to get Git through it; you can find instructions on the GitHub help site. (And yes, we’ll talk about GitHub). On Windows, the simplest way to start rolling is to use the msysgit installer. However, if you’ve got Cygwin, you can git Git through there as well.

How do I use Git?

By now you should have Git installed; if you’re on a Mac, open up a terminal; if you’re on Windows open the Git Bash (from msysgit) or your Cygwin prompt. From here on, there shouldn’t be any OS differences.

Configuration

We’ll start by doing a bit of configuration. Every commit you make will have your name and email address to identify the ‘owner’ of the commit, so you should start by giving it those values. To do so, run these commands:

git config --global user.name "Your Name"
git config --global user.email "your@email.com"

It’s also nice to enable some text coloring, just for easier reading in the terminal.

git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto

git init

Now that Git knows who you are, let’s imagine we’re creating a simple PHP web app. (Of course, the bigger the project, the brighter Git shines, but we’re just learning the tools, right?) We’ve got an empty directory called ‘mySite.’ First focus on that directory (using the cd command). To get started with Git, you need to run the git init command; as you might guess, this initializes a Git repository in that folder, adding a .git folder within it. A repository is kind of like a code history book. It will hold all the past versions of your code, as well as the current one.

Notice that your terminal path is appended with (master). That’s the branch you’re currently working on. Branch? Think of your project as a tree; you can create different features on different branches, and everything will stay separate and safe.

git add

We’ve started working on our application.

Before we go any further, we should make our first commit. A commit is simply a pointer to a spot on your code history. Before we can do that, however, we need to move any files we want to be a part of this commit to the staging area. The staging area is a spot to hold files for your next commit; maybe you don’t want to commit all your current changes, so you put some in the staging area. We can do that by using the add command

git add .

The . simply means to add everything. You could be more specific if you wanted.

git add *.js
git add index.php

git commit

Now that we’ve staged our files, let’s commit them. This is done with the command

git commit

This takes all the files in our staging area and marks that code as a point in our project’s history. If you don’t add any options to the command above, you’ll get something like this.

Each commit should have an accompanying message, so you know why that code was committed. This editor allows you to write your message, as well as see what is in this commit. From the image above, you can see that this commit is comprised of four new files. The editor you’re using to write the message is Vim; if you’re not familiar with vim, know that you’ll need to press i (for Insert) before you can type your message. In the shot above, I’ve added the message “Initial Commit.” After you write your message, hit escape and type :wq (to save and exit). You’ll then see you’re commit take place.

You can use a few options to make commits more quickly. Firstly, -m allows you to add your message in-line.

git commit -m "initial commit"

Then, -a allows you to skip the staging area; well, not really. Git will automatically stage and commit all modified files when you use this option. (remember, it won’t add any new files). Together, you could use these commands like this:

git commit -am 'update to index.php'

So how does Git tell commits apart? Instead of numbering them, Git uses the code contents of the commit to create a 40 character SHA1 hash. The neat part about this is that, since it’s using the code to create the hash, no two hashes in your project will be the same unless the code in the commits is identical.

git status

The git status command allows you to see the current state of your code. We’ve just done a commit, so git status will show us that there’s nothing new.

If we continue working on our imaginary project, you’ll see that our status changes. I’m going to edit our index.php and add another file. Now, running git status gives us this:

The update is divided into two categories: “changed but not updated,” and “untracked files.” If we run

git add userAuthentication.php
git status

you’ll see that we now have a “changes to be committed” section. This lists files added to the staging area. I’m going to commit these changes with this:

git commit -am 'user authentication code added'

Now running git status shows us a clean working directory.

git branch / git checkout

Here’s a scenario: we’re working happily on our project when suddenly we have a grand idea. This idea is so revolutionary, it will change our project drastically. We’ve got to give it a try, but we don’t want to throw this insecure, first-draft code in with our tested and true code. What to do? This is where git branch will be immensely helpful. Let’s branch our project so that if our big idea doesn’t work out, there’s no harm done.

git branch

Just running the branch command sans options will list our branches; right now, we’ve only got the master branch, which is what any git repository starts with. To actually create a new branch, add the name of your new branch after the command.

git branch bigIdea

When you create a new branch, you aren’t switched to it automatically. Notice that our terminal still says (master). This is where we use branches comrade command git checkout.

git checkout bigIdea

(Tip: you can create a branch and switch to it in one fell swoop with this command: git checkout -b branch name.) As you can see, we’re now on the bigIdea branch. Let’s code up a storm. Git status will show our work.

Let’s commit our changes:

git add .
git commit -m 'The Kiler Feature added'

All right, enough of this feature for now; let’s go back to our master branch; but before we do, I want to show you our current project folder.

Now, switch back to the master branch; you know how:git checkout master. Look at our project folder again.

No, I didn’t do anything; those two files are only part of the bigIdea branch, so we don’t even know they exist from the master branch. This not only works for complete files, but also for even the smallest changes within files.

git merge

Ok, so we’ve been working hard on that bigIdea branch in our spare time. In fact, after another commit, it’s looking so sweet we’ve decided it’s good enough to join the master branch. So how do we do it?

The git merge command is made for exactly this purpose. While on the master branch, give this a try:

git merge bigIdea

It’s that easy; now, everything on the bigIdea branch is a part of the master branch. You can get rid of the bigIdea branch now, if you want.

git branch -d bigIdea

I should mention that if you haven’t merged a branch, Git won’t let you delete it with this command; you’ll need to use an uppercase D in the option. This is just a safety measure.

git log / gitk

You’ll probably want to look at your commit history at some point during your project. This can easily be done with the log command.

git log

This will output a list of all the commits you’ve made in a project, showing them in reverse order. You can get at quite a tidy chunk of info here:

• the commit author
• the commit hash
• the date and time
• the message

Definitely informative, but rather dry, no? We can brighten things a bit with the graph option.

git log --graph

Now we can see the tree structure, sort of. Although we don’t get their names, we can see each of the branches and which commits were made on them. If you’re used to working in a terminal, you might be fine with this. However, if (previous to this experience) the word terminal strikes you first as something deadly, breathe easy: there’s an app for that. Try this:

gitk --all

This is the graphical repository browser. You can browse around your commits, see exactly what was changed in each file during a commit, and so much more. (You’ll notice I added a few commits before merging, just to make the tree structure more recognizable.)

GitHub

Now that you’ve got a reasonable knowledge of Git under your belt, let’s look at some of the collaborative parts of Git. Git is a great way to share code with others and work on projects together. There are a number of Git repository hosting sites. We’ll just look at one: GitHub.

Head over to the GitHub sign-up page and create an account. You’ll need an SSH public key, so let’s create that right now! (Note: you don’t need the key while signing up; you can add it later.)

Open up your terminal and type this:

ssh-keygen -t rsa -C "your@email.com"

The t option assigns a type, and the C option adds a comment, traditionally your email address. You’ll then be asked where to save the key; just hitting enter will do (that saves the file to the default location). Then, enter a pass-phrase, twice. Now you have a key; let’s give it to GitHub.

First, get your key from the file; the terminal will have told you where the key was stored; open the file, copy the key (be careful not to add any newlines or white-space). Open your GitHub account page, scroll to SSH Public Keys, and click “Add another public key.” Paste in your key and save it. You’re good to go! You can test your authentication by running this:

ssh git@github.com

You’ll be prompted for your pass-phrase; to avoid having to type this every time you connect to GitHub, you can automate this. I could tell you how to do this, but I’d probably inadvertently plagiarize: the GitHub Help has a plain-english article on how to do it.

Git Clone

So now you’re set up with GitHub; let’s grab a project. How about jQuery? If you go to the jQuery GitHub project, you’ll find the git clone URL. Run this:

git clone git://github.com/jquery/jquery.git

This creates a jquery folder and copies the whole jquery repository to your computer. Now you have a complete history of the project; check it out with gitk –all.

git push

So let’s say you’ve been working on a project, managing it with git locally. Now you want to share it with a friend, or the world. Log into GitHub and create a new repository. GitHub will give you a public clone URL (for others wanting to download your project) and a personal clone URL (for yourself).

Then, come back to your project in the terminal and give this a whirl:

git remote add origin git@github.com:andrew8088/Shazam.git

A remote is a project repository in a remote location. In this case, we’re giving this remote a name of origin, and handing it our private clone URL. (Obviously, you will have to substitute my URL for your own.) Now that the project knows where it’s going . . .

git push origin master

This pushes the master branch to the origin remote. Now you’re project is available to the world! Head back to your project page and see your project.

git pull

You might be on the other end of a project: you’re a contributor instead of the owner. When the owner pushes a new commit to the repository, you can use git pull to get the updates. Git pull is actually a combo tool: it runs git fetch (getting the changes) and git merge (merging them with your current copy).

git pull

You’re Set!

Well, there’s so much more you can learn about Git; hopefully you’ve learned enough commands to help you manage your next project more smartly. But don’t stop here; check out these resources to become a Git master!

• Git, GitHub, and Social Coding (YUI Theater)
• GitHub Learning Center
• Gitcasts.com: screencasts on Git
• The Git site
• My public Git Evernote-book

• Follow us on Twitter, or subscribe to the Nettuts+ RSS Feed for the best web development tutorials on the web.

What are Feeds?

In this digital age, users no longer have the luxury of time to check for new content manually each time or more importantly remember each site they want to get information from. Web feeds, news feeds or feeds helps the user simplify this process drastically.

Feeds, to put it simply, are a way to publish frequently updated content. Your feed is a XML formatted document which lets you share content with other users on the web. Users, subscribers in this lingo, can use your feed to read updated information on your site if and when it is posted.

Why you Should Publish Feeds

From a web developer’s perspective, one of the main reason for publishing a feed is user convenience. With a feed for users to subscribe to, they don’t have to check for new content manually each time. They can just subscribe to your feed and get notified new content is posted. No hassles! If you fear you’ll lose your advertisement revenues in this process, you can just as easily include ads in the feed.

Publishing a feed also means that it is easier for third party content providers to syndicate your content thus gaining more exposure and traffic in the process.

Feed Formats

As with any hot technology, there are a few well established, competing protocols for creating web feeds.

RSS

RSS is the dominant format for publishing web feeds and stands for Really Simple Syndication. RSS has a number of variants each branching out from RSS 1.x and RSS 2.x versions. A lot of services, including WordPress use RSS for creating its feeds.

Despite it’s massive user base, RSS does suffer from some drawbacks, some significant, the most important one being its inability to handle HTML. Nevertheless, we’ll be creating our feed today in the RSS format.

Atom

Atom was created in order to mitigate a lot of RSS’ drawbacks including the ability to include properly formatted XML or XHTML in your feeds. But since RSS has almost become synonymous with feeds, Atom has always been the much more feature rich and flexible little brother.

RSS’s Format

In the interest of keeping it simple, we’ll just stick with RSS today instead of trying out each format out there.

Each and every RSS feed out there follows this general format:

Defining the version and encoding

RSS is a subset of XML which means we need to make sure it is marked so appropriately.

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
..
</rss>

The first line is the XML declaration. We define the version so that it validates correctly as XML. The encoding part is purely optional.

The second line defines the version of RSS we are going to use today. We are going to use RSS 2 today.

Each feed need to be inside a channel so that goes inside the markup. Thus far our feed looks like so.

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
<channel>
..
</channel>
</rss>

Filling in the feed’s source information

This is where you fill in all the important details like the name of the feed, the URL and a description of the site.

<title>My feed</title>
 <link>http://www.somesite.com</link>
 <description>Random ravings  </description>

You aren’t limited to these fields alone. There are a number of other optional fields including the language of your feed, an image for the logo, when the feed was updated last and many more.

Adding the content

Each item in the feed has to be enclosed by an <item> element. An item can be anything: a news post, a status update, new products: anything. Each item requires a title and a corresponding link. As with before, you can make use of a number of optional elements including description and author fields.

A sample item would look like so:

<item>
<title>Feeds 101</title>
 <link>http://www.net.tutsplus.com</link>
 <description>Let's create an RSS feed from scratch!</description>
 <author>Siddharth</author>
</item>

Building a Static RSS Feed

Now that we know all the individual parts of a RSS file and how they all gel together, it’s time to see a complete RSS file.

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
<channel>
	<title>My feed</title>
   <link>http://www.somesite.com</link>
   <description>Random ravings  </description>
   <item>
		<title>Feeds 101</title>
 		<link>http://www.net.tutsplus.com</link>
 		<description>Let's create an RSS feed from scratch!</description>
 		<author>sid@ssiddharth.com</author>
	</item>
</channel>
</rss>

It may not look like much but gents, this is a working RSS feed. We’ve defined everything that needs to be defined and if you are inclined to do so, you can put this on the web.

Building a Dynamic RSS Feed

Happy about building your first RSS feed? You should be! But the problem with this is that the feed is completely static: something which is completely counter intuitive as compared to the concept of feeds. We’ll rectify this now by building a simple PHP script that mooches off data from a database and updates the RSS feed when needed.

Since I like having pretty URLs, I am going to name this file index.php and place it in a folder called feed so my feed can be accessed at www.mysite.com/feed

For the sake of simplicity, I am going to assume you already have a database containing your articles. I am also assuming the database has columns named title>, link, description and date in a table called posts.

Building the base

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
<channel>
	<title>My feed</title>
   <link>http://www.somesite.com</link>
   <description>Random ravings  </description>

 <?php
    // Code here
 ?>

</channel>
</rss>

Since the XML declarations and feed information are going to be pretty static, we’ll keep them static. You’d want to keep them dynamic if you were writing a PHP class for generating RSS feeds but for our purposes, this should do.

Defining database information and connecting

DEFINE ('DB_USER', 'some_username');
DEFINE ('DB_PASSWORD', 'some_unusually_weak_password');
DEFINE ('DB_HOST', 'localhost');
DEFINE ('DB_NAME', 'database');

Simple as it looks. We just note down a bunch of information for use later.

$connection = mysql_connect(DB_HOST, DB_USER, DB_PASSWORD) or
die('Connection to the specified database couldn't be established');
mysql_select_db(DB_NAME)  or
die ('Specified database couldn't be selected');

Pretty generic connection code. We try to connect using the credentials noted earlier. If nothing hitches up, we select the relevant database for use later.

Querying the database

$query = "SELECT * FROM posts ORDER BY date DESC";
$result = mysql_query($query) or die ("Query couldn't be executed");

This isn’t really a SQL oriented tutorial and so I’ll skim over it. We just grab all the posts from the table so that we can add it to the feed. Nothing else fancy going on over there.

Populating the items list

while ($row = mysql_fetch_array($result, MYSQL_ASSOC) {
echo '<item>
		 <title>'.$row['title'].'</title>
		 <link>'.$row['link'].'</link>
		 <description>'.$row['description'].'</description>
	   </item>';
}

We grab each individual record and then print it inside the relevant element to create the items list. Note that since I wanted a hash to work with I set the result type to MYSQL_ASSOC.

And with that the PHP part is done. The complete code should look like below.

 <?php
     header("Content-Type: application/rss+xml; charset=utf-8");
 ?>

 <?xml version="1.0" encoding="utf-8"?>
 <rss version="2.0">
 <channel>
	<title>My feed</title>
   <link>http://www.somesite.com</link>
   <description>Random ravings  </description>

 <?php
    DEFINE ('DB_USER', 'some_username');
	 DEFINE ('DB_PASSWORD', 'some_unusually_weak_password');
	 DEFINE ('DB_HOST', 'localhost');
	 DEFINE ('DB_NAME', 'database'); 

	 $connection = mysql_connect(DB_HOST, DB_USER, DB_PASSWORD) or
	 die('Connection to the specified database couldn't be established');
	 mysql_select_db(DB_NAME)  or
	 die ('Specified database couldn't be selected');  

	 $query = "SELECT * FROM posts ORDER BY date DESC";
	 $result = mysql_query($query) or die ("Query couldn't be executed");  

	 while ($row = mysql_fetch_array($result, MYSQL_ASSOC) {
		echo '<item>
			 	<title>'.$row['title'].'</title>
		 		<link>'.$row['link'].'</link>
		 		<description>'.$row['description'].'</description>
	  	 	  </item>';
	 }
 ?>

 </channel>
 </rss>

You should now be able to access your feed at www.yoursite.com/feed.

Validate your Feed

Just like with xHTML, RSS/XML needs to be well-formed and without errors. There are a number of validators to help you with this. Here are some of my often used ones.

• W3C’S Validator
• Feed Validator
• RSS Board’s Validator

Since RSS can only handle escaped HTML, make sure you use &lt; lt; for < and &lt; gt; for > respectively. Also make sure you replace special characters to their respective HTML codes. Forgetting to do so will probably result in invalid markup and break the feed.

All Done! Publish that Feed

Now that we’ve created the feed and made sure it validates, we can now go publish it. You can use a service like Feedburner to manage your feeds. This lets you glean a lot of information including how many subscribers you have. Or you can take the easy way out and just link to your feed on your site.

Have you ever noticed the feed icon on your browser lighting up for certain pages alone? This means the browser has been notified that a feed of the current page is available for subscription. In order for the user’s browser to automatically detect the feed’s presence you need to add this small snippet to the head section of your page:

<link rel="alternate" type="application/rss+xml" title="Article RSS Feed"
href="http://www.yoursite.com/feed" />

You need not limit yourself to one feed. You may have a feed for each author or a feed for each category of the products you sell. Feel free to add as many feeds you want to the head section.

Conclusion

And that brings us to an end to this joy ride. We’ve gone over what feeds are, what purpose they serve and the different formats available. Next we looked at RSS, its skeleton structure and then learned how to create a simple dynamic RSS feed. Hopefully you’ve found this tutorial interesting and this has been useful to you.

Questions? Nice things to say? Criticisms? Hit the comments section and leave me a comment. Happy coding!

• Follow us on Twitter, or subscribe to the Nettuts+ RSS Feed for the best web development tutorials on the web.

With that in mind, regardless of whether you’re an SEO guru or a beginner, these twenty tools are guaranteed to make your life easier.

Keyword Research

When people – like us – build web sites, they assume they know what keywords people use to get to their sites. For the basic keywords this works but there a lot of untapped keywords that you might be unaware of. Doing the proper research to find out all possible keywords is imperative in this case. The keyword research tools below let you do all that in a jiffy.

Google Search Based Keyword Tool

Google’s tool provides keyword ideas and suggestions siphoned directly from Google’s search data. This is slightly different from the Adwords Keyword tool in that it suggests keywords not already associated with your Adwords account and provides a lot more information.

Just key in your site and normal keywords and let it provide you with a plethora of new ideas.

WordTracker

An excellent tool, with a paid counterpart, which lets you find out related keywords you might have missed out on so far. It also provides rough estimations of the search volume generated by the keywords.

SEOBook Keyword Suggestions

This tool cross references the keyword you input with multiple search engines to provide suggestions.

Microsoft’s Keyword Forecast

This tool predicts search volume and impressions for the keywords you enter into the system. Useful tool when you are about to launch a SEO campaign. Also provides a ton of target demographic data you’d want to take advantage of.

Trellian’s Keyword Discovery

Another popular keyword research tool with a paid version available for those who want additional features. Just type in your basic keywords and let it generate a list of top keywords which will work well for you.

Keyword Density

The number of times a keyword occurs in your page’s content is extremely important. Be too skimpy and your site won’t be counted for that keyword. Go overboard and you’ll be penalized for keyword stuffing. The optimum numbers seems to be between 2 to 4 percent and these tools will let you make sure you make this number.

SEOBook Keyword Density Analyzer

Just enter your URL and let the tool do its thing. It shows you which keywords are present most in your content, how many times it occurs and how much place it takes up relative to the other words on the page.

iWebTool Keyword Density Checker

Another tool which looks through your page and creates a tag cloud. If you prefer raw data, it also shows you how many times each keyword occurs on your page.

Webconfs Keyword Cloud

Webconfs’ tool produces a keyword cloud for easy perusal. Just like with other tools it also produces a listing of which keyword occurs the most and its density.

Search Engine Rank Checkers

Link Vendor’s Page Rank Checker

This Page Rank checker lets you find out your Page Rank at individual Google data centers.

PageRank Tool

This tools lets you find out your page rank quickly with minimal fuss.

Self SEO Rank Checker

You can find out your PageRank and Alexa rating along with a bunch of other useful info using this tool.

Link Popularity

A major part of SEO is getting linked. The number of backlinks you are getting is a fair approximation of how well your site is doing and makes tracking this statistic an important affair. Using these tools, you can find out who links to you, which pages are linked the most and a lot of other data.

WebMaster Toolkit Link Popularity Checker

Just enter the URL in question and it’ll show you how many pages popular search engines link to through their search engine result pages.

SEOCentro Link Popularity Check Tool

Lets you know how many incoming links you have and breaks it down to individual search engines. Also provides an interesting table of sites with differing numbers of incoming links for reference.

LinkVendor’s Link Popularity Tool

An excellent tool which provides a plethora of information including how many web sites link to you, how many individual linkbacks you get, your PageRank, your Alexa rank and so much more.

Site Analytics

Monitoring your site’s traffic, page views and visitor behavior is extremely important once you’ve finished the initial SEO to make sure your plan is sound. Use these tools to track down your site’s statistics.

Google Analytics

Google Analytics provides an extremely slick summary of your data. Use it to check which pages get linked to the most, how much time people spend on your site, what percentage of visitors are new and a lot more.

Compete

Just like Google Analytics, this tool presents an extremely pleasing way to monitor your site’s well being. As a fun feature, it lets you compare the stats of up to 5 different sites.

Mint

If you don’t mind a paid solution, Mint is a top-notch analytics suite which a lot of developers swear by. It features a beautiful interface to present all the data.

Crawl tests

Understanding how your pages look to spiders (heh) is important while optimizing for them. This lets us strip out all the visual elements and see the page as a crawler would see. Such a test helps you understand how accessible a page is to a crawler and lets you weed out potential issues before full deployment. These 3 tools let you do just that.

SEOTools Spider Test

This tool not only lets you see how your page looks to spiders but also returns a lot of useful information including the number of words in the page, the keyword density and pages you link to.

iWebTool Spider View

If you are just looking to find a tool to simulate a spider without any extra frills, this is the tool for you. Crawls through your site and lets you see how it looks to a bot.

WebConfs’ Spider Simulator

WebConfs’ Spider Simulator simulates a spider crawling through your site. Shows you how a page looks to a spider and also nets you the list of sites you link to, the meta description and meta keyword.

Conclusion

I hope this list made it easier for you optimize your web applications for search engines. With the internet being a big place, I am sure I’ve missed a ton of equally useful SEO tools. Let us know about these hidden gems in the comments. Thanks for reading!

• Follow us on Twitter, or subscribe to the Nettuts+ RSS Feed for more daily web development tuts and articles.

When people think of .htaccess configuration the first thing that pops into
most people’s minds is URL manipulation with mod_rewrite. Thoughts on
mod_rewrite vary quite a bit. To get a quick feel for what the world thinks
for it I just ran a twitter search on “mod_rewrite” and picked a few from the
front pages at the time I started this article:

mldk: Aargh! .htaccess and mod_rewrite can be such
a pain in the —!

bsterzenbach: Man do I love mod_rewrite. I
could work with it the rest of my life and still not master it – so powerful

mikemackay: Still loving the total
flexibility of mod_rewrite – coming to the rescue again. Often so
overlooked…and easier than you might think too!

hostpc: I hate mod_rewrite. Can’t get this dang
application to work properly

awanderingmind: Oh Wordpress and
Apache, how thou dost vex me. Mod_rewrite be damned!

danielishiding: Why won’t mod_rewrite
work! Damn it!

A few things I noticed are that people clearly recognize the power of
mod_rewrite but are often frustrated by the syntax. Thats not surprising
considering the front page of Apache’s mod_rewrite documentation says
basically the same thing:

Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool
voodoo, but still voodoo.” — Brian Moore

What a turn off! So, in this article I’m really going to take things down a
notch. I’m going to try and address not only mod_rewrite’s syntax but try and
provide a workflow that you can use to debug and solve your mod_rewrite
problems. I’m also going to give you a few useful real-world examples.

However, before I start I’m going to give a warning. With many subjects, this
one in particular, you won’t learn unless you try on your own! That is one of
the reasons I’m going to focus on teaching a debug workflow. As usual I’ll
show you how to get your system setup if you don’t already have the module
loaded. I urge you to work through the examples on your own server, preferably
in a test environment. The more experience and success that you have the
easier it will be to expand on that knowledge to more advanced examples and
applications. Enjoy.

What is mod_rewrite?

mod_rewrite is an Apache module that allows for
server-side manipulation of requested URLs. Incoming URLs are checked against
a series of rules. The rules contain a regular expression to detect a
particular pattern. If the pattern is found in the URL, and the proper
conditions are met, the pattern is replaced with a provided substitution
string or action. This process continues until there are no more rules left or
the process is explicitly told to stop.

This is summarized in these three points:

• There are a list of rules that are processed in order.
• If a rule matches it checks the conditions for that rule.
• If everything is a go it makes a substitution or action.

Advantages of mod_rewrite

There are some obvious advantages of using a URL rewriting tool like this but
there are some things that are probably not as obvious.

The main reason people use mod_rewrite are to transform ugly, cryptic URLs into
what are known as “friendly URLs” or “clean URLs.” The new URLs are
friendly in more ways then one. They are user friendly often making it much
easier for humans to understand at a glance and possibly manipulate on their
own. As an added bonus these URLs are also more search engine friendly.
Creating friendly URLs is one search engine optimization technique. URLs are an
effective way to describe the content its linking to. Take the following example:

Not so friendly: http://example.com/user.php?id=4512
Much friendlier: http://example.com/user/4512/
Even better:     http://example.com/user/Joe/

Not only is the final link easier on the eyes, its possible for search engines to
extract semantic meaning from it. This basic kind of URL rewriting is one way
that mod_rewrite is used. However, as you will see it can do a lot more
then just these simple transformations.

Expanding on the same example, some people claim there are security benefits
by having mod_rewrite tranform your URLs. Given the same example, imagine
the following attack on the user id:

http://example.com/user.php?id=AHHHHHH
http://example.com/user/AHHHHHH/

In the first example the php script is explicitly being invoked and must handle
the invalid id number. A poorly written script would likely fail and in a more
extreme case (in a poorly written web application) bad input could cause data
corruption. However, if the user is only ever shown the friendlier URLs they
wouldn’t even know that the user.php page existed. They might only know about
the friendly URL structure. Trying the same attack in that case would likely fail
before it even reaches the php script. This is because at the core of mod_rewrite is
regular expression pattern matching. In the example case above you would have
been expecting a number, for example (\d+), not characters like a-z. The
rewrite would have failed as soon as it found letters instead of numbers.

This extra layer of abstraction is nice from a security perspective. You could
even prevent direct access to the original PHP scripts if you wanted. However,
I am in no way condoning using mod_rewrite as a replacement for the usual
security measures. You should always have server-side validation in your
scripts.

Enabling mod_rewrite on the Server

Just like enabling .htaccess support, enabling mod_rewrite or any apache module
must be done from the global configuration file (httpd.conf). Just as before,
since mod_rewrite usage is so widespread hosting companies nearly always have
it enabled. However, if you suspect that your hosting company does not have it
enabled, and we will test for that below, you should contact them and they will
likely enable it.

If you rolled your own Apache installation its worth noting that mod_rewrite
needs to be included when compiled Apache, as it is not done so by default.
However, its so common that nearly all installation guides, including
Apache’s show how in their example. However, pre-packaged versions will
have it enabled. If you’re reading this there is probably a 99% chance that
mod_rewrite is compiled on your Apache, so you can just proceed to the next
step.

If you’re the administrator for your webserver and you want to make sure that
you load the module you should look in the httpd.conf file. In the
configuration file there will be a large section which just loads a whole
bunch of modules. The following line will likely appear in the file. If it
is, great! If its commented out, meaning there is a # symbol at the start
of the line then remove the # to be left with:

LoadModule rewrite_module modules/mod\_rewrite.so

Olders version of Apache 1.3, may require you to add the following directive,
after the LoadModule directive.

# Only in Apache 1.3
AddModule mod\_rewrite.c

However, this seems to have disappeared in Apache 2 and later. Only the
LoadModule directive is required.

If you had to modify the configuration file at all then you will have to
restart the web server. As always you should remember to make a backup of the
original file in case you need to revert back to it later.

Testing for mod_rewrite

You can test if mod_rewrite is enabled/working in a number of ways. One of the
simplest ways is to view the output from PHP’s phpinfo function. Create this
very simple PHP page, open it in your browser and search for “mod_rewrite” in
the output.

<?php phpinfo(); ?>

mod_rewrite should show up in the “Loaded Modules” section of the page like so:

However, if you’re not using PHP (although I will for the rest of the tutorial)
there are some others ways to check. Apache comes with a number of command
line tools. I mentioned the htpasswd tool in the first tutorial for Basic
Authentication. You can use other tools like apachectl or httpd to directly
test for the module. There are command line switches that allow
you to check all of the loaded modules in the existing installation. You
can execute the following to get a listing of all of the loaded modules.

 shell> apachectl -t -D DUMP_MODULES 

Here I show the help page for the command. I then run the command and
search for “rewrite” in the results and it shows there was a line of output
that matched!

Finally, if you are still unsure if its enabled, like before just give it a
shot and see what happens! I’ll go over the syntax later but here would be
a very bare bones test to see if its working. The following .htaccess file
would redirect any request in the given folder to the good.html file. That
means if mod_rewrite is working you should see good.html. If mod_rewrite
is not working then you will see index.html which shows a warning.

# Redirect everything in this directory to "good.html"
RewriteEngine on
RewriteRule .* good.html

Here are the Good and Bad result pages:

Inside .htaccess

As always, anything that you can put in a .htaccess file can also be put inside
the global configuration file. With mod_rewrite there is a small differences
if you put a rule in one or the other. Most noticeably:

if you’re putting […] rules in an .htaccess file […] the directory
prefix (/) is removed from the REQUEST_URI variable, as all requests are
automatically assumed to be relative to the current directory.
– Apache Documentation

Just something to keep in mind if you see examples online or if you’re trying
an example yourself, beware of the leading slash! I will attempt to clarify
this below when we got through some examples together.

Regular Expressions

This tutorial does not intend to teach you regular expressions. For those of
you that know regular expressions, the regular expressions used in mod_rewrite
seem to vary between versions of Apache. In Apache 2.0 they seem to be
Perl Compatible Regular Expressions (PCRE). This means that many of the
shortcuts you are used to, such as \w meaning [A-Za-z0-9_], \d meaning
[0-9], and much more do exist. However, my hosting company uses Apache 1.3
and the regular expressions are more limited.

If you don’t know regular expressions here are some useful tutorials that will
bring you up to speed quickly.

• Nettuts very own Jeffrey’s Crash Course
• The Absolute Bare Minimum Every Programmer Should Know About Regular Expressions
• Quick And Practical Tutorial
• Smashing Magazine Links on Regular Expressions

And a few references that everyone should know about:

• Popular Added Bytes Cheatsheet For Regular Expressions
• Added Bytes Cheatsheet for mod_rewrite
• Explain Regular Expressions

If you haven’t spent the time to learn regular expressions I highly suggest
that you take the time to learn them. As is usually the case, they are not as
complex as you may think they are. I selected the links above from my years of
experience working with regular expressions. I feel that these guides do a very
good job of getting the basics across. Regular Expressions are crucial to know
if you want to effectively use mod_rewrite, and they are also useful to know
for many different aspects of general development, such as “find/replace” in
your favorite code editor!

Getting a Feel for it.

Okay, you’ve waited patiently enough, lets run through a quick example. This is
included in the linked source files. Here is the code from the .htaccess file:

# Enable Rewriting
RewriteEngine on

# Rewrite user URLs
#   Input:  user/NAME/
#   Output: user.php?id=NAME
RewriteRule ^user/(\w+)/?$ user.php?id=$1

Before I can explain any of it I have to give you more information about the
other files in the directory.

The directory contains an index.php and a user.php file. The index just has
some links, of various formats, to the user page. The php code is purely debug
to show that the page was accessed and what the given “id” parameter contained.
Here is user.php code:

<?php

// Get the username from the url
$id = $_GET['id'];

?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <title>Simple mod\_rewrite example</title>
    <style type="text/css"> .green { color: green; } </style>
</head>
<body>
  <h1>You Are on user.php!</h1>
  <p>Welcome: <span class="green"><?php echo $id; ?></span></p>
</body>
</html>

This example has a few different parts. First, notice that URL Rewriting must
be enabled via the RewriteEngine directive! If your .htaccess file is going
to use rewrite rules you should always include this line, otherwise you can’t
be sure if its enabled or not! As a rule of thumb, always include it and make
sure that you only have it once per .htaccess file. The string “on” is case
insensitive. So when you see other examples on the net that show “On”, that
is equally acceptable.

The first RewriteRule is for handling the user.php page. As the comments
indicate we are rewriting the friendly URL into the format of the normal URL.
To do that, when the friendly URL comes in as input we are actually
transforming it into the standard query string URL. Breaking it down we get:

The Rule:
RewriteRule ^user/(\w+)/?$ user.php?id=$1

Pattern to Match:
^              Beginning of Input
user/          The REQUEST_URI starts with the literal string "user/"
(\w+)          Capture any word characters, put in $1
/?             Optional trailing slash "/"
$              End of Input

Substitute with:
user.php?id=   Literal string to use.
$1             The first (capture) noted above.

Here are some examples and an explanation for each:

So the first example goes through unaffected by the RewriteRule and works
just fine. The second and third examples match the RewriteRule, are
rewritten accordingly and end up working just fine. The last example does not
match the rule and proceeds untouched. The server doesn’t have a
user directory and fails trying to find it. This is as expected because
user/joe/x is a bad URL in the first place!

This example was rather easy to understand. However, there were a lot of
minute details that I glossed over. To do anything more complex I want to
clarify exactly what is happening. In the next section I’m going to walk
through exactly what happens and we will take a look at a more complex
example that touches on all the core aspects of rewriting.

NOTE: If this example didn’t work for you its possible that your Apache or
mod_rewrite versions are not PCRE compatible. Try changing ^user/(\w+)/?$
into ^user/([a-z]+)/?$. Notice that I did not use the \w shorthand. If
this version works for you then you will have to avoid the regex shortcuts
and instead use their longer equivalents (see the Regular Expressions section
above).

Flow of Execution in Detail

The flow of execution through the rewrite rules is simple but its not exactly
straightforward. So, I’m going to break it down into painful detail. It all
starts with the user making a request to your server. They type a URL into
their browser’s address bar, their browser translates that into an HTTP request
to send to the server, Apache receives that request, and parses it into pieces.
Here is an example:

Note that whenever I mention one of Apache’s variables I use a weird syntax:
%{APACHE_VAR}. That is just because its similar to the syntax that
mod_rewrite uses to access the variables. However, it is the name inside the
braces that is important.

So what part does mod_rewrite deal with? If you’re working inside a .htaccess
file, then you’re working with the REMOTE_URI portion but without the leading slash!
I mentioned this before, and its something that is very confusing for most
people when they start out. If you’re working from inside the global
configuration file, then you would leave the leading slash in.

To be as specific as possible, buried in the Apache Documentation is
this description of the “URL Part” that mod_rewrite acts on:

The Pattern is always a regular expression matched against the URL-Path of
the incoming request (the part after the hostname but before any question
mark indicating the beginning of a query string).
Apache Documentation

To remove any ambiguity, highlighted in gold in these two URLs below is the
“URL Part” that mod_rewrite acts on inside a .htaccess file:

For the rest of this section I’ll be using these two URLs to describe the flow
of execution. I will refer to the first url as the “green” URL and the second
as the “blue” URL. Also I will be using “URL Part” throughout this analysis,
meaning the REMOTE_URI without the leading slash.

For those readers that want to be 100% technical these two things that I am
calling URLs are actually URIs. The definition of a Uniform Resource
Identifier (URI) differs from a Uniform Resource Locator (URL). A URI is just
an indicator of where a resource is. This means that multiple URIs can point
to the same resource but are themselves different addresses. Following a URI
might take any number of hops or redirections until it actually arrives at the
resource. A URL however, is a stricter term that identifies the exact location
of a resource. This subtle difference has blurred over time such that nobody
cares about the difference. I will continue to use the term URL because people
are more comfortable with it.

So, now we know what the rewrite rules are going to be acting on. Once Apache
has parsed the request it translates that to the file it thinks is needed and
proceeds to fetch that file. At this point it will traverse directories and
encounter the .htaccess files. Assuming the .htaccess file enables the
RewriteEngine any RewriteRule could change the URL. A drastic enough change
(such as one that points Apache to another directory instead of the original
directory it was heading towards) will cause Apache to issue a sub-request
and proceed to fetch the new file.

In most cases sub-requests are invisible to you. This implementation detail
is not important to know for the majority of the simple rewrites that you will
ever write or use. What is more important to know is how Apache processes
the rewrite rules inside a .htaccess file.

The rules in a .htaccess file are processed in the order that they appear.
Note that each RewriteRule is acting on the “URL Part” that is similar to
the REMOTE_URI. When a rule makes a substitution, the modified “URL Part”
will be handed to the next rule. That means that the URL that a rule is
processing may have been edited by a previous rule! The URL is continually
being updated by each rule that it matches. This is important!

Here is a flow chart that tries to provide a visualization of the generic
flow of execution across multiple rules in a .htaccess file:

Note that at the top of the flow chart the value going into the rewrite rules
is that “URL Part” and if the substitution is successful the modified part
proceeds into the next rule.

I mentioned rewriting conditions earlier but I didn’t go into detail. Each
RewriteCond is associated with a single RewriteRule. The conditions appear
before the rule they are associated with, but only get evaluated if the rule’s
pattern matched. As the flow chart shows, if a rewrite rule’s pattern matches
then Apache will check to see if there are any conditions for that rule. If there
are no conditions then it will make the substitution and continue. If there
are conditions then it will only make the substitution if all of the
conditions are true. Lets visualize this in a concrete example.

The URLs that I’m working with are actually part of the “Profile Example” that
I’ve included in the source code download in the “profile_example” directory.
This is similar to the previous example with the user.php but it now has a
profile.php page, an added rewrite rule, and a condition! Lets take a look at
the code and Apache’s flow of execution through it:

Here there are two rules. Rule #1 is the same as the user example we saw
before. Rule #2 is new and notice that it has a Condition. The “URL Part” we
have been discussing goes through the rules in order, top to bottom. So it will
first go through Rule #1 and then Rule #2.

The key to understanding this example is to first understand the goal. In this
example I am going to allow friendly profile URLs but I’m actually going to
explicitly forbid access to the php page directly. Note, some people might say
that this is a bad idea. They might say that as a developer this will make
things harder for you to debug. Thats true, I don’t actually recommend doing a
trick like this, but it makes for an excellent example! More practical uses for
mod_rewrite will show up later in this tutorial.

So, with that in mind lets see what happens with our green URL. This one we want
to be successful.

Up at the top you see Apache’s THE_REQUEST variable. I put this at the top
because, unlike many of the Apache variables we will deal with, during the
duration of the request this variables value will never change! That is one
of the reasons why Rule #2 uses %{THE_REQUEST}. Underneath THE_REQUEST we
see the green “URL Part” going into the first rule:

• The URL matches the pattern.
• There are no conditions, so it continues.
• The substitution is made.
• There are no flags, so it continues.

After making it through the first rule, the URL has changed. The total URL has
been rewritten to profile.php?id=joe which Apache then breaks down and
updates many of its variables. The ?id=joe portion gets hidden from us and
profile.php, the new “URL Part”, continues into the second rule. It is our
first encounter with conditions:

• The URL matches the pattern.
• There are conditions so we will try the conditions.
• THE_REQUEST does not contains profile.php so the condition fails.
• Because a condition failed we ignore the substitution and flags.
• The URL is unchanged by this rule.

At this point we made it through all the rewrites and the profile.php?id=joe
page will be fetched properly.

Here is how the execution looks for the blue URL, the one we want to fail:

Again I put the THE_REQUEST value at the top. The blue “URL Part” enters
Rule #1:

• The URL does not match the pattern.
• Everything else is ignored and the URL proceeds unchanged.

The first rule was easy. As is often the case a URL that you have won’t match
a rule’s patten and will proceed untouched. Now it enters Rule #2:

• The URL matches the pattern.
• There are conditions so we will try the conditions.
• THE_REQUEST contains profile.php so the condition passes.
• All the conditions passed we can make the substitution.
• ”-” is a special substition that means don’t change anything.
• There are flags on the rule so we process the flags
• There is a F flag which means return a forbidden response.
• A 403 Forbidden response is sent to the client.

A few things are worth re-iterating. In order for the substitution to work, all
of the conditions have to pass. In this case there is only one, and it passes
so the substitution happens. Note that - is a special substitution that
doesn’t change anything. This is useful when you just want to use flags to do
something for you, which is exactly what we want to do in this case.

Here is the familiar table breakdown of example URLs and their responses:

Syntax

While going over the syntax of RewriteRule and RewriteCond I would suggest
that you first download the AddedBytes Cheatsheet. This is because
the cheatsheet lists the most useful server variables, flags, has regular
expression tips, and even a few examples. There is just so much there that it
would be difficult to put it inline.

Lets start with RewriteRule. You can always visit
Apache’s Documentation on RewriteRule if you need to do something
really specific. Here is my overview:

The cheatsheet shows what types of flags are available. Many tutorials cover these
flags in detail, and I’ll go through the flags that I see most commonly used in
the examples below.

Here is Apache’s Documentation on RewriteCond and my overview:

Debug Workflow

Whenever you’re working with mod_rewrite and creating new rules, always
start with a simple, dumbed down version of the rule and work your way
up towards the final version. Never try to do everything at once. The same
thing applies for conditions. Add rules and conditions one at a time.
Test often!

The key concept I am trying to get across with this approach is that this will
let you know quickly if a change you made doesn’t work properly or causes
something to work incorrectly. When doing too much at once inevitably you will
run into an error and you will have to revert all of the changes you made to
track down what the problem was. This is a very roller coaster approach and
will likely lead to frustration. However, if you’re always steadily advancing,
and each step along the way moving to workable checkpoints you’re in much,
much better shape.

People often ignore this advice, create a complex rule, and it ends up not
working. Hours later they find out the problem was not in the complex portion,
but instead it was just a simple mistake in the regular expression that could
have been caught much earlier had they carefully constructed the rule like
I’ve explained above. The same goes for deconstructing a rule to reverse
engineer a problem. This approach will seriously reduce frustration!

In the Examples

In the examples below I will always assume the website’s domain is
example.com. This domain name is important because it affects the
HTTP_HOST variable as well as specifying a redirect URL to another file on
your website. Keep this in mind in case you intend to modify any of the examples
for your own website. If so, simply replace “example.com” with your domain.
For example, Nettuts would replace “example.com” with “nettuts.com”.

Removing www

This is the most classic rewrite rule. This will make it so anyone who comes
to your website via http://www.example.com they will get a hard redirect and
thus the Location Bar in their browser will update accordingly.

RewriteEngine on
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]

The rule matches anything, and saves everything as $1. The important part
in this example is the condition. The condition checks the HTTP_HOST variable
to see if it started with “www.” If this condition is true, the rewrite
happens:

• The substitution is a full URL (it starts with http://)
• The substitution contains $1 which was captured earlier
• The [R=301] flag redirects the browser to the rewritten URL, this is a hard
  redirect in the sense that it causes the browser to load the new page and
  update its Location Bar with the new URL.
• The [L] flag means that this is the last rule to parse, the rewrite engine,
  should stop.

If the incoming URL had been “http://www.example.com/user/index.html” then
HTTP_HOST would have been www.example.com and the rewrite would happen
creating http://example.com/user/index.html.

If the incoming URL had been “http://example.com/user/index.html” then
HTTP_HOST would have been example.com, the condition would have failed
and the rewrite engine would proceed with the URL unchanged.

Forbid Hotlinking

Hotlinking, referred to as Inline Linking on Wikipedia, is the term
used to describe one site leeching off of another site. Usually one site, the
Leecher, will include a link to some media file (lets say an image or video)
that is hosted on another site, the Content Host. In this scenario, the
Content Host’s servers are wasting bandwidth serving content to some other
website.

For many people, its fine if other sites cross link to their content. However,
many people would rather prevent hotlinking so as not to pay for the extra
bandwidth required to send the content to someone else’s site.

The most common, and basic approach to preventing hotlinking is to whitelist
a number of websites, and block everything else. To find out who is asking
for the content from your site you can check the referrer. The HTTP_REFERER
header (yes that is how it is spelled) is set by the browser or client that
is requesting the resource. In the end this is not 100% reliable, however it
is more then effective at stopping the majority of hotlinking. So, verify
if the referrer is in a whilelist of acceptable referrers. If the referrer
is not acceptable (blank or someone else’s site) then you can send them
a forbidden warning:

# Give Hotlinkers a 403 Forbidden warning.
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http://example\.net/?.*$ [NC]
RewriteCond %{HTTP_REFERER} !^http://example\.com/?.*$ [NC]
RewriteRule \.(gif|jpe?g|png|bmp)$ - [F,NC]

Here the RewriteRule is checking for a request of a file with any popular
image extension. Such as .gif, .png, or .jpg. You could add other extensions
to this list if you want to protect .flv, .swf, or other files.

The domains that are allowed to access the content are “example.net” and
“example.com”. In either of these two cases a Rewrite Conditions will fail
and the substitution won’t happen. If any other domain makes an attempt, lets
say “sample.com” attempts, then all the Rewrite Conditions will pass, the
substitution will happen, and the [F] forbidden action will trigger.

Give Hotlinkers a Warning Image

The previous example returns a 404 Forbidden warning when someone trys to
hotlink content from your server. You can actually go one step further, and
send the hotlinker any resource of your choice. For example you can send
a useful warning image can just be some text stating “hotlinking is not
allowed”. This way the other person can realize their mistake and host a copy
on their own server. The only change is to actually go through with the rewrite
substitution and provide a choosen image instead of the one being requested:

# Redirect Hotlinkers to "warning.png"
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http://example\.net/?.*$
RewriteCond %{HTTP_REFERER} !^http://example\.com/?.*$   [NC]
RewriteRule \.(gif|jpe?g|png|bmp)$ http://example.com/warning.png [R,NC]

Note that this is an example of what I call a “hard” or “external” redirect.
The RewriteRule has a URL in the substitution portion and it also has the [R]
flag.

Custom 404

One trick that you can do with htaccess is check to see if the current “URL Part”
leads to an actual file or directory on the web server. This is a good way to
create a custom 404 “File not Found” page. For example, if a user trys to
fetch a page in a particular directory that doesn’t exist you can redirect them
to any page you want, such as the index page or a custom 404 page.

# Generic 404 to show the "custom_404.html" page
# If the requested page is not a file or directory
# Silent Redirect: the user's URL bar is unchanged.
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule .* custom_404.html [L]

This is a great example of mod_rewrite’s file test operators. They are
identical to file tests in bash shell scripts and even Perl scripts. Here
the condition checks if the REQUEST_FILENAME is not a file and not a
directory. In the case where it is neither, then then there is no such
file for the request.

If the incoming request filename can’t be found then this loads
a “custom404.html” page. Note that there is no [R] flag, so this
is a silent redirect, not a hard redirect. The user’s Location Bar
will not change, but the contents of the page will be
“custom404.html”. Short and simple.

Safety First

If you have mod_rewrite snippets that you use often and want to easily
distribute to other servers or environments you may want to be careful. As
was mentioned, any invalid directive in a .htaccess file will likely cause
internal server errors. So if an environment you move the snippet to doesn’t
have mod_rewrite you could temporarily break it.

One solution to this problem is the “check” for the mod_rewrite module. This
is possible with any module. Just wrap your mod_rewrite code in an
<IfModule> block and you’ll be all set:

<IfModule mod_rewrite.c>

  # Turn on
  RewriteEngine on

  # Always remove www (with a hard redirect)
  RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]
  RewriteRule ^(.*)$ http://example.com/$1 [R=301,L]

  # Generic 404 for anyplace on the site
  # ...

</IfModule>

Conclusion

I hope that this tutorial proves that mod_rewrite isn’t all that scary, and in
fact its quirks and speed bumps can be avoided with careful development
practices.

• Follow us on Twitter, or subscribe to the Nettuts+ RSS Feed for more daily web development tuts and articles.

A word from the Author

Before we start looking at these techniques, just know and understand this: don’t expect overwhelming changes to occur over night. Getting higher ranks on search engines through SEO is a meticulous process and takes times to obtain positive results. Don’t be too hasty and more importantly, don’t resort to black hat SEO techniques. It may give you almost instant results but in the long term, the search engine is probably going to flag and blacklist you. You don’t want that. Take it slow, be earnest and wait for the results.

What is SEO?

Search Engine Optimization is the process of increasing the number of visitors by achieving a high position within search results when relevant keywords are searched for. It is common knowledge that people rarely look passed the second or third page of the search results. Optimally you’ll want a first page position or even the first result in the first page. However, to accomplish this, you’ll need to optimize and code accordingly.

Choose the Right Keywords

Choosing the right keywords can be painless or extremely tricky depending upon the scenario. You’d want to avoid the generic ones since it is going to be extremely difficult to optimize for them. Try to pick keywords that are just as specific as they need to be. For example if you are a freelancer based in Melbourne, your optimal keywords would be freelancer Melbourne or web development services Melbourne. Going for the generic freelancer or web development keywords isn’t going to do you any good.

Research your keywords. Know which ones are probably going to be searched for most and go from there.

Focus on the Content

Content always comes first. It doesn’t matter if you perform some dark voodoo to get your site the top place in the results. You’ll still need solid content to back that up since the visitors are going to be leaving pretty quickly if they don’t find what they are looking for.

Having good, relevant content is the most important aspect of SEO. Your content needs to be suitably useful for the people who you’d want to find your site. You need the content to make sense to the reader. The content needs to appeal to people and make them come back for more.

Having original content is very important. Don’t expect to just copy-paste some text from another site, throw in some keywords and call it a day. You need lots and lots of original content with the keywords in the content itself. If people searching for jQuery come to your page, they expect something related to jQuery to be found on your page. Throw in relevant keywords within the content of the page. But don’t just spam them sporadically like with tweeting. Your keywords need to be in the appropriate position and of appropriate density. Throw too much keywords around in the content and you are going to be flagged for spam.

Just as important as having original content is having regularly updated content. Fresh content will bring in people and bots alike which in turn will let you get your site indexed with much more frequency which will in turn return fresher results to the search results. But don’t update just for the sake of updating. Bots have little incentive to come back if all the updates you perform are only marginally incremental. Just try to have something fresh for the visitors and you should be alright.

Get a Proper Domain Name

This is a hard to obtain part. If at all possible, get a domain name with the keywords in the domain name itself. www.webdevelopmentaustralia.com is going to have a lot more weight with search engines than www.somecompany.com. Obtaining a domain with the proper keywords should be difficult though.

Domains with the keyword as part of it do look ugly but keep in mind that keywords in the domain name carry very great weight.

Create Pretty URLs

Using a URL scheme where parameters are passed as a query string through the URL make it difficult for search engine spiders to look through your site. More importantly, when you are passing the session ID as part of the URL you are essentially creating a separate URLs for each session with almost the same content. This is probably going to get you penalized for duplicate content. We’ll talk about that later on.

Human readable, bot parsable URLs are generally preferred over traditional parameter filled URLs. www.somecompany.com/games/2009/callofduty6 is generally preferred to www.somecompany.com/index.php?cat=game&year=2009&name=callofduty6. When crafting pretty URLs try to avoid days, months and years. www.somecompany.com/blog/seobasics is preferred to www.somecompany.com/blog/2009/09/09/seobasics

Dish out Relevant Page Titles

The text within the title tags: the text that is displayed on your browser’s title bar is amongst the most important elements of a page. Actually I’d venture so far as to say it’s the most important part of your page after the actual content itself.

Make sure the title is unique for each page and contains relevant keywords. With regards to the title’s structure itself Page Title -> Site Name is vastly preferred to Site Name -> Page Title. There are no reasons for you to feel the title needs to be as terse as possible but on the other hand don’t try to make it too long. 60 characters is the accepted limit.

Also whilst using keywords in your title text, please don’t try to spin it too much. If the search bot sees too many keywords, you are going to be flagged for spam. Remember, the title text is what appears on the search engine result page. You need to convey as much information as possible without sounding too spammy.

Tweak the Meta Elements

The meta elements used to matter eons ago when search engine bots were less sophisticated and relied on the meta description and keyword attributes to help them. When this was taken advantage of by spammers, search bots started giving less importance to meta elements.

Having said that, it doesn’t hurt to include the meta description element. This is the text used in the description of your site. Try to limit yourselves to 200 characters, keep it simple, grammatically correct and include relevant keywords. Keep the descriptions unique for each page.

Optimize the Page Structure

Layouts vary. Positions of your sidebar or navigation vary too. But with respect to the core markup itself, it’s best to put your main content as close to the body tag as possible. If your other elements have to be placed before the content, use CSS to position it before the content instead of moving the markup itself before the content.

Footers are wonderful places to link to other content on your site. Don’t just ignore your footer. Place links to recent posts or popular posts in the footer. Having said that, try to not make it look like a link farm.

Use Appropriate Tags

Use the appropriate tags when developing a site. The heading tags are widely under used. People are instead using generic div tags to encapsulate important information. This is wrong. Strictly looking at the markup alone, the heading tags lets us see the informational hierarchy of the page and this applies for the bots too. Use h1 for the title of the post, h2 for each section’s heading and so on.

If you are including some code, use the pre tag. If you think some information is important feel free to make it bold. Bots tend to place value on bolded text just like we immediately see what the bolded text. As always, use it sparingly. You don’t want to be flagged for spam.

Craft Proper Links

When creating links, try to stay away from the generic read me text. It’s not very SEO friendly. Try to include a part of the child link’s title to the anchor text itself. This is not as hard as it sounds. For example, instead of using read more, use read more about seo. It doesn’t take that much time to change but yields a lot of SEO benefits.

While linking to page on your site, try to make the anchor text as focused as possible. Portfolio is a better candidate than What I’ve Done. The latter sounds more catchy but the former represents better SEO.

Link Internally

Courtesy of Opera

Don’t be scared to interlink the pages in your site. If the number of pages is small, putting it all up on the navigation bar is the way to go. If yours is a big site with a ton of pages, just put all the main category pages on the navigation bar. One way or the other, make sure your pages can be found through links on your site.

Thinking outside the box, you could just as easily include a popular post section on each page. This way you get the interlinking SEO needs and at the same time your visitors can get to see some of the popular posts on your site. It’s a win-win situation.

Make your site Accessible

Remember, search engines are meant to bring people to your site. Which means your site is primarily for human parsing. Design with them in mind.

Include alt attributes for all images on your site. This is not only good practice but also a necessity if you want valid markup. If it’s appropriate include relevant keywords in the alt text. Remember, search bots can’t really look at a picture and decide whether it’s relevant or not. Appropriate keywords lets it make that decision. As always don’t go overboard on the text. Keep it simple and to the point.

Please don’t hide your content behind obnoxious JavaScript or Flash. Spiders can’t go through those to get to your content. And without content, the entire point of your site fails. Miserably. Avoid this unless you absolutely have to.

Avoid Duplicate Content

Google is very strict about duplicate content and severely penalizes sites which do so. This is regardless of whether the content is on different domains. If the same, exact content appears on different pages, the page last indexed is going to be penalized.

This is mostly common sense: don’t have the same content on each page. The footer text can be repeated with no penalties but not if your footer text is big enough to qualify as an article.

Also, your site may dish out alternative print capable pages which might be seen by the search engine as duplicate content. In this case, use robotx.txt to disallow indexing on these pages.

Use robots.txt

Create a robots.txt file to allow/disallow spiders from certain parts of your site. You just create a file named robots.txt and place it at the root of your web site and all co-operating spiders will respect the rules you’ve mentioned in the file.

You can do everything from disallowing all bots from accessing a specific folder to disallowing bots from a specific search engine. Read up more about it here.

Create a Site Map

Courtesy of Opera

A site map lets the search engine know about the existence of pages it might not have discovered through spidering through your site normally. Ideally, you should create a normal HTML site map for your users and an XML site map for the search bots. If at all possible, link both.

Avoid Frames

I can’t say this enough: frames are bad. Both from a web developer perspective and a seo perspective. Content inside frames are virtually invisible to search engines.

More disturbingly, even if one frame of the page gets indexed and is returned as result the result would take you to just the frame without all of its supporting frames inside the parent document. Frames cause undue confusion to people and virtually stop spiders from crawling through your site. Unless you absolutely have to, don’t use frames.

Reduce Code Bloat

And by this I mean 2 things:

Move your JavaScript and CSS to their own separate files. Spiders have no business with them and it is best practice to remove them from the core markup. Create separate files and include them later.

No presentational markup. This is not only SEO friendly but also best practice. Your HTML markup is no place to define how the content should look and similarly the bots have no reason to know how your site is programmed to look. Format the document to your heart’s content in your CSS and leave the markup pristine and clean.

Avoid using a Flash Only Navigation

This is common sense but a lot of designers and developers tend to overlook this. Bots can’t crawl through flash based content and if the only navigation is flash based, the bot has nothing to crawl through.

If your entire site is flash based, it makes sense to create a text only version for spiders and bots to crawl through and find your content. It’ll take extra time to create that but without a text version to fall back on your site will be virtually invisible to search engines.

Use a Common Domain Naming Scheme

Decide on a common naming scheme and stick to it. Personally I prefer www.somename.com but others may like http://somename.com. Decide on a format and stick to it. Use URLs of this format while linking other pages on your site.

Also decide on a whether trailing slashes are required or not. Search engines considers www.somename.com/seo and www.somename.com/seo/ to be different URLs and there is a possibility you are going to be penalized for duplicate content. To get around this, modify your .htaccess file to redirect to the format you like with a 301 redirect. This tells the bot that the page has been moved permanently.

Submit your Site

If your site is newly hatched and hasn’t been indexed yet, it’s a good idea to get the ball rolling by submitting it to search engines and inspiration galleries. This not only let the search engines get to your site early but also brings in a ton of new traffic and back links.

Do not resort to link submitters unless you absolutely trust it. A lot of these submit your links to a number of link farms, an activity which might get you penalized. Just stick to the big search engines and galleries.

Check for Broken Links

Nothing stops spiders dead in their tracks quicker than broken links specially in the home page. Check thoroughly for broken links to ensure the bots have something to start crawling through your site.

Create a proper 404 page in case the search engine leads the visitor to an old URL. Include appropriate links in the error page.

Get Linked by Peer Sites

This is the massive step that is going to take you a lot of time to get right. Ideally, you’d want a lot of sites linking to your site and your posts . Each link to your site is considered as a vote to your site by the linking site. Getting inbound links from sites catering to the same user base is extremely vital since the current way of ranking relies on the fact that if a lot of sites link back to you then the site must contain relevant information.

Unfortunately, this is a long, arduous and never ending task and only one thing can assure you this: good content. Provide good content and sites will automatically start linking to your content. The more sites link to you, the higher your rank is going to be.

Do not resort to illegal means to get back links. This includes link farms and so. Doing anything like this is going to get you kicked out pretty quickly. Accepted means of getting back links includes reciprocal linking where a site places a link to another site in exchange for that site linking back to the original site.

The way I prefer is to write for Net Tuts. Each article I write nets me a back link and Net Tuts being as large as it is, these contribute heavily to my rankings. Plus it brings in a ton of interested new visitors.

Use Appropriate Tools

Tools like Google Analytics helps you analyze and track a number of data including from where your traffic comes from, which pages visitors look at, how much time they spend at each page, how many pages and so on. Use this data to fine tune your site.

Don’t forget Google WebMaster tools. It lets you look at the search queries which bring visitors to your page, whether the spider encountered any error while trying to crawl through your site, which sites link to you and more. Invaluable when you are trying to optimize.

Avoid Black Hat Techniques

I can’t say this enough: don’t try to cheat. Sooner or later, most probably sooner than you think, you are going to be caught and kicked out with no chance of getting listed again. This includes legit sounding techniques like link farms or cross linking to keyword stuffing and keyword dilution.

Just don’t do it.

Wait for the Results

At this point, you’ve hopefully done everything right. The only thing you need to do is sit back, generate some quality content and wait for the rankings to increase. Be patient, this doesn’t happen over night but it definitely happens once you have the basics nailed down.

Continue Learning

These are of course only the tip of the huge iceberg that is search engine optimization. Here are some links to get you started:

• WikiPedia
• Google guidelines
• Yahoo guidelines
• Bing guidelines

• Follow us on Twitter, or subscribe to the Nettuts+ RSS Feed for more daily web development tuts and articles.

Background Info on Regular Expressions

This is what Wikipedia has to say about them:

In computing, regular expressions provide a concise and flexible means for identifying strings of text of interest, such as particular characters, words, or patterns of characters. Regular expressions (abbreviated as regex or regexp, with plural forms regexes, regexps, or regexen) are written in a formal language that can be interpreted by a regular expression processor, a program that either serves as a parser generator or examines text and identifies parts that match the provided specification.

Now, that doesn’t really tell me much about the actual patterns. The regexes I’ll be going over today contains characters such as \w, \s, \1, and many others that represent something totally different from what they look like.

If you’d like to learn a little about regular expressions before you continue reading this article, I’d suggest watching the Regular Expressions for Dummies screencast series.

The eight regular expressions we’ll be going over today will allow you to match a(n): username, password, email, hex value (like #fff or #000), slug, URL, IP address, and an HTML tag. As the list goes down, the regular expressions get more and more confusing. The pictures for each regex in the beginning are easy to follow, but the last four are more easily understood by reading the explanation.

The key thing to remember about regular expressions is that they are almost read forwards and backwards at the same time. This sentence will make more sense when we talk about matching HTML tags.

Note: The delimiters used in the regular expressions are forward slashes, “/”. Each pattern begins and ends with a delimiter. If a forward slash appears in a regex, we must escape it with a backslash: “\/”.

Matching a Username

Pattern:

/^[a-z0-9_-]{3,16}$/

Description:

We begin by telling the parser to find the beginning of the string (^), followed by any lowercase letter (a-z), number (0-9), an underscore, or a hyphen. Next, {3,16} makes sure that are at least 3 of those characters, but no more than 16. Finally, we want the end of the string ($).

String that matches:

my-us3r_n4m3

String that doesn’t match:

th1s1s-wayt00_l0ngt0beausername (too long)

Matching a Password

Pattern:

/^[a-z0-9_-]{6,18}$/

Description:

Matching a password is very similar to matching a username. The only difference is that instead of 3 to 16 letters, numbers, underscores, or hyphens, we want 6 to 18 of them ({6,18}).

String that matches:

myp4ssw0rd

String that doesn’t match:

mypa$$w0rd (contains a dollar sign)

Matching a Hex Value

Pattern:

/^#?([a-f0-9]{6}|[a-f0-9]{3})$/

Description:

We begin by telling the parser to find the beginning of the string (^). Next, a number sign is optional because it is followed a question mark. The question mark tells the parser that the preceding character — in this case a number sign — is optional, but to be “greedy” and capture it if it’s there. Next, inside the first group (first group of parentheses), we can have two different situations. The first is any lowercase letter between a and f or a number six times. The vertical bar tells us that we can also have three lowercase letters between a and f or numbers instead. Finally, we want the end of the string ($).

The reason that I put the six character before is that parser will capture a hex value like #ffffff. If I had reversed it so that the three characters came first, the parser would only pick up #fff and not the other three f’s.

String that matches:

#a3c113

String that doesn’t match:

#4d82h4 (contains the letter h)

Matching a Slug

Pattern:

/^[a-z0-9-]+$/

Description:

You will be using this regex if you ever have to work with mod_rewrite and pretty URL’s. We begin by telling the parser to find the beginning of the string (^), followed by one or more (the plus sign) letters, numbers, or hyphens. Finally, we want the end of the string ($).

String that matches:

my-title-here

String that doesn’t match:

my_title_here (contains underscores)

Matching an Email

Pattern:

/^([a-z0-9_\.-]+)@([\da-z\.-]+)\.([a-z\.]{2,6})$/

Description:

We begin by telling the parser to find the beginning of the string (^). Inside the first group, we match one or more lowercase letters, numbers, underscores, dots, or hyphens. I have escaped the dot because a non-escaped dot means any character. Directly after that, there must be an at sign. Next is the domain name which must be: one or more lowercase letters, numbers, underscores, dots, or hyphens. Then another (escaped) dot, with the extension being two to six letters or dots. I have 2 to 6 because of the country specific TLD’s (.ny.us or .co.uk). Finally, we want the end of the string ($).

String that matches:

john@doe.com

String that doesn’t match:

john@doe.something (TLD is too long)

Matching a URL

Pattern:

/^(https?:\/\/)?([\da-z\.-]+)\.([a-z\.]{2,6})([\/\w \.-]*)*\/?$/

Description:

This regex is almost like taking the ending part of the above regex, slapping it between “http://” and some file structure at the end. It sounds a lot simpler than it really is. To start off, we search for the beginning of the line with the caret.

The first capturing group is all option. It allows the URL to begin with “http://”, “https://”, or neither of them. I have a question mark after the s to allow URL’s that have http or https. In order to make this entire group optional, I just added a question mark to the end of it.

Next is the domain name: one or more numbers, letters, dots, or hypens followed by another dot then two to six letters or dots. The following section is the optional files and directories. Inside the group, we want to match any number of forward slashes, letters, numbers, underscores, spaces, dots, or hyphens. Then we say that this group can be matched as many times as we want. Pretty much this allows multiple directories to be matched along with a file at the end. I have used the star instead of the question mark because the star says zero or more, not zero or one. If a question mark was to be used there, only one file/directory would be able to be matched.

Then a trailing slash is matched, but it can be optional. Finally we end with the end of the line.

String that matches:

http://net.tutsplus.com/about

String that doesn’t match:

http://google.com/some/file!.html (contains an exclamation point)

Matching an IP Address

Pattern:

/^(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$/

Description:

Now, I’m not going to lie, I didn’t write this regex; I got it from here. Now, that doesn’t mean that I can’t rip it apart character for character.

The first capture group really isn’t a captured group because

?:

was placed inside which tells the parser to not capture this group (more on this in the last regex). We also want this non-captured group to be repeated three times — the {3} at the end of the group. This group contains another group, a subgroup, and a literal dot. The parser looks for a match in the subgroup then a dot to move on.

The subgroup is also another non-capture group. It’s just a bunch of character sets (things inside brackets): the string “25″ followed by a number between 0 and 5; or the string “2″ and a number between 0 and 4 and any number; or an optional zero or one followed by two numbers, with the second being optional.

After we match three of those, it’s onto the next non-capturing group. This one wants: the string “25″ followed by a number between 0 and 5; or the string “2″ with a number between 0 and 4 and another number at the end; or an optional zero or one followed by two numbers, with the second being optional.

We end this confusing regex with the end of the string.

String that matches:

73.60.124.136 (no, that is not my IP address )

String that doesn’t match:

256.60.124.136 (the first group must be “25″ and a number between zero and five)

Matching an HTML Tag

Pattern:

/^<([a-z]+)([^<]+)*(?:>(.*)<\/\1>|\s+\/>)$/

Description:

One of the more useful regexes on the list. It matches any HTML tag with the content inside. As usually, we begin with the start of the line.

First comes the tag’s name. It must be one or more letters long. This is the first capture group, it comes in handy when we have to grab the closing tag. The next thing are the tag’s attributes. This is any character but a greater than sign (>). Since this is optional, but I want to match more than one character, the star is used. The plus sign makes up the attribute and value, and the star says as many attributes as you want.

Next comes the third non-capture group. Inside, it will contain either a greater than sign, some content, and a closing tag; or some spaces, a forward slash, and a greater than sign. The first option looks for a greater than sign followed by any number of characters, and the closing tag. \1 is used which represents the content that was captured in the first capturing group. In this case it was the tag’s name. Now, if that couldn’t be matched we want to look for a self closing tag (like an img, br, or hr tag). This needs to have one or more spaces followed by “/>”.

The regex is ended with the end of the line.

String that matches:

<a href=”http://net.tutsplus.com/”>Nettuts+</a>

String that doesn’t match:

<img src=”img.jpg” alt=”My image>” /> (attributes can’t contain greater than signs)

Conclusion

I hope that you have grasped the ideas behind regular expressions a little bit better. Hopefully you’ll be using these regexes in future projects! Many times you won’t need to decipher a regex character by character, but sometimes if you do this it helps you learn. Just remember, don’t be afraid of regular expressions, they might not seem it, but they make your life a lot easier. Just try and pull out a tag’s name from a string without regular expressions!

• Follow us on Twitter, or subscribe to the NETTUTS RSS Feed for more daily web development tuts and articles.

Benefits of Formatted URLs

While some claim pretty URLs help in search engine rankings, the debate here is fierce, we can all agree that pretty URLs make things easier for our users and adds a level of professionalism and polish to any web application. I could go over all the theoretical reasons for this, but I like real-world examples better. Like it or hate it we all must admit that Twitter is a wildly popular web application and part of the reason for that is most certainly how it formats URLs. I can tell anyone in the know that my Twitter username is noahhendrix, and they know my profile can easily be found at twitter.com/noahhendrix. This seemingly simple concept has vast effects in the popularity of your application.

Just to put things in perspective we can look at another popular social networking website, Facebook. Since the site launched in 2004 the profile system has grown and evolved to better tailor to users, but one glaring hole was the URL to a profile. From the time I registered with Facebook my profile was at the URL http://www.facebook.com/profile.php?id=1304880680. That is quite a mouth full, and just recently it appears Facebook has realized that and they launched Facebook vanity URLs. Now I can share my Facebook profile by telling people my Facebook username is “noahhendrix”, which they know can be found by going to facebook.com/noahhendrix. While the odds are that we won’t have an application as popular as Facebook, we can still borrow a few pages from their book.

Quick Overview

A quick overview before we dive into code, in today’s tutorial we will go over two slightly different methods of creating pretty URLs using HTACCESS. The difference between the methods is whether Apache or PHP is doing the heavy lifting to break the URL apart for parsing. I want to point out that mod_rewrite tutorials are almost as old as the internet itself and this is not the first. At the end I will use one of the methods to create a simple application to show how these solutions would look in a real-live website (well not 100% production quality). The service we will create is a URL shortener that can mirrors the functionality of such sites like bit.ly, TinyURL, or su.pr. So without anymore fluff let us look at the code.

Using Apache

First, we can place all of our code in Apache .htaccess files. This could look something like this:

  Options +FollowSymLinks
  RewriteEngine On

  RewriteCond %{SCRIPT_FILENAME} !-d
  RewriteCond %{SCRIPT_FILENAME} !-f

  RewriteRule ^users/(\d+)*$ ./profile.php?id=$1
  RewriteRule ^threads/(\d+)*$ ./thread.php?id=$1

  RewriteRule ^search/(.*)$ ./search.php?query=$1

Let’s start at the top and work our way down to better understand what is going on here. The first line sets the environment up to follow symbolic links using the Options directive. This may or may not be necessary, but some web hosts use symlinks (similar to alias in MacOSX or shortcuts is Windows) for common HTTP request errors and these are usually symlinked files, or at least this is how I understand the reasoning. Next we tell Apache we are going to use the Rewrite Engine. The next two lines are very, very important it restricts rewriting URLs only to paths that do not actually exists. This prevents the rules below from matching example.com/images/logo.png for example. The first prevents existing directories with the !-d flag and the second with !-f means ignore existing files.

The next three lines are the actual URL rewriting commands. Each line creates a rule that tries to match a regular expressions pattern against the incoming URL. Regular expressions, at least for me, are a hard set of rules to remember but I always find it helpful to use this tutorial by Nettut’s own Jeffery Way and the tool he recommends. I found it easy to type in sample URLs we want to match and then try to hack together the pattern.

The first argument is the pattern, between the caret and dollar sign. We tell Apache we want URLs asking for the users directory (an artificial directory, doesn’t have to actually exist) followed by a / and any length of numbers. The parenthesis create a capture group, you can use as many of these as you want, they serve as variables that we can then transplant into our rewrite. The asterisk means the user can enter whatever they want, and it won’t affect the rewrite, this is primarily to handle a trailing slash so example.com/users/123 is the same as example.com/users/123/ as users would expect.

The second argument is the path we want to actually call, this unlike the first must be a real file. We tell Apache to look in the current directory for a file called profile.php and send the parameter id=$1 along with it. Remember the capture group earlier? That is where we get the variable $1, capture groups start at one. This creates a URL on the server like example.com/profile.php?id=123.

This method is great for legacy web applications that have existing URL structures that prevent us from easily rewriting the backend to understand a new URL schema because to the server the URL looks the same, but to the user it looks much nicer.

Using PHP

This next method is great for those who don’t want to distribute too much logic to Apache and feel more comfortable in PHP (or similar scripting languages). The concept here is capture any URL the server receives and push it to a PHP controller page. This comes with the added benefit of control, but greater complexity at the same time. Your HTACCESS file might look something like this:

  Options +FollowSymLinks
  RewriteEngine On

  RewriteCond %{SCRIPT_FILENAME} !-d
  RewriteCond %{SCRIPT_FILENAME} !-f

  RewriteRule ^.*$ ./index.php

Everything is the same as above, except the last line so we will skip to it. Instead of creating a capture group we just tell Apache to grab every URL and redirect it to index.php. What this means is we can do all of our URL handling in PHP without relying too much on stringent URL paths in HTACCESS. Here is what we might do at the top of our index.php file to parse out the URL:

  <?php
    #remove the directory path we don't want
    $request  = str_replace("/envato/pretty/php/", "", $_SERVER['REQUEST_URI']);

    #split the path by '/'
    $params     = split("/", $request);
  ?>

The first line is not necessary unless you application doesn’t live at the root directory, like my demos. I am removing the non-sense part of the URL that I don’t want PHP to worry about. $_SERVER['REQUEST_URI'] is a global server variable that PHP provides and stores the request URL, it generally looks like this:

  /envato/pretty/php/users/query

As you can see it is basically everything after the domain name. Next we split up the remaining part of the virtual path and split it by the / character this allows us to grab individual variables. In my example I just printed the $params array out in the body, of course you will want to do something a little more useful.

One thing you might do is take the first element of the $params array and include a file by that same name and within in the file you can use the second element in the array to execute some code. This might look something like this:

	 <?php
	   #keeps users from requesting any file they want
	   $safe_pages = array("users", "search", "thread");

	   if(in_array($params[0], $safe_pages)) {
	     include($params[0].".php");
	   } else {
	     include("404.php");
	   }
	 ?>

WARNING: The first part of this code is unbelievably important! You absolutely must restrict what pages a user can get so they don’t have the opportunity to print out any page they wish by guessing at file names, like a database configuration file.

Now that we have the soapbox out of the way let’s move on. Next we check if the requested file is in the $safe_pages array, and if it is we include otherwise will include a 404 not found page. In the included page you will see that you have access to the $params array and you can grab whatever data from it that is necessary in your application.

This is great for those who want a little more control and flexibility. It obviously requires quite a bit extra code, so probably better for new projects that won’t require a lot of code to be updated to fit the new URL formats.

A Simple URL Shortner

This last part of the tutorial is going to let us put some use to the code we went over above, and is more or less a “real-life” example. We are going to create a service called shrtr, I made up this name so any other products with this name are not associated with the code I am posting below. Note: I know this is by far not an original concept, and is only meant for demonstration of mod_rewrite. First let’s take a look at the database:

As you can see this is very straightforward, we have only 4 columns:

• id: unique identifier used to reference specific rows
• short: unique string of characters appended to the end of our URL to determine where to redirect
• url: the URL that the short url redirects to
• created_at: a simple timestamp so we know when this URL was created

The Basics

Next, let’s go over the six files we need to create for this application:

• .htaccess: redirects all short urls to serve.php
• create.php: validates URL, creates shortcode, saves to DB
• css/style.css: holds some basic styling information
• db_config.php: store variables for database connections
• index.php: The face of our application with form for entering URL
• serve.php: looks up short URL and redirects to actual URL

That is all we need for our basic example. I will not cover index.php or css/style.css in very great detail because they are have no PHP, and are static files.

# index.php
----
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Makes URLs Shrtr</title>
    <link type="text/css" rel="stylesheet" href="./css/style.css" />
	</head>
	<body>
	 <div id="pagewrap">
  	 <h1>shrt<span class="r">r</span>.me</h1>

  	 <div class="body">
  	   <form action="./create.php" method="post">

  	     <span class="instructions">Type your URL here</span>
  	     <input name="url" type="text" />
  	     <input type="submit" value="shrtr" />

  	   </form>
  	 </div>

	 </div>
	</body>
</html>

The only real interesting to note here is that we submit the form with a field called URL to create.php.

# css/style.css
----
/* reset */
* {
  font-family: Helvetica, sans-serif;
  margin: 0;
  padding: 0;
}

/* site */
html, body { background-color: #008AB8; }
a { color: darkblue; text-decoration: none;}

  #pagewrap {
    margin: 0 auto;
    width: 405px;
  }

    h1 {
      color: white;
      margin: 0;
      text-align: center;
      font-size: 100px;
    }
      h1 .r { color: darkblue; }

    .body {
      -moz-border-radius: 10px;
      -webkit-border-radius: 10px;
      background-color: white;
      text-align: center;
      padding: 50px;
      height: 80px;
      position: relative;
    }

      .body .instructions {
        display: block;
        margin-bottom: 10px;
      }
      .body .back {
        right: 15px;
        top: 10px;
        position: absolute;
      }

      .body input[type=text] {
        display: block;
        font-size: 20px;
        margin-bottom: 5px;
        text-align: center;
        padding: 5px;
        height: 20px;
        width: 300px;
      }

That is all very generic, but makes our application a little more presentable.

The last basic file we need to look at is our db_config.php, I created this to abstract some of the database connection information.

# db_config.php
----
<?php

  $database = "DATABASE_NAME";
  $username = "USERNAME";
  $password = "PASSWORD";
  $host     = "localhost";

?>

You need to replace the values with what works in your database, and host is probably localhost, but you need to double check with your hosting provider to make sure. Here is the SQL dump of the table, url_redirects that holds all the information we showed above:

--
-- Table structure for table `url_redirects`
--

CREATE TABLE IF NOT EXISTS `url_redirects` (
  `id` int(11) NOT NULL auto_increment,
  `short` varchar(10) NOT NULL,
  `url` varchar(255) NOT NULL,
  `created_at` timestamp NOT NULL default CURRENT_TIMESTAMP,
  PRIMARY KEY  (`id`),
  KEY `short` (`short`)
) ENGINE=MyISAM  DEFAULT CHARSET=utf8;

Creating the Short URL

Next lets look at the code necessary to create our short URL.

# create.php
----
<?php
  require("./db_config.php");

  $url = $_REQUEST['url'];

  if(!preg_match("/^[a-zA-Z]+[:\/\/]+[A-Za-z0-9\-_]+\\.+[A-Za-z0-9\.\/%&=\?\-_]+$/i", $url)) {
    $html = "Error: invalid URL";
  } else {

    $db = mysql_connect($host, $username, $password);

      $short = substr(md5(time().$url), 0, 5);

      if(mysql_query("INSERT INTO `".$database."`.`url_redirects` (`short`, `url`) VALUES ('".$short."', '".$url."');", $db)) {
        $html = "Your short URL is<br />shrtr.me/".$short;
      } else {
        $html = "Error: cannot find database";
      }

    mysql_close($db);
  }
?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Makes URLs Shrtr</title>
    <link type="text/css" rel="stylesheet" href="./css/style.css" />
	</head>
	<body>
	 <div id="pagewrap">
  	 <h1>shrt<span class="r">r</span>.me</h1>

  	 <div class="body">
  	   <?= $html ?>
  	   <br /><br />
  	   <span class="back"><a href="./">X</a></span>
  	 </div>

	 </div>
	</body>
</html>

Now we are getting a bit more complex! First we need to include the database connection variables we created earlier, then we store the URL parameter sent to us by the create form in a variable called $url. Next we do some regular expressions magic to check if they actually sent a URL, if not we store an error. If the user entered a valid URL we create a connection to the database using the connection variables we include at the top of page. Next we generate a random 5 character string to save to the database, using the substr function. The string we split up is the md5 hash of the current time() and $url concatenated together. Then we insert that value into the url_redirects table along with the actual URL, and store a string to present to the user. If it fails to insert the data we store an error. If you move down into the HTML part of the page all we do is print out the value of $html, be it error or success. This obviously isn’t the most elegant solution but it works!

Serving the Short URL

So we have the URL in the database let’s work on serve.php so we can actually translate the short code into a redirect.

<?php
  require("./db_config.php");

  $short = $_REQUEST['short'];

  $db = mysql_connect($host, $username, $password);
    $query = mysql_query("SELECT * FROM `".$database."`.`url_redirects` WHERE `short`='".mysql_escape_string($short)."' LIMIT 1", $db);
    $row = mysql_fetch_row($query);

    if(!empty($row)) {
      Header("HTTP/1.1 301 Moved Permanently");
      header("Location: ".$row[2]."");
    } else {
      $html = "Error: cannot find short URL";
    }

  mysql_close($db);
?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Makes URLs Shrtr</title>
    <link type="text/css" rel="stylesheet" href="./css/style.css" />
	</head>
	<body>
	 <div id="pagewrap">
  	 <h1>shrt<span class="r">r</span>.me</h1>

  	 <div class="body">
  	   <?= $html ?>
  	   <br /><br />
  	   <span class="back"><a href="./">X</a></span>
  	 </div>

	 </div>
	</body>
</html>

This one is very similar to create.php we include the database information, and store the short code sent to us in a variable called $short. Next we query the database for the URL of that short code. If we get a result we redirect to the URL, if not we print out an error like before.

As far as PHP goes that is all we need to do, but at the moment to share a short URL users must enter this, http://shrtr.me/server.php?short=SHORT_CODE not very pretty is it? Let’s see if we can’t incorporate some mod_rewrite code to make this nicer.

Pretty-ify With HTACCESS

Of the two methods I wrote about at the beginning of the tutorial we will use the Apache one because this application is already created without considering any URL parsing. The code will look something like this:

  Options +FollowSymLinks
  RewriteEngine On

  RewriteCond %{SCRIPT_FILENAME} !-d
  RewriteCond %{SCRIPT_FILENAME} !-f

  RewriteRule ^(\w+)$ ./serve.php?short=$1

Skipping to the RewriteRule we are directing any traffic that doesn’t already have a real file or directory to serve.php and putting the extension in the GET variable short. Not to bad no go try it out for yourself!

Conclusion

Today we learned a few different ways to utilize mod_rewrite in our application to make our URLs pretty. As always I will be watching over the comments if anybody has trouble, or you can contact me on twitter. Thanks for reading!

• Follow us on Twitter, or subscribe to the NETTUTS RSS Feed for more daily web development tuts and articles.

Requirements

Htaccess files are plain-text configuration files used by the Apache HTTP web server. They allow users to set directory level options without requiring access to the httpd.conf file. As such it is required that your server uses Apache, and a web host that allows htaccess files (the most popular hosts do).

I assume a basic working knowledge of htaccess, but if you need to freshen up check out this article by Joseph Pecoraro

1. Prevent Hotlinking

Hotlinking, or inline linking, is when one web site links directly to an object on another site. This costs the hosting site bandwidth to provide the image on the page of the second site. On popular photo sites this can be a major problem, albeit humorous at times.

http://www.shapelessmass.com

There are ways to fix this growing problem using htaccess. First here is the image we are trying to protect.

  RewriteEngine on
  RewriteCond %{HTTP_REFERER} !^$

  #domains that can link to images
  #add as many as you want
    RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?demo.collegeaintcheap.com [NC]
    # RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?noahhendrix.com [NC]

  #show no image when hotlinked
    RewriteRule \.(jpg|png|gif)$ - [NC,F,L]

We will step through this line-by-line.

1. First we need to turn on the rewrite engine in Apache, this allows us to redirect the user’s request.
2. Next we start setting our conditions using RewriteCond. This is a function that takes two arguments: TestString and CondPattern. TestString is the string we want to check our CondPattern against (using regular expressions). ${HTTP_REFERER} is a variable provided by Apache that holds the domain the request came from, in this instance we want to allow requests from blank HTTP referrers to protect users who are on a proxy server that sends blank referrers.
3. Next we set the domains from which we will allow our images to be linked using the same syntax except now we provide a URL. The [NC] flag at the end of the command simply instructs the engine to ignore casing. You can add as many lines domains as you’d like here, using the same syntax. For the sake of example I added my personal domain, but commented it out.
4. Finally, the last line is the RewriteRule we wish to use if any of the conditions above are not met. It takes two arguments as well Pattern and Substitution, where pattern is a regular expression match and substitution is what we want to replace any matches with. In this case we are looking for requests that end in jpg, png, and gif; if found we want to use a blank substitution. However in the flags we tell it furthermore what we want to be done, NC means no case, F sends a 403 forbidden error to user, and L tells the engine to stop rewriting so no other rules are applied.

This is fairly straightforward, but perhaps we are interested in telling the user we don’t want them to hotlink our images, so let’s redirect all hotlinked requests to an image instead of sending a 403 forbidden error. This is done by replacing the last line with this code.

  #show an alternate image
    RewriteRule \.(jpg|png|gif)$ http://demo.collegeaintcheap.com/envato/htaccess/hotlink/images/hotlink.jpeg [NC,R,L]

You can change url to any image path you’d like on your domain, but remember it needs to not end in jpg, png, or gif as it will reapply the rule and send the server into a never-ending loop. I chose to use the older .jpeg extension to fix this. The R flag that replaced F simply sends a redirect.

2. Block User By IP Address

This is a great little tip if you have a spammer on your website. If you can find their IP in your logs, simply add it to an htaccess file.

  Order Deny,Allow
  Deny from 24.121.202.23
  # Deny from 0.0.0.0

Using the Order directive in the mod_access module we can specify IPs to deny and allow. Simply using the syntax Deny from IP ADDRESS we can forbid those users from accessing our directory.

3. Error Documents

All production ready sites should use custom error pages for a professional touch. This is easy using the ErrorDocument directive in Apache’s core. A custom page is far better than the default Apache error pages.

  ErrorDocument 404 http://demo.collegeaintcheap.com/envato/htaccess/errors/404.html
  ErrorDocument 403 http://demo.collegeaintcheap.com/envato/htaccess/errors/403.html
  ErrorDocument 500 http://demo.collegeaintcheap.com/envato/htaccess/errors/500.html

ErrorDocument takes two arguments error-code and document. In the code above I created error documents for the 3 most common HTTP errors: 404 not found, 403 forbidden, and 500 server error. Then you can provide the full URL or relative path to your error documents. You could also them redirect to a PHP script that logs the errors in a database or emails them to you (might get annoying though). This is a great way to take control of errors in your web application, be sure to check out Smashing Magazine’s 404 error page showcase for inspiration.

4. Redirect While Performing Upgrades

If you are performing a major site upgrade you most likely should redirect users to a page informing them. This prevents users from seeing broken pages or potential security holes while the application is uploading. One caveat to consider is that we want to allow certain IP addresses into the site for testing before it goes live all of this can be achieved in an htaccess file.

  RewriteEngine on
  RewriteCond %{REQUEST_URI} !/upgrade.html$
  RewriteCond %{REMOTE_HOST} !^24\.121\.202\.30
  RewriteRule $ http://demo.collegeaintcheap.com/envato/htaccess/upgrade/upgrade.html [R=302,L]

We are using the rewrite engine again to do this, but in a kind of reverse way. First we need to set a condition that excludes the document describing the upgrade otherwise our server start a never ending loop. Next we exclude a single IP address from being redirected for testing purposes. Finally we use the rewrite rule to send users to an upgrade page. The flags we have looked at before, except this time we setting the redirect to a 302 status code, telling the browser that the page has temporarily moved and to handle caching accordingly. Smashing Magazine, again, has a great showcase of Effective Maintenance Pages.

5. Hiding Directory Listing

For numerous security reasons it is a good idea to restrict directory listing, the default behavior in Apache. This can be done with a simple line in our htaccess file we can prevent visitors from seeing our directory listings.

  Options -Indexes

Now users who request a directory that doesn’t have an index file it will show them a 403 forbidden error page.

Conclusion

These are several of my favorite uses of htaccess. Leave yours in the comments! I am available for help in the comments or on twitter. If there is a great deal of interest, I will do more htaccess tutorials with solutions to your requests in the comments. Thanks for reading!

• Follow us on Twitter, or subscribe to the NETTUTS RSS Feed for more daily web development tuts and articles.

The Application

Briefly, I will go over the demo application. I have a very simple, static HTML page that shows a photo and allows the user to comment on it. In a real application you would probably save the comments to a database, but for the sake of demonstration I just save them to a text file with each line representing a new comment. This code isn’t particularly important until you get to the add comment form.

# index.php
...
<div class="new-comment">
  <h2 class="sub-title">Add A Comment</h2>

  <form action="php/savecomment.php" id="comment-form" method="post">
    <div id="userbox" style="display:none;"></div>

    <div id="userinfo">

      Name: <input id="name" name="name" type="text" />
      <input id="url" name="url" type="hidden" />
      <input id="image" name="image" type="hidden" />

    </div>

    <div class="comment">
      Comment:<br />
      <textarea id="comment" name="comment"></textarea>
    </div>
    <input type="submit" value="Send Comment" />
  </form>

</div>
...

Here you see we have a basic form with four fields: name, url, image, and comment. I chose to hide the url and image fields because this is data we will get from Facebook and Google Friend Connect. The form is submitted to a PHP file, savecomment.php, which I won’t go over but is included in the download. In essence it takes all the post data and stores in an existing comments data file with pipe, “|”, characters separating each field. Again, not a practical technique but sufficient for our purposes. A little above the form we list out all the comments in that file by including another PHP script, readcomments.php.

# index.php
...
<div class="comments">
  <h2 class="sub-title">Comments</h2>

  <?php include("php/readcomments.php"); ?>
</div>
...

One last piece of code we need to look at is the JavaScript includes. All of our authentication is done on the client side, so I created application.js to hold the code responsible for that, and to save myself from writing too much JavaScript I included jQuery (via Google).

# index.php
---
<head>
...
  <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
  <script src="./js/application.js" type="text/javascript"></script>
</head>

Updating The Page to Show User’s Information.

After creating this we can move into the application.js file mentioned earlier. I decided that it would be best to create a function for each service that wrapped all the logic required in authentication. Then, after creating these for both services I extracted out common code to keep the code concise. After creating the file declare a function called update_userbox()

# application.js
---
//Generic updates #userbox with info retrieved
//from services
function update_userbox(name, image, url, logout) {

  //populate the data in #userbox and show it
  $('#userbox').html( "<a href='"+url+"'>"
                    + "<img alt='"+name+"' src='"+image+"' />"
                    + "Logged in as " + name + "</a> "
                    + "(<a href='./index.php' onclick='" + logout + "'>logout</a>)" ).show();

  //hide name input and service
  //login buttons
  $('#userinfo').hide();

  //populate the values of the inputs
  //using data from service
  $('#name').val(name);
  $('#url').val(url);
  $('#image').val(image);

}

This function is generic and can be used with either service, and as more spring up could probably be used in others as well. The purpose of this is to insert HTML into an empty div called #userbox so the user has a visual understanding that they logged into a service. This is done by hiding the name box, and showing a profile image from the remote service along with their name and a logout link to disconnect from the service. Also behind the scenes we fill in the name, url, and image inputs so they are submitted to the server along with the comment for saving to our database file. You can see this is done by passing in four variables:

• name: the user’s name they provided to the service
• image: a url to the user’s profile image
• url: a url to the user’s profile on the service
• logout: a string of JS code to execute when logout is pressed

These are all pretty straightforward, except the logout variable. This can be explained when you look at the APIs that FB and GFC offer. Each has function that will notify the service that the user wishes to be logged out, this is how I chose to pass that function call into the logout link.

Facebook Connect – Getting Your API Key

We will start with Facebook Connect. The first thing we will need to do is create an application on Facebook’s Developers site. It seems a bit odd at first that we have to create a Facebook application for this, but as far as I can tell it is only to receive the API key and to register your URLs with their developer program.

After you have created the application we need to edit some settings, on the left side of the screen you will see tabs, click on Connect. Here you need to enter the Connect URL which is the URL where the root of your site exists. I also chose to upload a picture, and I recommend all websites do this as it gives you some visual branding.

Alright now you can save these changes and it will take you to the application summary page. Here is where we can find the application API key, so go ahead and copy that on to your clipboard.

Adding A Cross-Domain Receiver

Facebook architected their connect API to work entirely on the client side. This tutorial will require no server side code to authenticate users. This is done through some intricate AJAX techniques where Facebook passes data back and forth via iframes to circumvent the same-origin policy implemented by most browsers. Part of this process requires that we place a file on our server that Facebook can interact with to verify our identity. So at the top-level of your domain create a file called xd_receiver.html and insert this code.

# xd_receiver.html
---
<pre name="code" class="html">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
    <script src="http://static.ak.connect.facebook.com/js/api_lib/v0.4/XdCommReceiver.js" type="text/javascript"></script>
</body>
</html>
</pre>

The Facebook Connect Button

Facebook requires us to jump through a few hoops to get everything working, first of which is we need to include a JS file from the Facebook website and run the init() function in our index.php file at very bottom just above the closing </body> tag.

# index.php
---
<!-- Facebook API Includes -->
<script src="http://static.ak.connect.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php" type="text/javascript"></script>
<script type="text/javascript">
  FB.init("FB_API_KEY", "xd_receiver.htm", {"ifUserConnected" : auth_using_fb});
</script>

There are a few things we need to look at in this function. First, be sure to replace FB_API_KEY with your API key. Next we have a string representing the path to our cross-domain receiver file which should be at the root of your application directory. Finally, we can pass in a hash of options. We want to maintain users’ login state so we tell Facebook to run a function auth_using_fb (we will create this in a few moments) if the user is already connected to our site. This means that if the user reloads the page it will still show them as logged in so they don’t have to re-login on every page.

Next we have to create the actual login button, this requires using XFBML, Facebook Markup Language which is an extension to HTML. The X denotes code that is inserted on 3rd party websites and not on Facebook’s website. Somewhere on the page we have to insert the tag Fb:login-button and a few options.

  <fb:login-button length="long" onlogin="auth_using_fb();"></fb:login-button>

I chose to put this next to my name textbox so the user could easily see it when they go to add a comment. Notice we have two attributes length and onlogin. Length allows us to specify the text on the button and has two options: short (the default) and long. Short says Connect and long says Connect with Facebook. Onlogin works a lot like onclick or onmouseover and allows us to execute JS when the user successfully authenticates with our site through Facebook. We call the same function we mentioned earlier, auth_using_fb(), but before we can create that we need to make one more change. At the top of the page in the HTML tag we need to tell the browser we are using more than one markup language.

# index.php
---
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:fb="http://www.facebook.com/2008/fbml">

The xmlns attribute specifies the xml namespace for the document. The first is the standard xhtml, and the second is the new facebook markup language, this helps make our document W3C compliant.

Writing the Javascript

Now we are going to go back to application.js and write the auth_using_fb() function.

# application.js
---
//Facebook Connect
function auth_using_fb() {
  //get the users data from FB
  var viewer  = FB.Facebook.apiClient.fql_query(

      'SELECT name, pic_square_with_logo,profile_url FROM user WHERE uid='+FB.Facebook.apiClient.get_session().uid,

      function(results) {
        update_userbox( results[0].name,
                        results[0].pic_square_with_logo,
                        results[0].profile_url,
                        'FB.Connect.logoutAndRedirect("./index.php");return false;')
      }
  );
}

This is the function we use to interface with Facebook’s data, and retrieve users’ data. The login button we created earlier actually has the functionality for signing the user into Facebook built-in, but if want to grab the information about the user we must request it separately. The first line of code in the function is a call to the Facebook API method, fql_query(). This function allows us to use Facebook’s SQL like query language to fetch the user’s data. We only need the three columns we discussed earlier: name, picture, and url. The Facebook Developer wiki has a page containing all the various tables that you can query for information. It is important to add the WHERE clause that limits to the currently logged in user. The second parameter of fql_query is a callback function that is passed an array of the results. We just need to take the first result in the array and send each property to our update_userbox() function along with the logout JS call. It is important to include “return false;” after the logoutAndRedirect() call because otherwise it causes the page to reload before the API can log out the user.

And amazingly that is all we need to do for Facebook Connect to work, go ahead and try it out!

Google Friend Connect – API Key

Much like Facebook Connect, Google Friend Connect requires us to sign up for an API Key. This is far quicker than Facebook Connect as they have an easy-to-use wizard that walks you through it all. First you need to provide the application name and URL just like in Facebook Connect.

Next it instructs you to upload a few files to your server for cross-domain AJAX support, again just like Facebook Connect. Seeing a trend here?

The final step will verify that everything is setup properly. Google calls the API Key the Site ID, but it acts the exact same Facebook’s API key.

Including the Necessary Files

Next we need to include the proper JS files at the bottom of our page after the Facebook files. We also need to implement the initOpenSocialApi() method of the Google Friend Connect API. This takes one parameter in the form of a hash of options. The only required option is site which is our Site ID we collected earlier.

# index.php
---
<!-- Google API Includes -->
<script src="http://www.google.com/friendconnect/script/friendconnect.js?v=0.8" type="text/javascript"></script>

<!-- Initialize the Google Friend Connect OpenSocial API. -->
<script type="text/javascript">
  google.friendconnect.container.setParentUrl('/envato/nologin/' /* location of rpc_relay.html and canvas.html */);
  google.friendconnect.container.initOpenSocialApi({
    site: 'GFC_API_KEY',
    onload: function(securityToken) { auth_using_gfc(); }
  });
  google.friendconnect.renderSignInButton({id:"google-login",style:'long'})
</script>

We also need to page in a callback function to execute when the user is authenticated with Google Friend Connect. Additionally we have to call a function that renders the sign in button, this is very similar to the XFBML markup we used earlier except Google decided to stick with plain HTML. This function requires we pass it a DOM id of the element we want the signin button to be created in, I made a div just below the FB login button with an id of google-login. We also pass in the style:’long’ option so that it is similar to our Facebook button.

<div class="services">
  <fb:login-button length="long" onlogin="auth_using_fb();"></fb:login-button>
  <div id="google-login"></div>
</div>

Writing the JavaScript

Google Friend Connect is similar in many ways to Facebook Connect, which of course makes our job all the easier. One language difference I found is that Google’s API tends to be a bit more verbose in nature so we will split our explanation of auth_using_gfc() into two parts.

//Google Friend Connect
function auth_using_gfc() {
  //Request GFC to send extra profile data
  var params = {};
      params[opensocial.DataRequest.PeopleRequestFields.PROFILE_DETAILS] =
      [opensocial.Person.Field.URLS];

  // Create a request to grab the current viewer.
  var req = opensocial.newDataRequest();
  req.add(req.newFetchPersonRequest('VIEWER', params), 'viewer_data');
...

The first thing we do is declare the params variable as an empty hash. This will contain the options we need to send with our request to Google, because by default we do not receive the user’s profile URL. Next we create a request object that will actually make the request to Google for the user’s profile data. The add() method takes two arguments a newFetchPersonRequest() object and then a unique string to identify the data. VIEWER is a constant representing the currently logged in user.

// Sent the request
req.send(function(data) {

  // If the view_data had an error, then user is not signed in
  if (!data.get('viewer_data').hadError()) {
    //get the users data from GFC
    var viewer = data.get('viewer_data').getData();

    update_userbox( viewer.getDisplayName(),
                    viewer.getField(opensocial.Person.Field.THUMBNAIL_URL),
                    viewer.getField(opensocial.Person.Field.URLS)[0].getField('address'),
                    'google.friendconnect.requestSignOut()' );
  }

});

The last part of the function is the actual request for data, using the send() method which takes one argument of a callback function. We declare the function inline and we have an if statement that checks weather the request received an error. If it doesn’t we assume everything went alright and we declare a variable called view that holds the data received from the request. This data is then passed into our update_userbox() function. The only thing to note here is the the third argument that passes in the user’s URL. Google allows users to enter multiple profile URLs (such as Facebook, Twitter, etc.) and we only need the first one which is the Google profile URL. The final argument is our string of JS to execute that signs the user out which also reloads the page.

This is all we need to do, so go ahead and try it out! One really nice thing you’ll notice is that user’s don’t have to have a Google account to login they can also use their AOL/AIM, Yahoo!, Netlog, or Open ID accounts.

Conclusion

While this specific example is not production ready, hopefully you can see how easy it would be for us to implement this into our existing applications. I encourage everyone to take a good look over the documentation Facebook and Google offer.

• Facebook Connect Documentation
• FBC Tutorial
• FQL Simulator
• Google Friend Connect Documentation
• GFC Example Code
• GFC Simulator

I hope you enjoyed this tutorial, and if there is enough interest, I will write a follow-up tutorial on how this can be further integrated using PHP on the server-side. As always, if anyone needs help or you can find me on Twitter, @noahhendrix.

• Follow us on Twitter, or subscribe to the NETTUTS RSS Feed for more daily web development tuts and articles.

WebApps vs. Native Apps

Keep in mind that a web application runs in the browser, while a native application is installed on the iPhone.
So, if you want to make something like a high-performance, fast-responsive, action-packed game with awesome graphics, then you’re probably better
off just learning Objective-C and making a native app. However, if you don’t own a Mac and/or if you are trying to do something a lot simpler, like
making a mobile version of your website or blog, then making a web app might be the faster and more reasonable road to take.

Still not convinced? Here are a list of popular sites that are iPhone web apps/websites:

• iphone.facebook.com
• m.digg.com
• hotels.com/iphone
• iphone.fmylife.com
• iphone.coldwellbanker.com

The list goes on…
If you’re REALLY smart, you’ll make BOTH a native app(hopefully free) and web app, like most of the sites above did.

1: Viewport, Viewport, Viewport

I would say this may be the simplest and most important thing for an iPhone web app. It’s just one line of code to include within your head tags:

	<!-- add this in your <head> section with your other meta tags-->
    <meta name="viewport" content="width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" />

This tells the browser to scale your page in such a way that will make it fit nicely on the iPhone. Here’s what each field means:

• width=device-width
  This fits the page to the device’s width. The iPhone’s display is 320×480 pixels in portrait mode, and 480×320 pixels in landscape mode, which is why you sometimes see sites use width=320 instead of width=device-width.
• initial-scale=1.0
  This is the scaling when the page first loads up.
• maximum-scale=1.0
  This is the maximum scaling allowed.
• user-scalable=0
  This determines whether the user is allowed to zoom in and out by pinching/double-tapping. You can also use user-scalable=no and user-scalable=yes instead of 0 and 1.

Keep in mind that the viewport IS NOT A WINDOW. Think of it like a magnifying glass over a page. You can move the magnifying glass around and zoom in/out.
This is why certain features like fixed positioning don’t work on the iPhone(at least at the time of this writing). In Professional iPhone and iPod touch Programming, Richard Wagner explains what a viewport is:

A viewport is a rectangular area of screen space within which an application is displayed. Traditional
Windows and Mac desktop applications are contained inside their own windows. Web apps are displayed
inside a browser window. A user can manipulate what is seen inside of the viewport by resizing the
window, scrolling its contents, and in many cases, changing the zoom level.

Specifying the viewport is a *must-have* and is the first step into making your web app iPhone-friendly.

2: "Hide" the Address Bar!

The address bar takes up a considerable portion of the already tiny screen we have to work with. You’ll want to hide the address bar to display as much information on the screen as you can, so that the user doesn’t have to flick down. Consider the picture below. Is that the whole screen, or is there more information below?

With the address bar

Now let us hide the address bar by adding this single line of javascript code:

//add this in your javascript code to 'hide' the address bar
window.scrollTo(0, 1);

This will "hide" the address bar by scrolling down just enough so that you won’t see it when loading the page. In our picture below, we see that there was more information to be displayed after all!

Without the address bar

Notice that this only temporarily hides the address bar by just scrolling down a bit upon loading the page. Permanently hiding the address bar may not be the best idea, but it is possible. For safety’s sake, we’ll leave that outside of the scope of this article.

3: Test on iPhone AND Browsers

Although your ultimate goal is to put your web app on the iPhone, testing it on normal browsers can be beneficial!

Remember, since this is a web application, you can test it like one! That means useful tools like Firebug, Web Developer, and YSlow still work!

"A firebug error!? But that’s impossible…my code is always perfect!"

NOTE: You may get errors for certain pieces of code that are legitimate — iPhone-specific/webkit-specific code mostly. With that said, don’t be too dependent on these tools…they are more of a guide, not an oracle.

Keep in mind also that Firefox may display things differenty than Safari does, and Safari is also different from Mobile Safari. You’ll most certainly notice web apps that you develop in Dashcode won’t display properly on Firefox.
This is why you still need to test on an iPhone. If you do however, develop in Dashcode, there are testing/debugging features that come with it.

4: Mimic a Native App if Possible

From a usability perspective, making your web app look like a native iPhone app is beneficial because users already know how to use an iPhone application, thus there is a positive transfer of knowledge.
Besides that, using the buttons, font, lists, etc is also beneficial. A lot of time and money was put into researching what would be a good design…Apple must have hired various usability and design experts.
If you mimic a native app, you won’t have to go through the whole process of designing and creating something that may in the end prove infeasible.

Take a look at the picture below…this is the "Groups" menu from the "Contacts" feature. Can you guess whether this is the real deal(native app), or a fake(webapp mimic)?

Native app or web app?

If you guessed that the above pic is a web app, you are correct! See how closely you can mimic a native app?

If you do not wish to mimic a native iPhone web app, perhaps because your application doesn’t fit well that way or because you want to maintain your style, then at least follow some basic guidelines:

• Be consistent (i.e: navigation buttons on each page)
• Make buttons large enough to tap (i.e: for fat fingers or the error-prone)
• Make things intuitive (i.e: collapsible boxes should have hint…like a +/- next to it)

5: Use Frameworks, Libraries, and Tools to Save Time

If you do decide to mimic a native app, then I suggest not starting from scratch. There are many things out there that can save you a ton of time:

• 
  Dashcode
  If you have a Mac, this may be the best route to go if you want to whip up something fast. Dashcode has a parts library(i.e: buttons/frames), a code snippets library, a workflow steps guide, and way more!
• iUI
  Created by Joe Hewitt, this nice little framework lets you create web apps with simple HTML! It has a nice slide-effect too. Performance is FAST and the framework itself is very tiny filesize-wise.
• iWebkit
  Just like iUI, you can create your app with simple HTML. However, this framework has many features that other frameworks might not have. It also comes with a user guide which clearly explains how to use the features.
  What makes this my favorite framework is that it plays nice with other javascript code, so I can customize my web app and do things like make collapsible boxes

There are, of course, many other frameworks, libraries, and tools, but as to date, these are my favorite ones. Have one that you really like? Write it in the comments below!

iWebkit’s pop-up feature

6: Use Lists When Possible

Lists are a nice quick n’ dirty way of displaying information. "Contacts" and "Mail" display information in the form of lists. Lists allow for easy navigation, let you display a lot of items on the tiny screen, and are easy to touch compared to pictures.
They also load pretty fast since they’re just text. Lists will almost always be your navigation method of choice, but then again it really depends on what your web app is.

If you do use a list, grouping items by alphabet, relevance, or usage is always a good way to go.

A list with items grouped by alphabet

7: Minimize Horizontal Navigation

If possible, minimize the number of screens your users have to navigate to in order to get the information they want.
Having less pages to jump to means less redirecting and unnecessary loading by going backwards and forewards.

Many navigation screens

In the example picture above, we can possibly eliminate the first two screens by automatically getting the date/time and start out with the third screen.
If a user wants to intentionally pick and different day/time, we can have that in the "Change View" menu.

8: Make Your App Small and Fast

Remember that performance is critical in the mobile world, as a user may be on the EDGE network or just have a slow connection. Give them as little to download as possible! Just like normal web sites, the same rules of enhancing performance apply. Instead of
giving you a checklist of everything, I would just recommend that you get both Page Speed and YSlow, as these
give more detailed checklists on beefing up performance than I could ever give.

Not bad for a framework that has a .js file, a .css file, and a bunch of images, huh?

9: Have a Homescreen Icon

Make sure to have a nice icon that people can see when they add your web app to their homescreen. Make a 57×57 PNG file and add the following code to your home page:

	<!-- add this in your <head> section -->
    <link href="path/to/your/icon.png" rel="apple-touch-icon" />

Having an icon is a good way to quickly recognize your web app, as well as look professional while having some nice eye-candy.

10: iPhone ‘Simulators’ aren’t Perfect

You will notice that iPhone simulators, even the official "Aspen Simulator", can sometimes yield different results than on the iPhone. This is true even when making native apps. This should actually be somewhat expected since the iPhone OS is different from Mac OS and the iPhone architecture is different from a normal computer. I want people to know about this, because I’ve had quite a few friends
develop and test mainly on "simulators" only to find out near final production/deployment that their program on the iPhone was buggy, crashed, or simply just didn’t work. Please be careful when using a simulator–they are here for convenience, NOT for iPhone replacement. Remember that since your ultimate goal is to put something on the iPhone, then test on the iPhone. Since you are making a web app and not a native app, you won’t need to worry about paying the developer fee or becoming a registered developer with Apple.

Simulator FAIL

Conclusion

I hope you enjoyed this article! One of the joys of making a web app is you can develop on any platform! I tried to keep the tips as cross-platform as possible. However, although this is true, it still might be the best idea to develop on a Mac.

There are many other important tips that I did not mention here, simply because other people have beaten me to the punch! If you are really serious about iPhone web app development, go out there and learn more! There are plenty of resources that your best friend
can give you that I would not know about.

Have any tips of your own? Want to call me out on tips that are nonsense? Share your knowledge by writing in the comments below! I love learning new things and I definitely want to be corrected if I am wrong.

• Please subscribe to the Theme Forest RSS Feed, and follow us on Twitter.