We were approached by the Committee in January to plan a new and modern replacement to the old website.  After meeting with the Committee we were able to develop a new website that promoted the Needs of the Charity.  Our main aim was to build a site that was really simple for the volunteers to work with so that they can upload their latest news and images onto the site.

In 1997 the Crossroads Centre was opened, funded by some of the money raised in the Crossroads Shop.  The premises are on Holmfirth Road in Meltham, opposite the Fire station. Free, confidential, advice and information is given by recognised agencies.  Advice is offered by the Citizen’s Advice Bureau, Ridley and Hall Solicitors, Work Link and Support 2 Recovery.  A counselling service is provided by UCHM (United Churches Healing Ministry) and clients are asked to make a contribution to the cost of this service.  Around 25 Crossroads Volunteers work hard to support the project and the running of the shop and centre.

The site was completed at the end of March and we were invited to a ‘Low Key’ Launch party.  We are looking forward to a great working relationship with the team at Meltham Crossroads.

Hi Steve

Thank you very much for our new website – we love it – its attractive and easy to use.

Thank you for joining us at our very ‘low key’ balloon launch this morning.  We look forward to a continuing relationship with you as you host the site.

All best wishes

Jean

Fake drug scam hijacks UK college websites

The BBC recently reported that “UK academic institutions have unwittingly become the accomplices of criminals selling fake drugs online.” The article went on to state that this had happened because spammers had “exploited vulnerabilities” in the PHP scripting language. As a PHP programmer I take exception to this claim, as should website owners and web design agencies, for reasons that I will explain later.

The article reported how academic websites with the .ac.uk domain extension were unwittingly forwarding visitors to websites selling fake drugs online. Without going into much detail it was explained that spammers had injected code into the web pages, seemingly exploiting vulnerabilities in PHP, that would make Google and other search engines believe that the pages were relevant for searches related to prescription drugs such as Viagra. When a user searched for those terms and visited the website via the link on the search engine results page (SERP), the injected code would detect this and redirect them to the online pharmacy. When a user visited the website by typing in the URL directly or via a non drug0related search, the normal page is displayed.

Deliberately Targeted

This is not a random attack; the websites had been specifically targeted. Academic institutions rank very well in search engines because, put simply, they are inherently trusted and as such, the .ac.uk domain extension carries a lot of weight.

An attack like this is also clever because it doesn’t place visible links to spammers’ websites or make any obvious changes to the web page that has been compromised. Visitors only get redirected to the online pharmacies if they are actually searching for specific terms. This way the website administrator may never know that their scripts have been compromised and remove the spammers’ code!

One such website that has been affected is Ravensbourne College of Design and Communication. Amazingly, four days after the BBC reported that their website had been compromised (and presumably even longer since they found out), the injection in still in place! If you visit www.rave.ac.uk you will see the college’s official website. If you search for the college and follow the link in the SERP you will also see the college’s official website. However, if you search for Viagra and follow the link in the SERP you will not end up on the college’s website at all, but at a “Canadian online pharmacy”!

What Cost?

This is all very unfortunate for the college. The negative publicity alone would be bad enough, but they will also have to spend time and money removing the injected code and then plugging the holes that allowed an exploit of this type to happen in the first place.

I mentioned earlier that I would object to the reporting of this a PHP exploit. I believe that this is inaccurate and could lead people to believe that PHP is inherently less secure than other scripting languages. In fact I would not call this a PHP exploit at all – it’s slack coding that could have resulted in the same thing happening no matter what scripting language the website was developed in.

From the scant technical details offered in the original article it would appear that the affected websites do not properly validate and filter user input. Of course a website developed in PHP would be vulnerable to rogue code injection attacks if user input is not validated correctly. But for that matter so would any other scripting language!

Aside from my personal objections to the labelling of this incident as a vulnerability within PHP, website owners and web design agencies should also consider the effects of the media when reporting stories like this. If a potential client reads the article and takes from it that “PHP is not secure” or “PHP websites get hacked easily” and then you pitch a PHP-based website to them, how will that affect your chances of winning the contract? And to a lesser extent, how do stories like this affect the public’s perception of your current website? Would they feel safe buying from you online when such high-profile PHP websites fall victim to hacking?

