Change Your Domain Name and Keep Your Incoming Links With .htaccess And mod_rewrite

When moving our site from to, this handy little bit helped move our entire website with four lines of code:

Options +FollowSymLinks
RewriteEngine on
RewriteCond %{HTTP_HOST} ^(.*) [NC]
RewriteRule ^(.*)$$1 [R=301,L]

This reference was extremely helpful.

This RewriteRule lives in the .htaccess file at and tells any request coming in to that domain to swap out and replace it with This includes ANYTHING after the trailing slash, like a direct link to a previous post. So gets sent properly to

The important part is the [R=301] which sends a 301 (Permanent) Redirect header. That tells search engines that the page has moved permanently.

Just imagine what you’d have to go through setting up individual forwarding links…

We’ve Moved!

Well, virtually, that is. If you’ve found yourself here after going to, fear not – you’re in the right place. It was time to bring some focus – to who this is and why I’m doing this – and start adding some meaningful posts. The important ones have been migrated over to the new site, while others weren’t quite relevant enough to carry on. More helpful info on the way…

Nettica ‘safeguard.php’ Hoax

This morning I received an email hoax purporting to be from Nettica, our DNS provider. Details aren’t clear yet on what it’s intent was (the attached file was encrypted, which we’re working on decrypting), but I’ll post an update as soon as we figure it out. We’re working with Nettica Support to find out what’s going on.

The email instructions appear to be referencing a Plesk installation.

Here’s a copy of the email that was sent in case anyone else receives it:

Dear Nettica Inc. valued MembersRegarding our new security regulations, as a part of our yearly maintenance we have provided a security guard script in the attachment.So, to secure your websites, please use the attached file and (for UNIX/Linux Based servers) upload the file “safeguard.php” in: “./public_html” or (for Windows Based servers) in: “./wwwroot” in your site.If you do not know how to use it, you can use the following instruction:For Unix/Linux or Windows based websites that use PHP/CGI/PERL/ASP:
1) Download the attachment named “safeguard.php”
2) Login to your site Control panel.
3) Open “File Manager” window.
4) Go through “Public_html” or “htdocs” (for UNIX/Linux Based servers), but for Windows Based server, please Go through “wwwroot” directory.
5) Choose “Upload Files”
6) Upload the file “safeguard.php”
7) Check its URL too “”, if it is okThank you for using our services and products. We look forward to providing you with a unique and high quality service.

Best Regards

Nettica Inc.

[UPDATE] Nettica has added a post about this on their blog as well.

Creating a MySQL Dump File From an External Database

I needed to export a MySQL database that was on a different server than the web server and was bound and determined to do it without going through the hassle of installing phpMyAdmin (port 3306 was blocked as well, so I couldn’t use any GUI tools either). The trick was adding the -h option. Here’s the command line that made some magic:

mysqldump -u username -p -h --compatible=mysql40 dbname > filetosave.sql

The --compatible command was added because the database server was running MySQL 4.1 and we needed the export for MySQL 4.0.

PHP mail() And Gmail – A Warning on Headers

Today, out of nowhere, we started receiving reports that HTML email the site was sending were showing up as just that: HTML code and not much else. Running a few tests confirmed these reports… but only in my gmail account. We went back and checked the reports and sure enough – they were all coming from gmail users.

After some tinkering and futzing around we realized that the Windows line breaks that we had after the headers (rn) were the problem. Here’s an example:

This will show up as two line breaks in gmail and trash your HTML formatting:
$headers = "MIME-Version: 1.0rn";

This, however, will fix the problem and show up in gmail just fine:
$headers = "MIME-Version: 1.0n";

I’m sure if you were sending mail from a Windows server this may not be the case, but for those on a Unix box, just stick with n. Google will thank you by displaying your HTML email the way it was meant to be displayed – without raw code!

Enable mod_rewrite on OS X 10.4 (Tiger)

Tiger has introduced a new super-confusion level to the stock configuration of Apache. In addition to the httpd.conf file in the /etc/httpd directory, there’s now a new users directory as well. That directory holds unique config files for each user of the machine. So, if you were to enable mod_rewrite or AllowOverrides in httpd.conf, you may find that it doesn’t quite cut the mustard in your personal Sites directory. Let’s take a look:

To enable mod_rewrite:

  1. Open /etc/httpd/httpd.conf
    (I highly recommend TextMate – from the command line you can simply type this:
    $ mate /etc/httpd/httpd.conf
    or use the old standards: vi, vim, whathaveyou)
  2. Go to line 223 (if your config file just so happens to jive with mine) and uncomment the following line:
    LoadModule rewrite_module libexec/httpd/
    (mind the wrap)
  3. Go to line 267 and uncomment the following line:
    AddModule mod_rewrite.c
  4. Scroll down to line 408 and change the line to read:
    AllowOverride All
    (Some server admins will tell you this may not be the best idea for hosting a live site, but I’m assuming you’re using this for local development only, right?)
  5. Uncomment line 454:
    AccessFileName .htaccess
  6. Restart Apache:
    $ sudo apachectl restart

At this point you should have mod_rewrite happily fixing your ugly URL’s in the /Library/WebServer/Documents directory, but it’s not working in your /Users/you/Sites directory. What gives? Here’s the trick:

  1. Open the yourname.conf file in the /etc/httpd/users folder.
  2. Change the first two lines to this:
    Options All
    AllowOverride All
  3. Give Apache another bounce:
    $ sudo apachectl restart

You should now be seeing friendly url’s in your very own Sites directory.