This has been a long time in the making, but I’ve finally decided to move this blog (and a few other things I’m hosting) to DreamHost. Why DreamHost? Because they offer a great package, what can I say? I’ve been hosting at 1and1 for over a year, but after a few bad experiences, I’ve decided to move to something a bit more robust.
Although it’s not really fair to compare DreamHost to 1and1 Hosting, let’s give it a shot:
I use these for my MySQL backups. Download a nice PHP script and set up a cron job to run said script at a scheduled time. Without cron jobs, I have to go through the hoopla of running some PsuedoCron stuff, which basically runs a script if a user visits your website after the script has been scheduled to run. This is fine for small scripts, but didn’t really fly much for my database backups, since the poor sap that happened to trigger the script would have to sit and wait for it’s completion, as it would appear to be something the website was loading.
After working so much with CakePHP, I can’t help but be curious. I really doubt that I’m going to jump ship, but it’s good to have an environment to play with.
You got 500 GB of disk space to play with, and 5.0 TB of monthly bandwidth. This is enough to host at least a few good sized sites under one account. The unlimited Domains makes this a breeze.
No, I’m not moving, not yet anyway. But Lava is. She scored a domain name which describes her blog so perfectly, that she couldn’t help but nab it up: HowISaveMoney.net. Now what are the odds that this domain would still be lying around?
Lava finally made the big step and “moved into her own place”. Moving domains is always such a hassle, but there are a few things that make the process a little bit easier. I was the Administrator during this move and I must say it was a little bit involved, but I think I got it done.
The domain was purchase at 1and1.com. Why not NetSolutions, Yahoo, GoDaddy? Because they all have great promotional deals but then it’s upward of $8 to renew every year. 1and1 has a nice flat rate of $5.99 every year.
The host remained the same, since this particular hosts allows up to 10 domains pointing to it. All the files are simply dumped in a different sub folder. I both love and hate the idea of one consolidated host. It’s easier to manage: one login one set of administration and maintenance, cheaper than several different hosts. But if one sight goes down, they all go down. If a hacker gets into one, he damn well gets into all of them. The load on all of the sites is still very small and way under the allotted bandwidth limit. Most of them are blogs using WordPress and we all know what a small physical footprint WordPress leaves behind. If any one site seems to out grow things little family what it turns 18 or something, it will definitely be kicked out of the nest onto it’s on hosting package.
Now this should be the simple part. You copy everything into the folder that is going to house your new blog. There are a few minor changes that you might need to make. Depending on your previous setup you may need to edit the .htaccess file and change the RewriteBase option. But I do think that WordPress will configure it for you when you set up your permalink stuff.
One change that is necessary is editing your wp_config.php file. If you’re changing databases, you need to make the changes here. If you’re not changing databases you still need to make the changes to the table prefix. I forgot to mention that we still need to keep the old database active (details to come later).
phpMyAdmin is a beautiful tool. It let’s you administer a MySQL Database without all the messy commands. Also, some host don’t even allow you access to those messy commands. So, once again, it’s a beautiful tool. You can pull up a window and run individual SQL commands on the database or you can run an entire SQL script. It’s really great. There is a wonderful export tool that allows you to back up your Database as plain text SQL file or a file in GZip format. I have seen exported files get up to 10 MB compressed, which is over 100 MB decompressed, given that it’s just a plain text file.
But one thing that is lacking is a proper import procedure. Currently, you can import a database by pasting the SQL statements in a form and clicking submit, or by uploading an SQL file through your browser. Now that’s all well and good, but there are some problems with this method. The main problem is with timeouts. Of these there are two kinds, there are browser timeouts and server timeouts. The second problem is file size. Another limit, which you don’t often read about, is the phpMyAdmin configuration limit.
Browsers have a limited time that they can be busy waiting for response from the server and when doing a database import this is exactly what is happening. Your browser does a little work of uploading the file. After that it’s up to the server. So while your browser says it’s busy it really isn’t. It’s just waiting for the PHP script (phpMyAdmin) to get back to it and say it’s done. With large databases, this can take a time.
There are a couple ways to get around this. In Firefox you can go to about:config and look for the setting that deals with the browser timeouts. Honestly, I even forget what the exact property is. If you use Internet Explorer (well maybe you need to be punished) you’re out of luck, because as far as I know (which is not much about IE) I think you need to go into registry to do this. If you’re browser times out, it simply stops and kills the connection. With no active connection there script on the server comes to a halt.
Now let’s say you’ve gotten over the problem of the browser timeout. Good for you. Now you’re hit with something you may not have control over. A lot of shared hosts don’t allow you to modify their PHP configuration settings, for good reason. And a lot of servers have very fixed limits on the length of time that a script can run for. If this is less than what you’re file needs to run, then you’re once again out of luck. There is no work around for this though, sorry.
File Size Limit
Servers have a fixed limit with respect of the size of file that can be uploaded through the browser. Back in the day, it was stuck at 2 MB. Right now, I’ve seen them maxing out at about 8 MB on average. So what do you do if your export file is 10.5 MB? You’re out of luck, that’s what. Now why don’t they modify their export utility to break files up into multiple sizes that can be handled through import? well, it’s too much work. It’s not their problem, get a better server I guess. Once again, you’re out of luck.
phpMyAdmin has a limit in their configuration file that limits the actual number of SQL commands that can be executed. It’s that simply. If your database goes beyond this, then once again, you’re out of luck.
Well not really. You could install your own version of phpMyAdmin on the server and configure it as you like. If this works for you, great. But if your problem is also one of those mentioned above, then again, you’re out of luck.