Conclusion

But what can we in the IT community do? It’s not realistic to expect journalists to understand that this was poor coding rather than an insecure scripting language. The best that we can do is be aware of what stories are floating around in the news and be sure that we understand and can explain the real issues!

Comparing your site to others in your industry

Although nobody wants their website to be a carbon copy of a competitor’s, it is important to check your competitors to make sure you’re offering at least as much information on your site as they offer on theirs.

Things customers might expect from your site, especially if your competitors provide it:

• Do you clearly display opening hours (if applicable) and contact details?
• Do you offer an e-mail address or a contact form?
• Do you show prices, a menu, services or a stock list if applicable?
• Do you show what payment options you accept, either on your site or in your store?
• Do you provide directions or a map?

What your potential customers might be saying about you

Social media – forums, blogs and networking sites – can also have a significant effect on your business. In the case of this particular shop, the majority of their online advertising has been done by word of mouth and user recommendations – and this has been a factor in their growth as a business.

But the negative reviews of the company’s newly launched website on a well-used forum with high natural rankings may have a long term effect – particularly when comparisons have been made and links provided to other industry standard websites that do contain the information that the site users want to see.

What could this company do?

A competitor analysis would provide an overview of other sites in the industry, either UK-wide or targeted to their region. This could provide an insight into the expectations of users based on their experience of other companies’ websites.

Performing a WebScan on their site would help ensure that the site is optimised, search-engine friendly and compliant with W3C standards.

And lastly, social media monitoring would highlight issues like the discussion of the current website, so that appropriate action – whether that be revising the website to meet expectations or responding to the discussion to explain the reasoning behind the current site’s design – can be taken.

PHP’s MySQL Extension

PHP’s mysql extension is the original extension that was designed to allow you to develop PHP applications that interact with your MySQL database. The mysql extension was introduced prior to PHP version 3 and provides a procedural interface only. This extension is intended for use only with MySQL versions older than 4.1.3. It can be used with newer versions of MySQL, but not all of the latest MySQL server features will be available.

PHP’s mysqli Extension

PHP also offers a more recent mysqli extension, sometimes known as the MySQL improved extension. The mysqli extension is included with PHP versions 5 and later and was developed to take advantage of new features found in MySQL versions 4.1.3 and newer. mysqli provides both an object-oriented and a procedural interface.

Why to Use the mysqli Extension

The PHP development team strongly recommends that if you are using MySQL versions 4.1.3 or later you should use the mysqli extension rather than the original mysql extension. The key reasons for using mysqli over mysql are:

• Object-oriented interface
• Support for Prepared Statements
• Support for Stored Procedures
• Support for Multiple Statements
• Support for Transactions
• Enhanced debugging capabilities
• Embedded server support

Additionally the mysql extension is no longer being actively developed by the MySQL development team, whilst the mysqli extension under active development. It also supports multiple statements and character sets, whereas the mysql extension does not.

But…

Although the PHP development team strongly recommend that you use the mysqli extension if you’re using MySQL versions 4.1.3 or later, there is a debate about speeds differences between the two extensions. There is evidence (example) to suggest that although under certain circumstances mysqli is faster, for everyday use mysql actually performs better in terms of speed than its more modern counterpart!

However, the tiny speed advantage to using mysql rather than mysqli is probably outweighed by the newer extension’s benefits.

Conclusion

Although it might be true that mysql is ever so slightly faster than mysqli, it’s still worth following the PHP development team’s advice and using the newer extension. mysqli gives you access to the features available in MySQL versions 4.1.3 or later and it’s more flexible than the mysql extension. In addition to that, as the mysql extension is no longer under active development by the MySQL team there is no guarantee that it will be included in future PHP releases.

Hold on just one moment… how much does your client know about CSS – and how long is the site content going to retain the look and feel they’re so pleased with if they’re not confident with HTML?

Clients aren’t coders.

