Much has been written already by many people using both examples and tutorials of the basics. The aim of my addition, as always is primarily for my own notes and secondarily to explain why you want to use mod_rewrite for SEO ranking retention.

Let’s say you have a website that enjoys well ranked pages and a lot of traffic via google or has a great deal of Backlinks from other blogs or websites to particular pages in your site. One of the powerful aspects of Google Webmaster Tools is that it easily provides you a way to be able to view which URL’s are linking particular pages on your own website. When contemplating moving a website or rearranging the structure of an existing website, one of your first considerations should be to maintain the availability of accessing your new pages via your old links. Essentially we map your current (old) structure to your new (proposed) structure.

Here’s our first sample. The old url was http://www.domain.com.au/mstore/2wsub1 and our new URL includes keyword rich content: http://www.domain.com.au/htc-hero-android-brown. We use the following mapping:

     RewriteRule ^mstore/2wsub1(.*)$ http://www.domain.com.au/htc-hero-android-brown   [R=301,NC,L]

The above means: Any content being requested at /mstore/2wsub1 or /mstore/2wsub1.html or /mstore/2wsub1.asp etc. will be redirected to http://www.domain.com.au/htc-hero-android-brown. The redirect additionally offers the following further information about the redirect.[R=301,NC,L] tells the requester that it is a permanent redirect (R=301 – Permanent Redirect) and that the requested URL match is case-insensitive (NC – no-case) and that if it finds a match, then redirect and do not attempt any further matches [L - Last match]

After migrating a website, I advise to monitor both Google Webmaster Tools and also your server site statistics / logs for 404 Errors, so you can correct any URL’s you hadn’t originally mapped.

Migrating domain names & ensuring a single accessible URL

In this scenario, we are moving http://www.olddomain.com.au/ to http://www.coolnewdomain.com.au/ because your audience are Mac users and like anything with the title “cool” in it ;). As an aside, we want to ensure that people are always directed to http://www.coolnewdomain.com.au if they type in http://coolnewdomain.com.au and search engines only index the www version so that you do not have duplicate content listed.

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

The above means: If you have NOT accessed the website using http://www.coolnewdomain.org.au then redirect you to http://www.coolnewdomain.org.au . The $1 value is the ‘first variable’. What it means is that if you access: http://olddomain.com.au/cool-product will be redirected to http://www.coolnewdomain.com.au/cool-new-product. Everything after the domain name is used as a variable to attach to the end of the new domain name. Even if you have not migrated domain names it is still wise to use this code on your existing site so that search engines only search one ‘form’ of your domain name. One last thing to note here, is that we don’t use the [L] flag, allowing mod_rewrite to continue looking for matches, as there’s still a chance it could find a match for url’s like our first example.

Using mod_rewrite for blocking access to a website as an alternative to Basic Authentication

Real life usage scenario. Some developers I know created a development website similar to http://dev.coolnewsite.com.au/ that was accessible publicly without authentication. They assumed as they hadn’t advertised it, nobody knew about it but just prior to going live, google ‘found’ the site and indexed it. When the real site went live, anytime they were searching in google for the site or for products, the http://dev.coolnewsite.com.au/ was being displayed. They wanted to block access to the dev site but they didn’t want to lose the fact that they already had some visitors and page rank on the dev site. I tried to use a mod_rewrite rule as above before the Authentication rule but the auth rule takes effect before the rewrite rule,so visitors were being asked to authenticate and not being redirected, additionally this wouldn’t have told google about the new, actual live site. So here’s what I did:

 RewriteCond %{REMOTE_ADDR} !^213\.206\.175\.212$
 RewriteCond %{REMOTE_ADDR} !^124\.231\.17\.180$
 RewriteCond %{REMOTE_ADDR} !^123\.168\.239\.32$
 RewriteRule ^(.*)$ http://www.coolnewdomain.com.au/$1 [R=301,L]

ps: fictitous IP addresses provided ;)
The above means: If your IP address is NOT 213.206.175.212 (dev A) or 124.231.17.180 (dev B) or 123.168.239.32 (Customer) then redirect the visitor to http://www.coolnewdomain.com.au/ with a permanent redirect [R=301] and make it the last matching rule [L].

This means search engines will know about the real, live site next time they come to visit, anyone searching for the site finding the dev site will be redirected to the equivalent URL on the live site but the developers and customer can still access the dev site from the three different locations. The obvious downside to the above code is that if you are not using a static IP address, you will need to update the addresses each time your IP changes. We will add authentication as our live site begins to take rankings above the dev site.

Technorati Tags: mod_rewrite, apache, lamp, web development

So, you have used Website Optimization Analyzer or you installed Yslow for Firefox or you discovered somewhere else that compressing your files (html, javascript & css) is a good thing to do. Unfortunately, it’s not always as easy as it looks to do this.

In Apache web hosting environments, there is a module called mod_deflate (for 2.x versions) or mod_gzip (for 1.3) versions. This is generally the easiest way to get content compressed. As in my last post about Magento, you should normally be able to enable this safely with the following lines inside your .htaccess file in your www root of your website:

