I launched a site last week that I’ve been working on for over a year. It is the biggest site I’ve launched as a free-lancer. It has been a tremendously rewarding experience, a great learning tool, and a great experience all the way around. You should check it out here: Word Music

We still have lots of tweaks to make it the best it can be, but it’s up there and it’s live and THAT is a huge relief. I have a great time working with the people at Word Music as well as the great team of free-lancers that I’ve worked with to make this happen.

Friday was a BUSY day launching a site like that. There were a lot of pieces to put in place. For those of you that don’t care anything about the technical details of what I learned from this launch, you will probably want to quit reading now Just check out the site and give Word Music some of your business. They are great folks to work with.

For those of you that are still reading, I assume you are interested in what I learned from this launch. This was a little different from the other launches I’ve made in the past. The easiest type of launch is, by far, the new domain name. They don’t have a site up yet and when we get it running, we get it running. We set the DNS a couple of days earlier than scheduled launch and then when we get the code ready, we upload it to the site, set up configuration for the database and BAM! There’s your site!

Then there are those that have a site already running. If the site is to be on the same server, then I don’t have to worry about DNS at all. When it’s time to launch the site, we just replace the old code with the new code, set up configuration for the new database, if needed, and BAM! There’s your new website!

There are also websites that are replacing an already running website but on a different web server or host computer. These are the tricky ones. If the client doesn’t really care about the exact minute that the site launches and isn’t concerned with the DNS propagation throughout the internet, then this isn’t a big deal. I just wait until the code is ready on the new server and set the DNS. Eventually, the client, as well as the rest of the world will start to see the new site instead of the old. Of course, since the DNS isn’t refreshed at the same rate and time thorughout the internet, they may see the old site one minute, the new site the next and then the old site again the next. This bouncing back and forth could last a couple of days. And if the client is cool with that, then my job has been done. But, there was never a ‘BAM!’

The situation I had with Word Music was that they already had a website on a different server. Their new website is on a new server and they wanted it to ‘go live’ at a specific time for the whole world. They wanted a ‘BAM!’ I respect that decision – it made the launch very exciting. It was almost like an unveiling. When they sent out announcements, they didn’t have to warn people that they might not see it right away.

So, how did we pull it off? Those of you that do this a lot are probably thinking this was a no-brainer. At first, I thought it was a no-brainer too. I had the DNS changed to the new site a couple of days early and then I set the .htaccess file to redirect everything back to the old website. Of course, since the DNS was in the process of being changed, I couldn’t redirect to the domain name, I had to redirect to the old IP address.

This worked really well until I had to start testing. How was I going to test the site while everything is redirecting back to the old site? This is where I had to use more of my brain power. I ended up setting the redirect back to the old site in the index.php file instead of .htaccess. I then created a new php file that would act as the index.php file.

Since I’m using the MVC model, this was a little trickier. The index.php is my front controller. If I ever lose the script name through the code, it will redirect back to the old site. Since we are using mod-rewriting on the site, we did have a few of those problems because the script name was getting lost, but for testing we could just substitute the script name in the address bar of the browser. At least we could get to the site and make sure that all the configuration was working and everything was looking good.

At 2:00 launch-time, I just had to take the redirect out of the index.php and let the traffic flow to the new site. Word Music announced the launch of their site and all is well. It was an exciting time!

A few things you may want to also note, I added a check for the IP address of those that were going to be testing so that even if someone did find my testing script that would allow me to bypass the redirect, they wouldn’t be able to get through.

I thought this might help someone else faced with this same type of launch. It worked really well for us and I wasn’t doing quite so much scrambling as soon as the site came up to make sure that I hadn’t missed anything while who knows how many other people were looking at the site for the first time.

It was a good day. I want more days like that one!

I finally got around to getting my domain names to work with my server.

At first I thought that I should just be able to register my domain name and have it point to my static IP address that I use for my server. But, then I remembered that I we don’t put an IP address for the server, but instead, we put in name servers. Sometimes name servers can be IP addresses, but more often than not, they are domain names themselves.

So, I had to study up a bit on DNS and name servers before I could get it set up correctly. The more I studied the more confused I seemed to get. I really do want to learn more about it, but I will leave the most of it for another day. I figured it out enough to do what I had to do to get it working. That’s all the brain power I had for today

When someone looks for my domain name, that domain name has to be on a name server somewhere. I must tell my registrar where my domain name servers live. Sometimes your domain registrar can and will handle your DNS. This means that your registrar is also your name server. So, basically, your name server is whoever handles your DNS records.

My registrar also handles my DNS records. So, I had to park my domain name at my registrar and then I could go in and manage my own DNS records. Sometimes this costs a little more at your registrar or at your host, but it’s not much more.

I had to add an A record to my DNS to point the domain name to my static IP address.

On my server, I had to add the domain name and static IP address in my /etc/hosts file.

I also had to add the Virtual Hosts information to my apache config files. For my setup, this was a file named 000-default in the /etc/apache2/sites-enabled directory. I added the following:

<virtualhost 123.456.789.012>
ServerName example.com
DocumentRoot /var/www/
<virtualhost>

Once I added this to my 000-default file, I restarted my apache server. That worked!! I can now get to my website using my domain name!

Next I wanted to be able to host more than one website on my server, so I changed the file to this:

NameVirtualHost 123.456.789.012

<virtualhost 123.456.789.012>
ServerName example1.com
DocumentRoot /var/www/website1
</virtualhost>

<virtualhost 123.456.789.012>
ServerName example2.com
DocumentRoot /var/www/website2
</virtualhost>

Again, I restarted my apache server and now I can get to both websites on my server. Oh, by the way, I did change the A record in the DNS for both domain names.

What a rewarding feeling to know that I now have my own websites hosted on my own computer!! And I know a little more about name servers and DNS