Most of them, anyway – most clients know how to use Microsoft Word, but that might well be the extent of their design knowledge. And, if you’ve worked with Content Management Systems, you know that copying text from a Microsoft Word document into the CMS can cause some unexpected design complications, and can result in accessibility issues, including loss of W3C compliance. Inserting plain text into the editor helps, but what happens to the formatting?

Using inline formatting is certainly an option, and many clients will opt for this. It’s quite easy to highlight a segment of text, apply a font size and colour, then set the text alignment. This has the advantage of being truly WYSIWYG, as all changes will show up exactly as the user wants them to in the CMS editor window. There’s just one small problem.

If your client doesn’t know exactly what font sizes, colours and alignments are used in the content you set up for them – not to mention image spacing, table cell padding and other more advanced settings – it will be very difficult for them to replicate this when they upload their own content. An area of text that looks just about right in the content editor might not look like the rest of the page content when it’s saved and viewed on the front end.

But they can apply CSS styles and classes, right?

Of course, you could supply them with a list of the correct inline style codes or even classes to add for each formatted segment of text… it adds another page or two in the user manual, but it would ensure that they could produce new pages that look like the content you uploaded for them.  Some clients are quite happy to click on that little HTML button and enter an instruction like class=”blah” in the correct part of the page for the content they’re uploading.

But many content managers don’t have any web design experience – they’re working with the content editor on the basis of a “Microsoft Word-like” interface. Looking at the HTML version of a page can be daunting. Those <p> and </tr> and <a class=”sausage” style=”margin: 5px; float: left; clear: both;” href=”/overthere.htm”> tags don’t make sense to anyone who doesn’t know that they’re looking at the start of a paragraph, the close of a table row or a styled link to a page.  In that respect, it may not be reasonable to expect your clients to be able to add classes or inline styling.

What’s the solution?

I use a combination of two approaches.

First,  in every CMS user guide that WSI Huddersfield produces, we include any applicable inline styling, particularly where <div> sections have been used to create columns or floating text areas, as standard CMS software doesn’t include an insert-DIV option. This is done by providing a block of code in the user manual with “your text goes here” sections in it.

Secondly, in the site creation process, we use CSS to define the appearance of a number of basic functions on the site, like paragraphs, headings and lists. Once this is done the customer can then use your styles with just a click or two to format their text and retain the same look and feel as the content you have uploaded.

For example, you may need a specific format for a Call-to-Action button. Trying to show a client how to do the Call-to-Action buttons with standard text and inline scripting could be quite problematic, even if you explain to your client exactly where to paste the appropriate styling text. But if you have set up the CSS so that using the Heading 5 option in the CMS will automatically make the text appear as a button with a fixed width, floated right and showing a background image and border, it simplifies things considerably.  A client could then enter their normal text, highlight it, and click “Heading 5″ in the settings.

Style test pages

There is one down side to using the CSS styling in this way – the CMS is no longer quite so WYSIWYG if you’re using external style sheets, which do not show in the editor window. That formatted H5 wouldn’t have the styling applied to it, so it would simply appear as plain bold text in the CMS. This is why creating a Style Test page is important, so that a client can refer to what something looks like on the front end of the site, and click the right option in the CMS. This test page should show:

• Headings 1 –  6
• Standard paragraph text
• Links
• Bullet and numbered lists
• Any other formats applied to standard functions

This way, your client can see what they need to do to replicate the style of pages already on the site. And helping your client to do that will also help you – so that the site you are so pleased about will remain a showcase piece once your clients are maintaining their content themselves.

SEO Unfriendly Pages

If you’ve got a CMS or some other sort of database of pages the easiest way to link to them will be something like www.example.com/index.php?pageID=1. After a while you might have started to think about search engine optimisation and concluded that www.example.com/page-1.htm would be a better URL format. You can rewrite the 1 in the URL onto index.php?pageID=1 very easily and achieve a website with static looking URLs in a short time.

Update Your Links

However, there will (hopefully) be lots of links out there on the web pointing at your old-style URLs. You don’t want to serve your page from both URLs, as this would lead to duplicate content and is something that should be avoided for SEO reasons. The best thing to do in this situation is to programme your script so that it will detect visitors coming from the old-style URLs and redirect them seamlessly to the correct new URL.