<ifmodule mod_deflate.c>
# Insert filter
SetOutputFilter DEFLATE
# Netscape 4.x has some problems...
BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Don't compress images
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
</ifmodule>

Then visit your website and in your browser right-click on the web page and choose “View Source”. In the source code, try and find a line that contains your stylesheet, then we go to whatsmyip compression checker and we enter the whole URL to your stylesheet there. To test, enter my css url.

http://www.opensourcetutor.com/wp-content/themes/hemingwayEx/style.css

You should see a big green tick and the site will say the CSS is compressed. Now, if you don’t, you either haven’t applied my above .htaccess settings yet or mod_deflate is not enabled on your server for you to access.

Alternative #1 – requires Apache mod_rewrite

This method is probably the best method I have seen to overcome the mod_deflate issue and we are only concerned about javascript and css files for now. PHP has an easy method to compress php files on the fly. What we need to do is gzip all our javascript & css files.

If you have shell access, you can run this command to take of the job for you. It will find each and every javascript file and css file and create a gzip copy.

find . -regex ".*\(css\|js\)$" -exec bash -c 'echo Compressing "{}" && gzip -c --best "{}" > "{}.gz"' \;

The line above searches the current directory and any subdirectories for files with extensions .js or .css, then prints out that it is being compressed, then compresses with the highest compression in that directory leaving the original file as is.

Now, we need to tell our browser to access the gzip version *IF* it supports gzip encoding. To do this, we use the following in our .htaccess file. Make sure you have removed the above code if it wasn’t successful.

<files *.js.gz>
  AddType "text/javascript" .gz
  AddEncoding gzip .gz
</files>
<files *.css.gz>
  AddType "text/css" .gz
  AddEncoding gzip .gz
</files>
RewriteEngine on
#Check to see if browser can accept gzip files.
ReWriteCond %{HTTP:accept-encoding} gzip
RewriteCond %{HTTP_USER_AGENT} !Safari
#make sure there's no trailing .gz on the url
ReWriteCond %{REQUEST_FILENAME} !^.+\.gz$
#check to see if a .gz version of the file exists.
RewriteCond %{REQUEST_FILENAME}.gz -f
#All conditions met so add .gz to URL filename (invisibly)
RewriteRule ^(.+) $1.gz [QSA,L] 

The advantage of this Alternative is that our server doesn’t have to gzip / compress the javascript and css each time it is called. This eases the load up on the server as we already do the compression one time and then just call the compressed version from then after. The other advantage is that we don’t need to load up mod_deflate each time. This could be advantages if you are running a VPS with very low memory available.

If you have a static website, you could apply the same technique for all your html files. To do so, you would instead use this line:

find . -regex ".*\(html\|css\|js\)$" -exec bash -c 'echo Compressing "{}" && gzip -c --best "{}" > "{}.gz"' \;

and then add this into your .htaccess also

<files *.html.gz>
  AddType "text/html" .gz
  AddEncoding gzip .gz
</files>

Technorati Tags: apache, gzip, mod_deflate, compression, yslow, firefox, optimization

1. Your URL you type into a browser, translates to an IP address – this check should take a very, very short time
2. Your browser then begins to access the web server where your website is hosted to ask for the page you want, this can cause some delay, typically 40-200ms (bottleneck 1.)
3. In the case of Magento,it uses PHP as the software language that runs the site, so the php begins to execute (bottleneck 2.)
4. PHP then reaches a part of it’s code it needs to access the database to retrieve website data and sometimes insert information about who you are. (bottleneck 3.)
5. The PHP code retrieves the information, does a bit more computing on it (for simplicity, this is still bottleneck 2) and then sends it to your web server
6. Your webserver can then send it or compress it and then send it to you (bottlneck 4)
7. The data is sent over the internet to your browser (bottlneck 5)
8. Your browser must ‘render’ the data it receives into an actual web page (bottleneck 6)

I will assume you are here specifically for Magento issues, so let’s get started with the basics. I will make the assumption that your web server is running Apache and you have very little control over that.

Preparation – the “before”

1. If you are familiar with the, use Firefox and the Firebug extension and the Yslow extension. Take a screenshot of your statistics.
2. Alternatively, what I suggest is to go to WebsiteOptimization if you’re fairly new to this. You basically enter your URL and click. Print out the page, preferably to PDF before we begin.

Check Magento Caching is turned on (if not developing still)

1. Login to your Magento Admin
2. go to System -> Cache Management
3. in the dropdown box, choose “enable” and tick all the boxes, then save settings.

Let’s start simple – .htaccess and gzip/deflate

1. Go to mod_gzip tester and enter your magento site address. If it comes back with a big green tick and says http://yourmagentosite.com is gzipped, then you’re in business and skip step 2. If not..go to step 2
2. Using ftp or ssh, however you access your magento website, go to the root of the site and find your .htaccess file. Scroll down until you see something like:

