Apologies to my fictitious regular visitors, who may have imagined that my WordPress-based site has been offline almost daily for the past month. DreamHost has been a down host, and I've made the switch to (mt) Media Temple. In fairness to DreamHost they haven't been the only hosting company affected by recent power cuts, but the power outages seem to be only the culmination of a string of longer-standing problems resulting in slow server response times or non-availability.
One minute I'd be working on my site—editing a template for example—and he next I'd be unable to save it back to the server, or to check the result for the rest of the evening. I'd noticed and reported intermittent problems (e.g. it would take half a minute for my WordPress admin page to display) since I signed up. But the last 4 weeks have been simply horrendous, and my patience became exhausted by repeating Support suggestions that I and my fellow DreamHost customers be patient. The way I see it, I'm paying for service not patience and if I don't get reasonable service then it's time to move on.
How do I know if my site is down?
Aside from regularly visiting your own site and reviewing visitor statistics, there are a couple of free services that might be of use in monitoring your server.
One of these is FeedBurner's which includes a FeedMedic feed that alerts you when you feed is not available. To be frank, it's a little hard to gauge how useful this is, since there appears to be a number of false-positive alerts. Having said that, the bombardment of warnings I've seen recently was beyond the more typical one or two per day and likely a fair indication that not all was well.
Another option is Montastic Server Status, a free server-checking facility that will alert you by e-mail or web feed when your site is not reachable.
What's involved in switching?
They make it sound so simple:
As you might expect, there's a bit more to it than that. The actual steps will vary depending upon your own configuration, but here's the sequence I followed.
- FTP everything from the DreamHost virtual server directory to the desktop as a backup;
- Export the WordPress and Gallery databases from MySQL via the command line in Terminal (I'm petrified by phpMyAdmin). This is done by establishing an SSH connection (a secure replacement for Telnet) to your server and typing something like the following:
mysqldump --opt -u username -ppassword -h dbhostname.bioneural.net dbname > output.sql- FTP the output to your desktop;
- Open an account with (mt). The sales guy even phoned me in the UK from the States to answer a few questions I had;
- Set up e-mail forwarding (xyx@bioneural.net to xyz@gmail.com) using the (mt) account panel;
- FTP all the files (WordPress, .sql output, etc) from your desktop backup to /var/www/html/ on the (mt) server;
- Create the appropriate database containers in the (mt) account panel (e.g. for WordPress, Gallery);
- Contact (mt) Support and request them to enable SSH on your account (it's disabled by default);
- Import your old database into the new container. Establish a connection to your (mt) server in Terminal using ssh user@your_server followed by your password, and then change to the directory where your files were uploaded:
cd html- Now for the actual import:
mysql -ucustname -pcustpass domain_com_-_db < output.sql- Didn't work? Same here. If you get an SQL syntax error about the character set, it might be because you exported from MySQL 5.x and are trying to import into version 3.x as in current use at (mt). Apparently 3.x does not support character sets, and Support at (mt) were kind enough to strip out the offending lines in my databases and import them for me. Now that's service!
- Edit wp-config.php with the correct MySQL connection settings for your new WordPress database;
- Log in to your domain registrar's site and re-direct your domain from DreamHost to the (mt) DNS servers;
- Edit the database connection settings for Mint (and the GetAMint plugin);
- Close your DreamHost hosting plan;
- E-mail The UnHappy DreamHost Goodbye Team (really) and get a credit card refund (I did, even though I was outside my 97 day money-back guarantee period);
- If you see "Fatal error: Allowed memory size of 16777216 bytes exhausted" when trying to retrieve your recent posts using ecto, see this KB article. Yet again the (mt) team were super-quick in responding—and they even applied the fix for me (although I need to increase the memory limit to 32MB).
- Now try to upload a new post using ecto. It works fine if there are no images...
(mt), images and ecto
My WordPress image uploads go to /wp-content/uploads/yyyy/mm where yyyy is the year and mm the month. In the 2006 folder months 01 to 07 have the owner and group of my (mt) username; these were uploaded by FTP from my DreamHost backup. When I used ecto in an attempt to publish this, my first post of August (08), I got an error:
Server returned an error! Method "metaWeblog.newMediaObject" produced a server error: "could not write file xyz.jpg"
Using Transmit to inspect the properties of /wp-content/uploads/2006/08 I could see that the 08 folder was created with the owner and group "apache". Setting the octal to 777 didn't help and I could not alter the owner:
Could not change the owner of 08. Server said: 'SITE CHOWN' not understood.
The good folk at (mt) responded with an explanation:
Well, this folder was created by your WP, and thus was created as user Apache. This is the case when files are created by PHP scripts. You can use something third party like filethingie to change the ownership of the directories, or you may want to consider going into power mode, where everything is run and created by you the user. Take a look at this list, and let us know if you want to proceed.
Here are some VERY IMPORTANT things to remember about turning on Power Mode:
- PHP will run as CGI which will result in slightly slower execution. This has the same effect as if you had used the .htaccess safe_mode workaround listed in the knowlegebase.
- Permissions. 777 permissions on files or folders is not needed and will not work under Power Mode. To make files executable and writable use 755 permissions instead.
- Modifying php environment values through .htaccess files will no longer work. Alternatively you'll have to edit the file /etc/php.ini to change values like upload_max_filesize and memory_limit.
More details can be found in our Knowledge Base article: http://kb.mediatemple.net/article.php?id=080
I recall that I was running PHP as a CGI with DreamHost. As a workaround I have uploaded the images manually by FTP for this post.
Update 06.08.06: I can confirm that enabling Power Mode means ecto can once again upload images directly. Enabling it took down my site, but increasing the memory allocation by editing /etc/php.ini restored it. Incidentally, Power Mode also seems to be essential to my Gallery installation.
I don't know about you but I'd hardly call this a "smooth transition", spanning several days and involving a certain amount of frustration. But my site is back, the access speed is noticeably better, and the (mt) Support response times and helpfulness are simply unrivaled.
This is possibly off topic, but do you use Ecto to upload to wordpress? If so, can you talk about that sometime? I can't seem to get mine to work...
I do Lisa, but I think you use ecto for Windows right? I seem to remember having a discussion about hacking xmlrpc.php for UTW in which that came up...
I use a Mac but will get in touch and help if I can.
I looked at (mt) after the recent spate of problems at DH—the problem is, when (mt) touts that its upcoming revamped control center is just making the switch from MySQL 3 to MySQL 4, well, I'm not encouraged (I'm a bleeding edge kind of guy).
Of course, the AJAX webmail beats the hell out of Dreamhost's Squirrelmail, and there are other perks, but DH has given me enough reasons to stick with them for the time being.
Keep us informed as to your future experiences with (mt): it'll be good to know when my current billing cycle ends and I can reevaluate my options.
Ben, I was reluctant to move hosts fearing things would break, and also worried about the historic MySQL version. It's been educational to discover how many things on my site work the way they do because of host characteristics. That knowledge is also a little unnerving because it confirms that you cannot simply pack up and set up elsewhere and expect everything to work—even when you upload exactly the same set of files and try importing the exact same database. There's a complex web of inter-dependency at work that binds everything together, for better or worse.
Oh, I agree. A year ago, I made the switch from Fuitadnet to Dreamhost: I hated CPanel, and DH's promise of ludicrously excessive disk space and bandwidth was enough to prompt my change. It was certainly an experience trying to reestablish everything, but for all their faults, DH isn't too bad at making things easy to set up.