It would also be a good idea to contact other webmasters that are hosting links to your old-style URLs and ask them to update them with the new URLs.

Set Up Your Redirects

There are two ways that you could handle redirecting visitors from the old-style URLs to the new ones.

If you have simple static URLs that include the page ID in the file name (e.g. www.example.com/page-1.htm) then you can add a couple of lines to your .htaccess file and all of your old URLs will be redirected to the correct new URLs.

If you have a more advanced CMS or custom setup that allows you to specify page URLs then you will need to programme your script to detect visitors from old-style URLs, lookup the corresponding new URL and perform a redirect.

.htaccess Redirects

Redirecting /index.php?page=1 to /page-1.htm can be accomplished easily using Apache’s mod_rewrite functionality within your .htaccess file in the root of your website.

RewriteEngine On
RewriteCond %{QUERY_STRING} ^pageID=([0-9]+)$
RewriteRule index.php http://www.example.com/page-%1.htm? [R=301,L]

That code will redirect any old-style URL containing the pageID as a variable to the correct new URL.

Programmatical Redirects

If your new URLs won’t be as simple as /page-1.htm you probably won’t be able to simply set up an .htaccess rewrite rule. Instead you’ll need to take the pageID from the old-style URL and lookup the correct new URL from your database. Once you have the new URL you can forward the visitor with a 301 HTTP status code, which should keep both visitors and search engines happy. Given a little time, search engines should update their indexes to reflect the new URLs, too.

This code, based on the examples that we have been using, should give you an idea of how to set up your redirects:

<?php
$matches = array();
// Check whether the visitor is coming from an old-style URL with a pageID
// variable appended. Save the pageID so that we can use it to query the database.
if(preg_match('/index\\.php\\?pageID=([0-9]+)$/', $_SERVER['REQUEST_URI'], $matches))
{
  // You should have a database connection open at this stage
  $result = @mysql_query("SELECT `url` FROM `pages` WHERE `pageID` = {$matches['1']} LIMIT 1");
  if($row = @mysql_fetch_assoc($result))
  {
    // We found the page, so redirect to it
    header("HTTP/1.1 301 Moved Permanently");
    header("Location: http://www.example.com/{$row['url']}");
  }
  else
  {
    // No matching page was found
    header("HTTP/1.1 404 Not Found");
    header("Status: 404 Not Found");
    // You could include a custom 404 error page here
    die('404 Page Not Found');
  }
}
else
{
  // Grab the page content from your database
}
?>
Your page content starts here!

Once you have modified it to suit your individual setup, placing that code at the top of your script will detect visitors on the old-style URLs and redirect them seamlessly to the correct new URL. Remember that you’ll need your new URLs rewritten onto the script using Apache’s mod_rewrite and .htaccess in order to fetch the content.

Conclusion

It’s worth moving from dynamic URLs to static URLs. Using the techniques outlined above you should not be affected by duplicate content and visitors landing on old URLs should be forwarded to your new URLs without having to take any further action.

1-    If it is an e-commerce website, make sure it looks like one, display credit card signs, show a basket

2-    Display your main offers and products on the home page, don’t clutter the home page with your life story or mission statement.

3-    Don’t waste valuable space and prime search engine optimisation with “Welcome to Our Site”

4-    Always have a phone number clearly displayed so that people can contact you, don’t hide it on the contact page or in teh footer

5-    Ensure that prices and offers and taxes are clear

6-    Do not require registration to checkout, this is a big turn off

7-    Make Delivery Policy and Charges Transparent

8-    Use Goody Badges e.g. trade associations and secure signs to add comfort to the customer

9-    Do not clutter checkout pages, keep them clear of distractions, too many choices can cause confusion or inertia

10-  Make terms and conditions clear, you have to offer a 7 day money back guarantee by law (some exceptions)

11-   Make sure that it is Search Engine Friendly, teh website can be beautiful, but if you’re never found, your investment is wasted

12-   Make sure that you have web analytics installed so that you can measure what is happening on site and so that you can measure and improve your marketing campaigns

Of course this is not a full checklist, but it is amazing how often websites miss the obvious and focus on themselves or their history.