<ifmodule mod_deflate.c>
# Insert filter
SetOutputFilter DEFLATE
# Netscape 4.x has some problems...
#BrowserMatch ^Mozilla/4 gzip-only-text/html
# Netscape 4.06-4.08 have some more problems
BrowserMatch ^Mozilla/4\.0[678] no-gzip
# MSIE masquerades as Netscape, but it is fine
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
# Don't compress images
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
# Make sure proxies don't deliver the wrong content
Header append Vary User-Agent env=!dont-vary
</ifmodule>

3. Make sure it looks like above. A hash in front of the line means it’s commented out. If your .htaccess file does look like this AND mod_gzip tester is still not showing enabled, you need to talk to your web hosting provider. They may not allow overrides or may not have the deflate module installed or enabled. If it doesn’t look like the above, remove the hashes from your lines so that it reflects what is above, then retest with mod_gzip tester
4. Take a screenshot / pdf printout of Yslow / websiteoptimizer results. ;)

Let’s shrink our javascript

1. Magento uses A LOT of LARGE javascript libraries and depending on your template, it’s a good chance that these make up for 50% of your website page size. This should only affect the first page load but it’s often the first impressions that count, so let’s shrink it.
2. For this, we will use the Fooman Speedster Extension from magentoconnect. Click on the “get extension key” and then copy the key to your clipboard.
3. Now go to your magento store admin interface and click on “System -> Magento Connect -> Magento Connect Manager”. Enter your admin user/pass to access magento connect manager.
4. *Warning – once you install the extension until you fix your .htaccess, it may break your website*
5. Paste the extension key to install the extension
6. Now go to your .htaccess and under the line: #RewriteBase /magento/ add this line

   RewriteRule ^(index.php/)?minify/([^/]+)(/.*.(js|css))$ lib/minify/m.php?f=$3&d=$2


7. Save your .htaccess and access your site (it may take a while to load the first time as it minifies and creates it’s cache.
8. **Test your site is working properly**
9. Take a screenshot / pdf printout of Yslow / websiteoptimizer results. ;)

Let’s check our php settings

1. Create a file called phpinfo.php and enter this information into it.
2. Check for the following: memory_limit
3. If it’s less than 128M, try and add an entry into your .htaccess like so:

php_value memory_limit 128M

Finally, MySQL – for experienced users.

1. If you’re a mysql hero, you don’t need me to tell you how but we want to try and get the following settings in your my.cnf

query_cache_type = 1
query_cache_size = 32M
query_cache_limit=2M

2. If you don’t have root access to check /etc/my.cnf (or /etc/mysql/my.cnf) variables, then login to mysql or use phpmyadmin to show variables.

$ mysql -u mysqluser -p magento_database_name
$ mysql> SHOW VARIABLES;

3. If you don’t have control over your mysql configuration, go knocking on your Web Host’s support tickets to get them to modify it to suit you or if you’re in Australia, check us out

**If you want someone to do this all for you, lodge a support ticket at Yourwebhostingsupport with the Subject “Magento Optimisation”

Technorati Tags: magento, optimization, apache, mysql, speed

suhosin[25917]: ALERT – configured POST variable limit exceeded – dropped variable ‘task_com_morfeoshow[]‘ (attacker ‘xxx.xxx.xx.xxx’, file ‘/home/user/public_html/administrator/index.php’)

in your php.ini (or suhosin.ini depending on your setup)

[suhosin]
suhosin.post.max_vars = 2000
suhosin.request.max_vars = 1000

Technorati Tags: suhosin, apache, joomla

First we need to export the certificate from IIS into a pfx file. To do that:
Click Start->Run->type: mmc [enter]
Click ->’Console’ -> ‘Add/Remove Snap-in’.
Click -> ‘Add’ -> ‘certificates’ snap-in and click on ‘Add’.
Select -> ‘Computer Account’ -> click ‘Next’.
Select ‘Local Computer’ and then click ‘OK’.
Click ‘Close’ and then click ‘OK’.

In the menu for ‘Certificates’ and click on the ‘Personal’ folder.

Choose your certificate to export and select ‘All tasks’ -> ‘Export’.
In the wizard, check the box to include the private key, continue until you have a .PFX file.

Move the Certificate to the machine Running Apache:

Now, we are going to use openssl to extract the private key, and the cert file.

# Export the private key from the pfx file
openssl pkcs12 -in iis.pfx -nocerts -out apache.key.pem
# Export the certificate file from the pfx file
openssl pkcs12 -in iis.pfx -clcerts -nokeys -out apache.cert.pem
# ****This removes the passphrase from the private key so Apache won’t
# ****prompt you for your passphase when it starts
openssl rsa -in apache.key.pem -out apache.key

Technorati Tags: apache, ssl, iis, certificate,

, , , , , ]]> http://www.opensourcetutor.com/2007/08/08/convert-iis-ssl-certificate-to-use-in-apache/feed/ 0