It's not a long story, but it sure took its time playing out.
So... about the end of July I had given up on the old SubText 1.9.5-- mostly I was too familiar with the features available and I was really wondering about how to keep my interest going (see, running a blog is more interesting to the likes of me than actually writing a blog!). Within days of giving up on ever seeing SubText.net releasing an update what should happen? They release v2.0!
I got down to work. After a hard 2 weeks at work I sat myself down with my laptop, a baseball game on TV, a smart gin-and-tonic and set myself to work on upgrading to SubText.net 2.0. If only it were as easy as it sounds!
Obstacle #1: Keeping it simple...not.
My first inclination was to avoid the upgrade path by dumping my blog to BlogML, replace 1.9.5 with 2.0 and re-import everything. The idea was to go completely around any struggle with whatever idiosyncracies may lie underneath my deployment of SubText as I'd done some customizations here an there (all cosmetic-- I never bothered to build my own deployment from source code).
But the BlogML export was where I reached my first fail. Moment after pressing the "Export" button I got an exception message stating it was invalid to put a <![[CDATA marker inside of a CDATA section. I certainly understood the problem, yet I had no idea of where or why this was happening. Frankly having seen several features in the Admin area go unfinished I assumed so to was the BlogML export feature. So I moved on.
Obstacle #2: Going with the flow, try the upgrade anyway
The ease with which I brought the original SubText.net blog up had left a long-lasting good impression so I didn't feel all that bad about doing the upgrade path after all. I was sure at deployments the SubText developers had taken a lot effort to make things go as "plug-and-play" as possible.
So, carefully following the upgrade instructions at the SubText project site, I prepared my version 2.0 folder and uploaded it to my web host (more on that aspect later...).
At last some progress was being made as up came the admin screen "This blog is currently being upgraded ... if you are a blog admin click here to finish," etc. However, when I clicked the link, I was steered back to the "This blog is being updated. I chose to wait just in case but thirty minutes went by with no forward progress.
Certainly, something was the matter but SubText was not able to tell me what it was. The time had come for something more drastic.
Obstacle #3: Slash-and-burn, baby!
The only way to find out if I was going to get to use SubText 2.0 at all was to start with a clean slate, and knock down each problem as it came along. Blogs are just data after all, so since I'd made my backups there was always going to be a way to put my archives back in place.
I removed all the old tables from my database, uploaded an unadulterated copy of SubText 2.0 to my host and voila: the real problem shows itself: my web host had locked down the "trust" element in machine.config so the setting in SubText's web.config file:
<trust level="Full" originUrl=".*">
...was never going to work no matter what setting I chose.
Endgame
At this point, I let it go. Sorry SubText developers. It's not you, it's not me, it's my ISP.
Enter the Blogengine... dot-net.
Now I've moved on. I did some looking around.
Hearing good things about dasBlog, I paid their site a visit, but a quick glance at the installation instructions left me with the impression it was another blog platform that was better suited for authors who had full control over their web server.
Even BlogEngine.Net was looking doubtful. Their default format is an XML-file based blog (a great idea if you have limited resources to publish with) but I didn't have control over setting folder-level read-write permissions. I had nearly given up on this whole blog project until I found a form posting that explained how to deploy BlogEngine.Net on SQL Server. (Note: the forum posting is from July 2007, since then they've changed the name of the blog provider from "MSSQLBlogProvider" to "DbBlogProvider")
That did the trick. About 40 minutes after letting go of SubText I had a new blogging platform up and running.
But What About the Archives
Ceratinly I wasn't going to deprive you of my past wisdom, but all my blog material was sitting in some unused database tables, how would I get them into the new platform?
Well, I hadn't given up on BlogML at all. After about 2 hours of false-starts fiddling with the SubText source code to properly extract my old blogs from the database I was at another crossroads. To be sure, I really, really wanted to use the BlogML assembly from Codeplex, but I couldn't make head nor tails of it. Being about midnight already I decided: "XML is XML, I'll just roll my own". I gave up on ever using any source from SubText or BlogML and mashed together a small console app to copy my blog into a BlogML file of my own making.
Using the sample BlogML file included with the binary download of BlogML I cobbled together XmlTextWriter and Linq (first time using it, what a mess) into an output file.
To my amazement, this worked. Now my entire blog is on the Blogengine.Net platform.
Conclusions: If it ain't broke, don't fix it
This whole ordeal spanned two days of my weekend, taking me into the wee hours of Sunday morning. If I had only been satisfied with SubText 1.9.5 then none of this would have happened.
But that's just not me.
And I'm not going to tell you one platform is better than the other. But I do think Blogengine.Net is going to suit me just fine.
As for the BlogML extraction code, it's far from perfect but I'll be glad to share it with anyone who wants a standalone app to make backups of their SubText blog-- but I make no guarantees on software authored after midnight.
Leave a comment if you want the source code for extracting BlogML from a SubText database.
Tags: blogging, subtext.net, blogengine.net, web hosts, upgrades