It is vital to put yourself in the mind of the customer, make it easy ofr them, minimise clicks to buy, engender trust with openness and no surprises and carefully and thoughtfully signpost the site with good navigation. Most of all keep it brief. No one reads long sentences and paragraphs, until after they have made a buying decision or are actively looking for more information.

Checkout Some Of Our White Paper Resources

Downloads Available from our White Paper Resources Page

The New Ways To Be Found Online

Landing Pages

Conversion Architecture

Email Marketing

Web Analytics

Your Guide To Paid Search

Social Media

Trends Report 09

Trends Report 09 – E-Commerce

Trends Report 09 – Internet Usage

Trends Report 09 – Social Media

Make Sure Your Company is Visible on Google with SEO

We are a Digital Marketing Agency and Internet Consultancy based in Huddersfield West Yorkshire. We pride ourselves in delivering , top performing e-commerce websites to our customer base around Huddersfield, Leeds and West Yorkshire. Our websites will always be built Search Engine Friendly.

The real reason it can be difficult to stomach replacing an existing site is psychological – people are hard-wired to do one thing that will cost them money instead of making it for them, even when it comes to websites.

The Sunk Cost Fallacy

Websites can be expensive, especially when you consider all of the modern bells and whistles that can be added – ecommerce, social media marketing widgets, video and so on. A fully featured website is a significant investment for any business. The key to this investment, however, is the return on investment that your website can provide. It’s there to bring you customers and attract them back for return business.

But when the investment on that website has been made, it is very difficult to take a step back a few years on and say “This was working for us in the beginning, but business coming from the website has steadily tapered off. This site just isn’t getting the job done any more – it’s time to replace it.” As people, we are very reluctant to replace something we’ve invested a great deal of time, money and effort into – even if keeping it or adding to it is going to cost us even more.

This is what’s known as the “sunk cost fallacy” – the idea that somehow plugging more money into something that isn’t doing the job and isn’t what you want is better than accepting that the original investment’s useful life has ended and starting with something new.

My Toaster’s Broken….

Of course, this idea isn’t doing you any favours – if your toaster was no longer working, and it would cost £20 to fix it or £15 to buy a new one with the same features … surely you’d buy the new toaster, right?

What if you had a broken toaster, and it would cost £20 to fix it, or £30 to buy a new one – it’s more expensive, but it has features you’d like to have and it comes with a one-year manufacturer’s warranty? Would you have your older toaster repaired then, or would you get the one that does what you really want?

If you’d spend less money but get significantly less for it, you’re falling prey to the sunk cost fallacy… and people do the same thing with websites. Older site architecture can be more difficult to bolt new features onto, and a fix that sounds cheaper on the surface than replacing the site as a whole can become a much more expensive exercise when adding new features causes problems with older ones.

Your Aging Website

Take a step back if you have an older website – is it still doing the job you need it to do?

If it doesn’t … does it make more economic sense to update it – or replace it?

There are likely to be areas of your website that you don’t want others to be able to access, such as admin areas. Or sometimes you might want to do some quick updates to your code without the website being accessible to the public. If you’re using the Apache web server the hypertext access (.htaccess) file lets you add password protection in a flash!

.htaccess

Apache has a built-in way of protecting entire directories (and sub-directories) from unauthorised users. Let’s assume that you are protecting your /admin/ directory.

If you don’t have an .htaccess file in the admin directory you will need to create one. The .htaccess file then needs just 4 lines of code to turn on password protection:

AuthType Basic
AuthName "Admin Area"
AuthUserFile /system/path/to/.htpasswd
Require valid-user

AuthType

The AuthType directive selects that method that is used to authenticate the user. “Basic” is the most common method and is fine for what we are trying to accomplish.

AuthName

The AuthName directive sets the Realm that will be used during authentication. The Realm has two uses. Firstly, the web browser often presents this information to the user as part of the password dialogue box. Secondly, it is used by the web browser to determine which password to send for a given authenticated area. Once a user has authenticated in one Realm, the web browser will automatically retry the same password for any area on the same server that is marked with the same Realm. This means that a user will not be prompted for a password more than once if multiple restricted areas share the same Realm.

