Blog migration

As I did not have a backup of the actual Blosxom.PHP code, with all my modifications, that the old blog was running, I made both server and platform switch at the same time. For the new blog platform I chose Serendipity, because like Blosxom.PHP it offered the possibility of using an embedded database (in this case, SQLite) rather than requiring a separate database instance on a server.

Installation was a breeze; unpack the tarball, browse to the server and fill in some basic information. Next I could start importing the old entries, which I did manually because there was no full XML feed of articles available.
I quickly encountered an annoying formatting issue: text sections inside pre tags would have a superfluous blank line in between each line. Lists made with ul or ol suffered the same problem.

After some investigation, it turned out that serendipity was adding a <br /> for each newline entered into the entry text, including the sections inside the above tags — whereafter the browser would render these breaks as superfluous blanks within such sections.
Some searching around in the admin interface made me find a “nl2br” markup plugin that was active, and offered the possibility to exclude from being run on text within certain tags. Fixing the spurious linebreak problem was simply a matter of adding the forementioned tags to the exclusion list; why they are not there by default is beyond me.

Next up after the entry import was comments import; as there were even less comments than entries in the old blog, at first I added a few of them manually through the sqlite command. This was in part also because I wanted to get the comment timestamps right, something that I wouldn't be able to do by adding comments to the articles through the blog comment interface.
I then noticed that the serendipity admin interface actually allows to edit comments before approval, so I then simply added a bunch of empty placeholder comments (each pointing to the correct articles though) that I could edit and approve, which was easier than having to insert all comment text through sqlite.

Moving on to syndication. On the old blog, I had removed all feeds for public access and added a feedburner link instead (though the atom feed was still working). The plan was to now do this again, and in fact make sure that the direct feed links would no longer be accessible but redirected to feedburner — the old site's atom feed still worked, even if it wasn't advertised anywhere.
Looking at the syndication plugin's configuration, I disabled all feed formats except feedburner, entered the feedburner id, saved the configuration, and navigated to the main blog site... to find an empty syndication `nugget'.
Went back to the plugin configuration, set the feedburner option to “force” rather then just “yes” — still no link.
I then went searching the serendipity forums, and after reading a dozen or so threads I found one where a user reported the same problem. And was promptly answered: for the feedburner option to work, it is also necessary to have one other feed option active, and feedburner set to force.
Once I re-enabled one other format, there was a link on the generated page. Which still pointed to the blog feed itself?!
However, it turned out that clicking on that link redirected to feedburner, so everything was OK now.

Thinking about it, there is some logic in the requirement to have one feed format published for the feedburner option to work, as you will need something to point feedburner to. Which fact is easy to overlook however if the feedburner feed already pre-exists and is pointed somewhere, even if on a different site.
The syndication issue is actually indicative of the main serendipity weakness, lack of proper documentation. Especially on the various plugins, there's little info about the settings available.

At this point, the new blog was basically ready to start being used. I decided to leave the old one up and just redirect it's feed URL to feedburner in the .htaccess file for the time being. And indeed, I soon started seeing a few page fetches on the new one.
Even better, when I checked Planet Debian and Planet Grep shortly afterwards, they both listed the feedburner location for my feed now. No manual intervention required there, it seems.

There was one problem with my feed on the planets though: they both listed a few older posts, lumped together, as very recent while they actually weren't. Annoying as this was, this would hopefully be just a side effect of the migration and I decided to not further investigate.

I then noticed another problem on the planets: they listed a “nospam@example.com” email address together with my name. Surely I had disabled email address display? And I definitely hadn't entered that address anywhere.
When I checked the ATOM feed source, it indeed listed that address inside the “author” block. A little grep for it revealed it to be set in a PHP include file where an array was filled to be used in the various feeds' smarty templates, and inside that function was a comment that email was a required field. Which, at least for ATOM, is not the case. And it isn't for any RSS version either, as far as I could find out.
I solved the issue by checking the value of the no_email array value in the ATOM smarty template and depending on that value, only optionally adding an email element.

All seemed fine at that point, I could publish new articles, they were picked up and republished, visits started flowing in on the new blog, people commented. And then when I approved comments from the moderation queue, the article where a comment was added appeared completely on top of the planet sites again.
While the article bumps were great for traffic, this wasn't very considerate of the other planet members. A little looking around on the serendipity forums revealed that each time a comment was added (approved when moderation is active), serendipity resets the “updated” element in the ATOM feed.
According to a comment in the thread, this is correct publishing behaviour, and could not easily be disabled; but there was a workaround: by setting $serendipity['max_last_modified'] in serendipity_config.inc.php to a really low value, like 1, this resetting would effectively be disabled. The max_last_modified configuration item is a number in seconds, after which age the updated element will no longer be reset when comments are added.
I have yet to see if this actually works, but I guess it would if said as such.

All in all, there have been a few bumps on the road, but in the end the move seems to have worked out fine. Giving me back more time to focus on other items on my long TODO list.