# Using .htaccess Files for Pretty URLs

Continuing our review of .htaccess files, today we'll examine how to use mod_rewrite to create pretty URLs.

### 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 add 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 on the popularity of your application.

## Overview and Setup

If you plan to follow along, you need to install a PHP development environment on your computer, and you can go for either WAMP or XAMPP. Both of these packages come bundled with the Apache server, which provides the modules we are going to use.

Create the following folder and files in your web server root directory.

The folder demo contains four files: home.php, article.php, profile.php, and .htaccess.

In the absence of an index.php file, we'll use .htaccess to set home.php as our index page. That way, it'll show at the URL localhost/demo/.

In the HTML markup for home.php, we'll provide a link to our article page.

We added a query string to the URL containing three variables that we want to pass to the article: year, month, and slug. Later, we'll use the .htaccess to configure our server to use a cleaner, well-structured URL whilst ensuring that the page still gets the query strings.

Inside article.php, we get these variables from the request URL and display them on the page:

## The .htaccess File

.htaccess is a server configuration file used to control websites. In using an Apache server, this file provides a way to reconfigure your server without having to manually edit the server configuration files.

Since we'll be working with the request URLs, we'll use the mod_rewrite Apache module to manipulate incoming URLs on the server-side.

We'll make all rewrites and reconfigurations inside the <IfModule> directive.

The instructions inside this directive will run only if mod_rewrite is loaded by Apache. To make any modifications, we must first enable the RewriteEngine on our Apache server.

In the nested directive just below, we set the environment up to follow symbolic links using the Options directive.

With the base configuration all set, let's take a look at some of the ways we can improve our URLs using Apache and PHP.

## Making URLs Cleaner With .htaccess

### Setting Alternative Index Files

Recall that our site doesn't have a default page, and this is because the index.php file is absent in the directory. In cases where you want to use an alternative PHP script file as your site's index, use DirectoryIndex

Below, we are manually making home.php our index page by pointing DirectoryIndex to that file.

### Formatting URLs Using Apache

Unclean URLs expose the filenames of underlying server scripts and variables used in rendering the page. For example, a person can easily make out that the profile.php file is responsible for loading the page based on the URL example.com/profile.php?id=1.

By using clean URLs, you can help secure the site by hiding the structure of your application's back end. For example, based on the URL example.com/user/1, it's impossible to tell what server-side scripting file is responsible for rendering the page.

Let's match an alternative URL that we want the user to see:

The string of text you have after the caret symbol is the alternative directory listing that you want in place of the actual URL. Now when we navigate to /user on our site, it'll actually take us to profile.php

#### Passing Variables

Some of our URLs may contain dynamic variables. Take the following, for example: https://localhost/demo/article?year=2022&month=3&slug=using-htaccess-to-prettify-url

Going back to article.php, recall that we got the variables from the query string in the URL because the page requires these variables to render:

To display the article page, we must add the query string to the URL: article?year=2022&month=3&slug=using-htaccess-to-prettify-url

This URL is neither SEO- nor user-friendly. A significantly better URL would be: article/2022/3/using-htaccess-to-prettify-url

However, changing the URL to this will give an Undefined Index error because the query string is no longer being sent to the page via the URL, and this is where .htaccess comes into play.

To solve this problem, we need to write a regular expression (regex) to match our intended semantic URL, and then pass query variables from each capture group to article.php:

We'll only match a URL that contains the path articles/ followed by a double-digit number for the article year and month, followed by a string for the post slug which could contain text, numbers, hyphens, and an underscore.

When a request's URL matches the provided regex, we tell the server to redirect to article.php. Most importantly, we pass the query strings along to the page.

For the query string, the three capture groups, denoted by $1, $2, and $3 respectively, are all transplanted into the variables year, month, and slug. We end the rule with two flags. The first flag, NC (Non-case sensitive), tells Apache not to consider the case when matching the URL with our regex. The second flag, L, tells Apache to stop code execution thereafter. Finally, replace +SymLinksIfOwnerMatch with -MultiViews. Navigate to localhost/demo/article/2022/3/using-htaccess-to-prettify-url on your browser and you'll find that our page is still able to access the variables without using URL query strings. Keep in mind that the order is important. So, for example, if you reorder the variables in the query string like in the following instance: You also need to reorganize the regular expression groups to match them. ### 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 to 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: Instead of creating a capture group, we just tell Apache to grab every URL and redirect it to home.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 home.php file to parse out the URL: The first line is not necessary unless your 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:

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.

One thing you might do is take the first element of the $params array and include a file by that same name. Then, within the file, you can use the second, third, and subsequent elements in the array (i.e. the queries) to execute some code (such as fetching from the database). This might look something like this: 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, we will include a 404 not found page. On 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 for your application. This is great for those who want a little more control and flexibility. It obviously requires quite a bit of extra code, so it's 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 Shortener This last part of the tutorial is going to let us put the code we went over above into practice, and it's 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). I know this is not an original concept, and it's only meant for a demonstration of mod_rewrite. First, let's take a look at the database: As you can see, this is very straightforward. We have only four 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 the database • css/style.css: holds some basic styling information • db_config.php: store variables for database connections • index.php: the face of our application with a form for entering URLs • serve.php: looks up a short URL and redirects to an 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 static files with no PHP. The only interesting to note here is that we submit the form with a field called URL to create.php. That is all very generic, but it 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. 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, which holds all the information we showed above: ### Creating the Short URL Next, let's look at the code necessary to create our short URL. Now we are getting a bit more complex! First, we need to include the database connection variables we created earlier, and 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, and 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 the page. Next, we generate a random five-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. Now, let's work on serve.php so we can actually translate the short code into a redirect.

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. However, 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.

### Prettify 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:

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 too bad—now 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. Thanks for reading!

This post has been updated with contributions from Kingsley Ubah. Kingsley is passionate about creating content that educates and inspires readers. Hobbies include reading, football, and cycling.