When this post appears, it will indicate that dovdox.com is up and running on the new hosting service.
I just upgraded the site to the latest version of WordPress. Normally, this takes about 15 minutes of careful work, involving a download to my desktop, some FTP monkey business, checking of config files, and so forth. This time, after backing everything up, I went ahead and tried WordPress’s “automatic upgrade” procedure. Honestly, I didn’t expect it to work, but with everything backed up I figured it was worth a shot.
Click, click, done.
Who says open source software is hard to use?
After a couple of years using Drupal to manage this site’s content, I’ve joined the crowd and switched to WordPress. If you’ve ever managed a server-side application, you know that this type of move isn’t trivial.
For those who haven’t dealt with this, here’s the short story. The actual content on a “Web 2.0″ site (any blog, forum, wiki, or what have you) lives in a database, usually under the control of an immensely powerful open source application called MySQL. If you’ve spent more than a few minutes working with open source software, you know that “immensely powerful” usually means “pain in the ass.” Communing directly with MySQL is not a point-and-click experience. But commune with MySQL you must, if you want to retrieve your content and move it into a different application’s schema.
Fortunately, I found a script and instructions that made the process relatively painless. The script is one of those traveling hacks that gets picked up, modified, re-posted, then picked up and modified by someone else. Both Drupal and WordPress get updated regularly, and the updates inevitably change the incantations one must do to move data from one application to the other. Because I was moving from Drupal 5.9 to WordPress 2.6, even the most recent version of the script didn’t quite work for me out of the box.
Taking my usual hacksaw-and-duct-tape approach, I simply deleted the portions that didn’t work. That means my version moved all of the posts and comments to the new blog, but didn’t preserve any of their categories. Drupal’s ridiculous “taxonomy” system just isn’t easy to map onto WordPress’s much more rational categories and tags, and in any case the hard part of the move was getting the posts and comments over.
If you want to migrate from Drupal 5.9 to WordPress 2.6, but are having trouble getting D’Arcy’s script to work, and you understand and accept that mine may trash your data completely, you can try it. As usual, anything you’re foolish enough to download from dovdox.com comes without warranty of any kind.
I’ve been struggling with a tricky problem in Web design lately: how to preview my sites in Internet Explorer. For my personal site, I largely ignore that buggy browser’s bizarre behaviors (see my archived tirade for details). But lately, I’ve been working on a Web redesign for a nonprofit group, and they need their site to be accessible. There’s no current version of Explorer for the Mac, and my old copy of IE5 doesn’t capture a lot of the more recent bugs the folks in Redmond have added. It seemed like the only reasonable option was to install Windows on my Intel Mac, paying hundreds of dollars to Microsoft to get a copy of their operating system, and then install Explorer. I have a moral objection to that, though, as it would mean enriching Microsoft, not in spite of, but because of their very worst habits.
Thankfully, the good folks at Codeweavers have come to my rescue. Instead of sending a big payment to Bill Gates, I can now send a measly $60 to this small company that helps support the Open Source movement. That’s the registration price for Crossover, a product very similar to the more popular Parallels. While both applications allow one to run Windows applications on the Mac, with Parallels you still have to shell out for a copy of Windows itself. Crossover eliminates that by using the open source Wine emulator instead. Now, back to hacking these stylesheets.
Back in the Good Old Days of the World Wide Web (circa 1995), changing the look and feel of a Web site was a pretty simple matter. You just opened up the HTML files in a text editor and changed the appropriate tags, then previewed the pages in Netscape. When everything looked right, you uploaded the new HTML files to your Web server. Because all of the content and layout information were inside the HTML file for each page, there was nothing else to keep track of.
In the past few years, that design approach, called “flat HTML,” has fallen out of vogue. Modern “Web 2.0″ sites – including everything from MySpace to Dovdox – store their content, layout information, and internal logic in separate files. A program running on the server assembles all of the information at the moment a user accesses the site, and serves the page. This more complicated approach gives modern sites a slew of new features, but at a price: it’s much harder to change the look and feel.
For example, I store a complete backup of Dovdox.com on my desktop hard drive, but if I simply open the index.php file in my browser, I get gibberish and error messages. That’s because my desktop computer doesn’t have the database and scripting languages of a full-featured Web server installed. If I want to change the layout of the site, I have two bad options. I can edit the text files that define the layout (the CSS files), then upload them to my Web server, then load the site in my browser to see how it looks. I tend to edit layout by “cut and try,” so all this editing, uploading, and reloading gets tedious pretty fast. The other option is to set up my desktop computer as a local server, which is what most serious Web developers do.
Unfortunately, configuring a local server on anything other than a Linux machine has been a pain in the butt. Until now.
This morning, I resigned myself to installing a local server on my desktop iMac, as I’m now doing some serious redesign on another dynamic Web site. At 8:00, I got ready to install the underlying scripting language, PHP, which is the first step in this usually protracted process. At 8:05, I discovered MAMP, a new, free application designed exactly for folks like me.
MAMP is a complete Mac installer package for Apache, PHP, and MySQL, the essential ingredients of a Web 2.0 server. Not only are these three tools packaged together, they’re already preconfigured to recognize each other (a big challenge in my previous efforts at installing a local server), and they get installed in a single folder that shows up in the Finder, rather than being squirreled away in obscure UNIX-only directories. MAMP even includes a widget that allows you to turn the local server on and off with a single click.
At 8:30, I opened a local copy of my Dovdox front page from my newly installed MAMP local server. It worked perfectly. By 9:15, I had installed Joomla, another content-management system, on my local server, and I am now free to tinker with it at will. The MAMP server isn’t a true Web server – its security doors are wide open, and it’s not optimized for heavy loads – but it’s perfect for running copies of Web 2.0 sites on a desktop machine in order to preview and edit them. Once I have the layout the way I want it, I can then upload the whole site to a proper Web server.
Time to party like it’s 1995.
I get this comment occasionally, and the problem always boils down to the same cause: Microsoft Internet Explorer. For years, the folks in Redmond have persistently ignored the W3C standards that every other browser now strives to meet. The upshot is that sites can either comply with the standards or try to look good in Explorer, but doing both is a huge pain.
In the course of maintaining a few sites, I’ve had to hack several workarounds for various Explorer bugs, and every one of these little projects has been excruciating. Microsoft’s failure to disclose its non-standard standards compounds the problem, leaving part-time Webmasters like me groping for solutions by trial and error.
The next time I hear “your page looks like crap,” the response will be “that’s because your browser is crap.” Download the fix for it, and then we’ll talk.