If you’ve been following along, you know I’ve given up on Movable Type as a blogging platform, and I’m moving this blog to WordPress. In Part 1 I explained why moving 10 years of blog posts with minimal link breakage was a lot of work.
Of course, I’ll have to have some place to move to. Which means I’ll have to design and set up another Wordpress blog. I managed to teach myself a bit about WordPress when I set up the Nobody’s Business group blog, and I liked what I saw of the technology. WordPress is easy to use and has a very active developer community, so I think it’s safe to assume it will be supported for a long time.
If you want to set up a WordPress blog, you have a choice of two broad solutions: You can let WordPress host your blog for you at wordpress.com, or you can download a free copy of the WordPress software from wordpress.org and install it on your own web host. I prefer the latter route because it gives me more flexibility. It does mean, however, that I need a place to host a blog.
Obviously, I already have hosting, but I decided to get a new hosting account so I could more easily set up the new website without interfering with the old one. And it’s just cleaner to start from scratch, so I can move over only the files I’m using and leave the junk behind. Windypundit had accumulated a lot of junk in its directory tree over the years.
The kind of hosting I need is a basic LAMP stack. That means Linux operating system, Apache web server, MySql database, and PHP programming language engine. This is far and away the most common hosting environment, and it will run WordPress and tons of other software I might want to install. I also want cPanel management tools so I can administer my account over the web without having to get a command line.
For now, I’ve decided to use a new shared hosting account from the provider I currently use, Downtown Host. I’ve had a few problems with stability over the years, but I see that as the natural flipside of their flexible configuration policies. (I.e. I’m paying the price in stability for flexible configurations of other websites on the same server.) The folks at Downtown Host have usually responded to service tickets fairly quickly, day or night, and they’ve been helpful when I had some minor special requests. I’ve tried using larger (and presumably more stable) hosting companies in the past, but they’ve been rigid and uncooperative.
I could probably get more flexibility with a virtual private server (VPS), but that’s more expensive. And more work. I’d have to install software updates regularly and clean up messes. There are tools to make that easier, but I’d have to learn what they are and how to use them. (And the tools change depending on which Linux distribution you install — CentOS, Debian, Ubuntu, Gentoo, Fedora — and I haven’t got a clue how to choose a distro wisely.) Ultimately, that’s just not a learning curve I want to follow. I guess I could avoid all that with a fully managed VPS plan, but that’s even more expensive. Windypundit just isn’t big enough to need all that.
Since my account allows me to host as many sites as I want for one monthly fee, subject only to storage and bandwidth limits, I’ve been consolidating some of my other sites onto the new server, in what I’m calling the Windypundit Media Empire. As I write this, Windypundit is still on the old server, and it will stay there until I finish the port to WordPress. The old server also has a test WordPress installation that I’ve been using to develop the migration process I described earlier.
After choosing WordPress itself, probably the most important decision I had to make was which WordPress theme I was going to use. I don’t want to just use a pre-built theme because I want Windypundit to have a unique appearance. On the other hand, I really didn’t want to build a theme completely from scratch. It’s a lot of work, and I’m not familiar with how to do it for WordPress. So what I really needed was a highly customizable theme. Or even better, a theme framework.
All WordPress themes are built from an HTML page layout with snippets of embedded PHP code that call into WordPress to fill in content such as posts, comments, and widgets. There’s also some CSS to style the HTML and a bunch of assets such as header images and custom artwork.
As far as WordPress is concerned, a theme framework is just another theme, but to a blog owner it’s a kind of construction kit for building themes out of template page layouts, template CSS, and a library of PHP code that can be used to implement certain common features. Often these frameworks come with substantial user interface tools that makes it easier to design themes without a lot of code.
Many theme frameworks are commercial products developed by professional WordPress design companies. Probably the most well-known of these is Thesis by DIYthemes, which is used by a lot of professional web designers to quickly create blogs and websites without a lot of coding and with results that are, frankly, pretty damned good. Jamison Koehler’s law firm web site is one of the most attractive blogging sites I know, and it’s built on Thesis.
Another big-name framework is Genesis by StudioPress. Genesis is oriented more toward using WordPress as a Content Management System for commercial web sites than for blogging. Unlike Thesis, Genesis isn’t an out-of-the-box theme; it’s intended as a base from which designers will build usable child themes. For example, Rick Horowitz used a Genesis child theme when he built his lawfirm website.
There are lots of other commercial theme frameworks out there such as PageLines, Carrington, Woo, Elegant Themes, and such drag-and-drop wonders as Ultimatum and Headway. They differ in the amount of HTML and CSS you have to write, whether they have built-in SEO or use a plug-in, security, support for designer and developer workflow, and dozens of other criteria. It’s a fascinating software niche, and if I were a professional web designer I’d probably license a few of them for building websites for clients.
But I’m not a professional web designer, I’m an amateur blogger who is also a professional web programmer. The difference being that I work with HTML and CSS and program code all the time. I’m used to it, and I like tinkering with code. So I prefer a framework that makes theme programming easier rather than one that eliminates theme programming entirely.
When I built Nobody’s Business, I used the Thematic framework because it was a popular free framework. It worked fine and I have no regrets. However, when I started thinking about porting Windypundit, I investigated a whole bunch of frameworks, and this time I settled on Hybrid because it seemed to have better documentation, a more active user community, and more recent releases (although I see that the folks at Thematic have been busy lately).
Hybrid actually comes in three layers. First, there’s Hybrid Core, which is essentially a PHP library for implementing WordPress themes. It can’t be used as a theme, but if you want to build a theme from scratch, Hybrid Core should make it easier.
The second layer is the Hybrid theme, which is full WordPress parent theme built using Hybrid Core. It’s a relatively simple basic theme, but you can use WordPress’s support for child themes to create a more interesting theme that provides more interesting versions of parts of the Hybrid theme. Hybrid’s creator, Justin Tadlock, has also released a bunch of other themes built on the Hybrid framework, several of which also come with child themes.
Finally, there’s Skeleton, which is a child theme of the parent Hybrid theme. It has all the CSS selectors laid out for you to fill in. You can just grab a copy of it, rename it, and start customizing it for your site. Which is exactly what I did. Unimaginative as I am, I call the result WindySkeleton.
Of course, I couldn’t resist the urge to make a few small modifications. I’m not overly fond of maintaining raw CSS, so I added a PHP version of the SCSS preprocessor to the site, copied all the Hybrid CSS theme files and renamed them to end in “.scss”, and wrote a small PHP front end page to compile and render CSS from the SCSS files. This makes modifying Skeleton even easier.
As for the actual site design, I’m not very good at that part, so I like to keep it simple, sticking to a very traditional blog layout. And my approach to choosing colors is as simple minded as picking out a nice banner photo and reusing some of its colors in the site design. Thus, the current design uses a lot of blue because the banner photo of the Chicago skyline has a lot of blue sky.
Originally, I wanted the new design to have even more of an old-school journalism feel to it than my current design, but I managed to derail that plan when I got it into my head that I wanted to use a night photo in the banner. That ended up taking the design in a very different direction. When I make the switch, you won’t recognize the place.
I’m also in the process of teaching myself Javascript and jQuery, so I decided to add a little animated flourish when the page loads. At the moment it looks kind of cool, but I expect it will get tiring. It’s basically the modern web version of the <blink> tag that made Geocities into such a hellscape.
I’ve still got a bunch of details to attend to before I cut over to the new site. For example, I almost forgot that Movable Type keeps its feeds in different locations than everybody is used to with WordPress. This meant I had to add redirection rules to send feed readers seeking the old feeds to the new locations. I’ll probably still put up a final post on the old site that warns people that they’re subscribed to an old feed. The site will be down so they won’t be able to read it, but it will be the last thing in the dead feed.
In addition, I’ve still got to add a bunch of other sidebar items to the blog (recent posts, archives, search, etc), create a robots.txt file (maybe), and tweak the design a bit more. Then, once I switch over, I’ll have to re-run the verification programs one more time, turn on comments, and enable all the statistics tools. I plan to use the same ones I have here — Sitemeter (which I consider to have the official authoritative visitor count), Google Analytics (the most useful), and Woopra (the cool new thing) — along with WordPress jetpack, but I don’t want to turn them on until the site is actually live.
And somewhere along the way, I’ll have to re-create my blogroll. That will be the subject of my next post about the move to WordPress.
Leave a Reply