Blog remodeling

Print Friendly

Effective January 1, 2010, this site does not use Drupal and instead uses only WordPress.

This last week I experimented with a couple of different ways of reorganizing this blog and making it easier for me to extend the website in the future.

The first thing I looked at was drupal. I’ve played with this from time to time and always end up with the same conclusion: while it looks great and powerful, moving my 2500+ blog entries and 2600+ comments to it, with all the design elements would simply be too much work.

Let me explain that the blog is just part of the overall website. It is currently built on WordPress, but the CSS design applies to the entire site. Thus the essay section uses the same style as the blog. The blog is embedded in a more general design so that, for example, the left sidebar is common to everything. Thus WordPress does not run all the content, but is just one part of it.

The photo application that I wrote uses the style but shares no code with WordPress. The early stage Second Life book has a lot of PHP processing in it but, again, shares nothing with WordPress. This means that I can’t just move to a new WordPress theme and expect the rest of the website to follow. I also can’t let WordPress run the whole site, though I could probably such a few things such as the essays under WordPress as pages.

So I left the overall website architecture intact but started moving a few things around. You’ll notice that it is no longer the “Open Blog” but just the blog. There is just one blog on this site, so there is no reason to call it out specially. Also I talk about a lot of things that don’t necessarily have “open” in their names. This doesn’t mean that I won’t talk about open source and standards.

I moved some things that were on the blog-specific right sidebar to the site left sidebar. I tweaked a bit of the CSS. Generally I’m going to try to smooth out the rough edges when moving from one area to another.

I would like to change the overall style but I every time to play with something, I always come back to this one. It’s not bad, but I’ve been staring at it for over four years. I’m coming to the conclusion that any style change would involve changes to some colors and some font tweaks, not wholesale reshuffling of elements. Ideally I would develop a sequence of little changes and put them in place over time.

For some reason I keep coming back to thinking that I want green to be the dominant color rather than blue, but just switching the background and a few font colors doesn’t do it for me. Let me know if you see a site with a dark smoky green whose style I should emulate.

By the way, in my experiments, typically around midnight, I tried to create a new WordPress blog and import the full contents of this blog into it. This involved exporting the current blog into XML and downloading it, then uploading it into the new blog. I had to tweak several PHP parameters to get the upload to work at all (such as the sizes of upload files and files retrieved by POST), but I never got it to work completely.

The fie would upload and then things would crash in the middle, leaving me with partial contents. If I tried to import again, I would get multiple copies of categories. It’s possible that PHP is just quitting, though I upped the usual script runtime parameters. Nothing was obvious in the error logs.

I know there are various schemes to hand edit the 12M XML export file and break it up into smaller pieces, but since this was just an experiment, I didn’t bother. So while it made me nervous that the import didn’t work smoothly, I’m confident that it would be possible with more work.

By the way, using the WP-DBManager plugin to suck the old blog into the new blog did not work. The database would get bigger but the blog entries would not show up under WordPress. Otherwise, I love this plugin and recommend it for maintenance of a single WordPress blog’s database.

This is all I want: simple and 100% reliable export of one WordPress blog of arbitrary size, and import into another one. They can even be on the same physical website, so I don’t want to have to download and upload big files.


One Comment

  1. Bob, it sounds like you’re going around the same block that I have, a few times.

    My sons’ blogs are on PivotLog, which doesn’t use MySQL, because I have some hope that my grandchildren may be able to read about their fathers as university students some day. PivotLog on flat files ensures greater portability, but reduced function, as it’s not as popular as WordPress.

    I’ve run my main professional blog on WordPress, and then for the rest of the content, I use Drupal. I don’t use the same CSS across WordPress and Drupal. I notice that there’s even an evolution of the structure of styles sheets on WordPress (i.e. the Carrington theme developed by Alex King, that I wouldn’t begin to know how to handle in CSS.

    I’ve tried to keep a similar look across WordPress and Drupal (e.g. top navigation bar, plus I like right sidebars), but there’s sufficiently different functionality that I don’t find 100% compatibility desirable. I’m really conscious that I want as little navigation to load before content as possible. Since I’ve just moved from a Treo 650 to a Blackberry Curve, I’m now conscious of how my blog — as the main page onto my professional site — loads on mobile devices. You might be interested in the WordPress Mobile Edition plugin for your blog. Similar functionality isn’t available for Drupal, but isn’t as necessary for the type of content that I put there.

    Now that I have working blogs and web sites, I really don’t want to spend the weeks required to fully transition to new technology. (It’s almost as bad as migrating laptops!) In CSS, I know that there’s a problem in my three-column WordPress theme — one column submarines to the bottom of the content when users come in on IE — but fixing that bug is sure to burn at least 3 to 4 days without guaranteeing that I’ll come to a successful resolution.

Comments are closed