AuthUserFile

The AuthUserFile directive sets the path to the password file that stored usernames and encrypted passwords for your users. This is the system absolute path and not the path within your web space.

Require

The Require directive provides the authorisation part of the process by specifying the user that is allowed to access this area. You can specify a single user or “valid-user” to allow anyone in that is listed in the password file, and who correctly enters their password.

Set Up A .htpasswd User List

Once the .htaccess file has been set up, we need to create the .htpasswd file so that Apache knows which users should be granted access to our admin area.

.htpasswd files are text files that list each user and their encrypted password on a new line like so:

admin:PAzNeZcFJV3Vk
bob:oRCu8rlaPEaTs
frank:1VhSkx7Q37ZYQ

(Passwords are encrypted with a one-way algorithm, so you can’t decrypt the password even if you know the encrypted value.)

Apache comes with a utility that will generate your .htpasswd file and add users with encrypted passwords that you specify. However, we will assume that you don’t have shell access, which is needed to use Apache’s htpasswd utility.

An easier way to generate your .htpasswd file is to use one of the many online .htaccess password generators that will pretty much do everything for you.

One such website is Dynamic Drive’s .htaccess password generator, which provides the code needed in both your .htaccess and .htpasswd files.

Turn Password Protection On

Once you have generated your .htaccess and your .htpasswd files you simply upload them to the directory that you wish to protect. Take care not to overwrite an existing .htaccess file, or you will lose the functionality that it added. If an .htaccess file already exists you should simply add your new code to it.

Conclusion

Apache comes with methods of setting up basic authentication in minutes, so you no longer need to worry about unauthorised users accessing parts of your website that you want to keep private!

Apache’s mod_rewrite module is a powerful rule-based rewriting engine that rewrites requested URLs on the fly, server-side. This is an incredibly useful feature and importantly it allows you to set up redirects and SEO friendly URLs in minutes.

Can I Use mod_rewrite?

If you’re using the Apache web server then the chances are that you have the mod_rewrite module available to you, as it’s enabled by default in most distributions.

Getting Started with mod_rewrite

Your rewriting rules will go in an .htaccess file, a hypertext access configuration file. This can be in the root of your website and apply to all lower directories, or you may have .htaccess files within particular directories if the URL rewriting rules will only apply at that location. We’re going to assume that all of your URL rewriting will be done from one .htaccess file in the root of your website.

Turn the Rewriting Engine On!

First we need to tell Apache that it should use the rewriting engine. We do this by adding the following line of text to our .htaccess file above any rewrite rules:

RewriteEngine On

Now we’re ready to start adding some URL rewriting rules with the RewriteRule directive!

URL Rewriting Rules

mod_rewrite accepts Perl compatible regular expressions. The most common mod_rewrite directives that you will use are RewriteRule and RewriteCond.

The RewriteRule directive is the part of the code that does the work in defining what will be rewritten. This directive can be used as many times as you want, with each one defining a single rewrite rule. The syntax for RewriteRule is as follows:

RewriteRule Pattern Substitution

The RewriteCond directive can be used alongside the RewriteRule directive to define a condition under which rewriting will take place. For example, you may have set up a rewrite rule but you only want that rule to be applied under certain circumstances. One or more RewriteCond rule conditions can precede a RewriteRule directive. The syntax for RewriteCond is as follows:

RewriteCond TestString CondPattern

Pattern and CondPattern are Perl compatible regular expressions, with some useful additions. Patterns can be prefixed with a ‘!’ character (exclamation mark) to specify a non-matching pattern. A working knowledge of regular expressions is particularly useful when setting up URL rewriting rules.

RewriteRule

A simple example of RewriteRule used on its own without the need for any extra RewriteCond conditions would be rewriting seemingly static product pages onto a dynamic script. Dynamic URLs such as www.example.com/product.php?id=26 are not recommended for SEO, and a slightly better (static looking) example would be www.example.com/product-26.htm. This is easy to implement with the following rewriting rule:

RewriteRule ^product-([0-9]+)\\.htm$ /product.php?id=$1 [L]

