Dedicated to my late brave, beautiful and silly mummy, Debra Ross. I love you mumster.

Skip navigation

WordPress eXtended RSS fun

WXR

I haven’t been having much luck with technology this week, but this seems to be the icing on the cake so to speak. The problem is no matter how hard I try I just can’t get WXR working.

WXR is of course the WordPress eXtended RSS format which allows you to quickly export the entire written contents of your weblog including posts, pages, categories, tags and kitchen sinks. It means you can pick up the guts of your weblog, then do a backup of your wp-content folder which contains all your uploaded media, plugins and themes, then import them somewhere else.

Only problem is, this is the seventh time and I still can’t get it to work on one WordPress installation. I have a local web server running on my MacBook Pro which I’ve set up to test new themes and plugins I’m working on, and on this local installation of WordPress I can import my Rubenerd Show material without any trouble at all, but I’ve had no end of trouble when I try to do the same thing from the Rubenerd Blog.

The curious thing is that there’s no consistency to the errors. On Thursday I tried importing from this weblog and WordPress silently failed; the import page just stopped rendering after it had uploaded the file. Then yesterday I tried again and it was able to import posts but only up to September 2006 when it decided to stop.

The only things I can think of that could be causing this problem is the WXR export php file in WordPress wasn’t uploaded to the server correctly, or the file (2.2MiB) is too big somehow for my local web server to handle, or maybe there’s some malformed HTML in one of my posts which breaks the resulting XML file it’s contained in… maybe it’s just gremlins.

One clue though showed itself when I tried to open the exported WXR file in Smultron:

So perhaps it’s an encoding issue? Or does Wordpress not output UTF-8? Could it be failing because some of my posts have East Asian characters which need UTF-8?

Whatever this blasted problem is, it looks like this is going to be a very, very, very long Saturday.

Enabling UTF8 in Nano

nanoutf8.png

Everyone knows that vi and vim are better than emacs right? Well personally I prefer nano even over vi. It was the first text editor I ever learned (okay it was actually pico, the editor it was cloned from) on UNIX and even now I use it for almost everything: Ruby, Perl, HTML, XML, KitchenSink… even these weblog posts. It’s a small world, so why not use a small editor? Hey, that’s catchy.

The problem though if you install Nano from MacPorts is that it’s not enabled with a number of what I would consider critical features. Aside from syntax highlighting support probably the most noticeable of which is the lack of UTF-8 support which means it spits out a series of question marks whenever you’re editing files with katakana, kanji and kitchen-sink in it for example. Bummer.

A cursory glance over at the DarwinPorts website shows that in fact it’s possible to enable UTF-8:

Variant: utf8 {
configure.args-append –enable-utf8
configure.args-delete –disable-utf8
depends_lib-append port:ncursesw
depends_lib-delete port:ncurses
}

The key is simply to add +utf8 when you initially build the port, along with any other conditions you think are spiffy:

sudo port -v install nano +utf8 +color +no_wrap