Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
March 26, 2022 11:58 pm

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


Twitter profileTwitter profileTwitter profile
Twitter profile


Overview and Setup


If you plan to follow along, you need to install a PHP development environment on your computer, 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 three 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 of 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 file index.php 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 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 backend. 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, 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 number, hyphen 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 ended 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 and within the file, you can use the second, third and subsequent elements in the array (ie. 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 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 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 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. I know this is  not an original concept, and is only meant for demonstration of mod_rewrite. First let's take a look at the database:


TableTableTable
Table


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:


Project folderProject folderProject folder
Project folder




  • .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 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.



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



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


Our apps lookOur apps lookOur apps look
Our apps look


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 that holds all the information we showed above:



Creating the Short URL


Next lets 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, 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!


ResultResultResult
Result


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.



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:



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



Original Link: https://code.tutsplus.com/tutorials/using-htaccess-files-for-pretty-urls--net-6049

Share this article:    Share on Facebook
View Full Article

TutsPlus - Code

Tuts+ is a site aimed at web developers and designers offering tutorials and articles on technologies, skills and techniques to improve how you design and build websites.

More About this Source Visit TutsPlus - Code