First let’s look at the regular expression pattern for the URLs that we’re matching. The caret symbol (^) means “starts”, so URLs must start with the word “product” and then an apostrophe (“-”).

Using parentheses in Pattern or in one of the CondPatterns creates a back-reference, so that those values can be used in the Substitution and TestString patterns. We want to capture the product ID and pass it to our dynamic script, so the ID part of the URL is enclosed in parentheses.

The use of square brackets indicates a range. In this case we’re looking for an ID number, so the range of numbers 0-9 are used. We expect 1 or more numbers in the ID number so the plus (“+”) symbol directly after the range means “match 1 or more of this range”.

We then want our static URL to finish with “.htm” in order to look like a standard HTML page. The full stop (“.”) character has a special meaning in regular expressions so it has to be escaped with the backslash (“\\”) character so that it is treated as a literal full stop and not its special meaning.

The dollar symbol (“$”) means “ends”.

Taken as a whole our regular expressions means “match a URL that starts with ‘product-’ then has 1 or more numbers 0 to 9 and finally stops after ‘.htm’”.

Now let’s look at the substitution string. This is much simpler than the regular expression pattern. We want to rewrite our static URLs into a dynamic script called product.php in the root of the website.

We created a back-reference referring to the product ID in the regular expression and this is added to the URL with $1, referring to the first back-reference created.

The [L] flag specifies that if matched, stop the rewriting process here and don’t apply any more rewrite rules. This will stop any subsequent rules matching this request and is also better for performance, as no further rules need to be tested by the server before rewriting takes place.

RewriteCond and RewriteRule

A simple and common example of using a rewrite condition with a rewrite rule is redirecting canonical URLs. Typically you’ll want any visitors arriving at http://example.com or http://example.com/whatever/ to be redirected to http://www.example.com or http://www.example.com/whatever/ (adding the “www.” prefix). This avoids any duplicate content issues. This is easy to implement with the following rewrite condition and rewrite rule:

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

This rewrite condition compares the CondPattern to the TestString and if it matches, the RewriteRule that follows will be applied. In this case the TestString is the website host (e.g. example.com or www.example.com etc…), specified by %{HTTP_HOST}. (Lots of other server variables can also be tested against.)

The CondPattern pattern is another regular expression. As mentioned previously, the “!” prefix specifies a non-matching pattern. This is a similar regular expression to our previous example – it starts with “www.example.com” and then ends. Because we’re looking for a non-matching pattern, this means that any HTTP hosts not matching “www.example.com” (e.g. “example.com”) will trigger the rewrite rule.

The RewriteRule pattern here is grabbing anything after the domain part of the URL so that it can be added to the end of the correct version of the URL with the “www.”.

The pattern starts with a caret, as we have seen previously.

The next part is enclosed in parentheses so that a back-reference will be created and added to the correct URL.

The full stop means “any character” and the asterisk (“*”) means “any number of”. Put together those two special characters mean “any number of any character”, which is anything! That will grab any directory / file name specified in the URL after the domain part.

The Substitution is equally as simple as the first example. The new URL will be http://www.example.com/ followed by whatever directory / file was identified by the back-reference.

The L flag specifies that this is the last rule, and R=301 specifies that the redirect code should be 301.

This will set up 301 redirects for any URL that doesn’t contain the “www.” prefix and redirect the visitor to the same page on the correct host.

Putting It All Together

In a real .htaccess file, the examples above would be put together as follows (in .htaccess files lines beginning with the hash character (“#”) are comments and are not parsed):

# Turn on the URL rewrite engine
RewriteEngine On

# Rewrite any non-www requests to the correct www host
RewriteCond %{HTTP_HOST} !^www\\.example\\.com$
RewriteRule ^(.*) http://www.example.com/$1 [L,R=301]

# Rewrite "static" HTML product pages onto the PHP script that processes them
RewriteRule ^product-([0-9]+)\\.htm$ /product.php?id=$1 [L]

Conclusion

Those are two of the simplest but most useful uses for the Apache mod_rewrite module. As it is such a powerful tool, mod_rewrite can do much more complicated and interesting things, but that’s beyond the scope of this basic introduction.