This is kind of an extension to my earlier post on Blowery.web and ScriptResource.axd. I've completed the migration to dasBlog 1.9.7-ish (doesn't it look awesome?). Which probably wasn't a wise thing to do since a brand new release version is expected in the next couple of weeks after which time, it looks like I won't need to upgrade the project to ASP.NET 2.0 myself anymore. But Scott's timing doesn't mesh with my vacation schedule (come June 14, I's be a European Hillbilly for a couple of weeks).

Tweaking dasBlog to work with the current version of ASP.NET AJAX and the AJAX Toolkit will wait for a future post. For now, I just want to discuss an issue that actually came up the last time I did this but I didn't look into it in much detail. Essentially, whenever a postback was required (posting a comment, updating the configuration, etc, etc, and so on and so forth), I would get an error that WebForm_PostBackOptions was undefined.

The most likely reason for this: Something is messed up with your WebResource.axd file. I know not the details of this file but apparently it is required for ASP.NET 2.0 forms to do postbacks. And in fact, it's not actually a file but a file served up by (I think) an HTTP handler.

So if you get this error, chances are the WebResource.axd file isn't doing its job. Or the HTTP handler isn't do its job and isn't even serving up WebResource.axd. The easy way to check for that is to look at your page source and see if you can find a line like the following:

<script
   src="/ajaxtoolkit/WebResource.axd?d=cCvonavza7NGh4PxQfj5rw2&amp;t=633135374249468480"
   type="text/javascript"></script>

The path to WebResource.axd will be different of course (this was taken from one of the samples over at http://ajax.asp.net/ajaxtoolkit). If you can't find that reference, I dunno, try Google to see if you need to register an HTTP handler somewhere. Maybe your ISP doesn't have it in the machine.config. I haven't run into this particular problem.

The one I *have* hit is when the reference to WebResource.axd does exist but you still get this message. Normally, when you navigate to the path specified by the <script> tag, you'll see a bunch of javascript (with the very first function being WebForm_PostBackOptions, in fact). But if you get this message, you will probably get a blank HTML page when you navigate to WebResource.axd.

As happened last time, I had to add WebResource.axd to the excluded paths for <blowery.web>. I guess this isn't a file that want compressed (although ScriptResource.axd seems to handle it fine, provided blowery is the only thing compressing it).

And just like last time, when I moved it to my server, it didn't work. This time though, I was a little wiser and had more time to kill so I thought I'd try to track it down.

Turns out you don't exclude WebResource.axd from compression in blowery.web. Rather you need to exclude ebResource.axd. That's not a typo. Here is what my blowery.web section looks like:

<blowery.web>
<httpCompress preferredAlgorithm="gzip" compressionLevel="high">
<excludedPaths>
        <add path="WebResource.axd"/>
            <add path="ebResource.axd"/>
        </excludedPaths>
        <excludedMimeTypes>
            <add type="image/jpeg"/>
            <add type="image/gif"/>
        </excludedMimeTypes>
    </httpCompress>
</blowery.web>

For whatever reason, blowery has code that skips the first letter in its excluded paths. And I can't take any credit for discovering this.

So there you have it. I now have a current dasBlog installation with compression turned on. You can tell all your friends about me now.

Kyle the Decompressed

Am in the process of upgrading to the latest dasBlog build in an attempt to combat some of the referral spam I've been getting (which is a little odd since I don't show my referrals anywhere). Would like to be able to turn the pingback and trackback services back on here too. I have a feeling Akismet isn't going to solve all of these problems but I've got some time on my hands.

Which is a good thing because I've been putting this off on the grounds that it will take time to get up and running again with a new version of dasBlog. The reason being my hillbilly theme (which is looking more and more like it needs upgrading every day) uses Atlas. Not ASP.NET AJAX Extensions. As in, I got Atlas working with dasBlog many moons ago and never looked back. So there be some work to do not only making sure I upgrade my AJAX installation but also with the client-side scripting I'm using to render the AjaxControlToolkit doohickets I'm using.

But that's for another post. Today's tidbit involves ASP.NET AJAX and the blowery.web control which dasBlog uses. It seems they don't play nicely together out of the box (or at least not the way dasBlog configures blowery.web by default). After getting the latest dasBlog source, upgrading it to ASP.NET 2.0, and adding my ScriptManager, I get getting a javascript error: Line: 1 Error: Invalid character.

To get the solution out of the way for those looking to get on with their project: Modify the <scriptresourcehandler> node in your <system.web.extensions> section of the web.config:

    <system.web.extensions>
        <scripting>
            <scriptResourceHandler 
                  enableCompression="false" 
                  enableCaching="true" />
            <webServices>
            </webServices>
        </scripting>
    </system.web.extensions>

This is merely speculation but I suspect that both AJAX and blowery.web are trying to compress the ScriptResource.axd that is output by the ScriptManager. I'm guessing you could also configure blowery.web to exclude ScriptResource.axd instead if you were inclined to let ASP.NET AJAX do its own compression.

I was going to relate my entire odyssey in discovering the error but now that the solution is in print, it seems kind of moot now. I will point out that I had to switch to Internet Explorer to figure this out though. It may be my configuration but Firefox didn't through any javascript errors at all.

Kyle the Compressed

 
Old, ugly search box reminiscent of the Teletubbies

I think I should have stuck with the junk-mail-subjects-as-post-titles theme. "oprah used it to lose weight" would have been pure gold...

Anyway, Jayzus only knows why I spend my time on this stuff but for whatever reason, the bubbly looking search box on my blog annoyed me enough that I extended an extender. The RoundedCornersExtender to be specific.

I added four properties to it: TopLeftCornerStyle, BottomLeftCornerStyle, TopRightCornerStyle, and BottomRightCornerStyle. The value of each of these can be one of: Inward (default), Outward, or None.

If you leave these properties off, you'll notice absolutely nothing different in the control which was my intent. But you can now change any of the individual corner styles to either Outward or None. Outward means that the corner will curve outward and None means no curving will occur at all.

To illustrate, here are the settings for the new search box you see above (and in the graphic below):

• TopLeftCornerStyle: Inward
• TopRightCornerStyle: None
• BottomLeftCornerStyle: Outward
• BottomRightCornerStyle: None

It is left as an exercise to the reader to determine what the settings are for the RSS section above the search box.

  
Svelte, new search box oozing class

The revised extender is attached. Note that I kept the same name for the control so it can't really co-exist with the existing RoundedCornersExtender. There's no real reason for them to co-exist. This is kind of a superset of the original one. Plus I wasn't really thinking that far ahead when I started.

I'll forego the detailed explanation mostly because by throwing it out there so cavalierly, I can make it sound like I whipped it up in a very short time (which I didn't) rather than spending several hours on it at the expense of my family (which I did). Plus I'm lazy.

I updated the CodingHillbilly theme if you want to see how it's done client-side. I also updated the other Atlas Control scripts because of changes made to the latest release version of Atlas (namely that it seems the AtlasControlExtender.js script has been renamed BaseScripts.js and there is now a Common.js script).

Side note on dasBlog: Does anyone know a way of developing themes in version 1.9 that doesn't require me to have to clear my temporary internet files every time I want to see my changes? No suggestions about the IE setting to get the latest version every time you load the page, please.

And lastly, when the &*$% are the Atlas people going to fix that typo/spelling mistake/abomination in the CollaspablePanelBehavior (sic)?

RoundedCorners.zip (4.96 KB)

** UPDATE ** Latest version of the toolkit now has this functionality built-in and implemented better than mine. Download mine at your own peril.

A couple of minor clean-up details on my recent Atlas journey.

Firstly, during the upgrade, I again had to remove all references to blowery.web from the web.config in dasBlog. Not sure why. It works on my laptop, not on the server. Perhaps something to do with Windows 2003. I care not...for now. But don't you folks go makin' the Coding Hillbilly all pop'lar now.

To clarify the javascript references for Atlas: There are a lot of them necessary for basic Atlas functionality. All of the Atlas .js files are in C:\Program Files\Microsoft ASP.NET\Atlas\v2.0.50727\Atlas\ScriptLibrary\[Debug|Release].

The good news is you don't need to reference them yourself. The ScriptManager handles that for you. But if you are in an environment that doesn't allow ASP.NET server-side controls, like PHP, you need to copy these files somewhere in your project and reference them. In order. Don't ask me what the order is.

The extenders in the Atlas Control Toolkit also require appropriate .js file references. These files are located directly in the codebase which is wherever you unzipped it.

Again, good news here. If you add a CollapsiblePanelExtender server-side control to your .aspx page, you don't need to worry about these references. For dasBlog, however, the themes don't support server-side ASP.NET controls (as far as I know) so my options were: a) embed the server-side controls directly into the WebControl objects (which I did the first time around), or b) bring the .js files I needed into my theme folder and reference them directly

The extender scripts aren't quite as order specific. You need to reference the AtlasControlExtender.js script first, I imagine, but after that, they're pretty much all independent of each other. The CollapsiblePanel is one exception because it relies on animation code in the AtlasUIGlitz.js script and for whatever reason, my ScriptManager wasn't including it. I imagine one of the ScriptManager properties could handle that but the less mucking with compiled code, the better.

Man, I gotta lay off the 'shine. Two fairly decent credibility-buildin' posts absolutely slaughtered in a moment of weakness.

So here's a question for ya. Now that I have Atlas and dasBlog in their own little marriage of convenience, what do I do with it? I can't submit it for addition to the codebase because Atlas requires .NET 2.0 and I imagine my recommendation would be met with a hearty "Nein!" as the French might say. (Oh wait, we ended up saving them in that war, didn't we.)

I guess I could post the whole application again somewhere but frankly, I didn't do that much to the codebase itself. Ninety-five percent of it is documented on the Atlas site anyway.

Oh well, I was in it for the academic exercise anyway (unlike those glory-hounds in Edmonchuck). At some point, I'll probably start incorporating more Atlas features into dasBlog outside of the themes. At least where it makes sense, like when you're scrolling through dates looking at your dwindling viewership. And certainly when you're editting your links. Not sure what I'll do with that when it's done either since I'm essentially forking the code (tee hee) from what the newtelligence folks are working on.

Sucks that doing this is more fun than my other project which has some modicum of profitability to it.

So now that DasBlog was all set up for Atlas, complete with ScriptManager, the next step was to add a couple of controls from the Atlas Control Toolkit. Specifically, I'm using a TextBoxWatermark in the search box and RoundedCorner and CollapsiblePanel controls for each of the funky brown blobs you see to the right.

In the first iteration, I had opened up each of these controls individually and had myself a little hootenanny in each one. I created a bunch of panels and images programmatically within the Render method as well as CollapsiblePanel and RoundedCorners controls attached to these panels. At some point, I found it necessary even to move all of that code out of the Render method and into CreateChildControls (where I believe it belongs; what if I want to handle events by any of the constituent controls?). Can't remember why I needed it, probably for the calendar which required me to create a whole brand now control specifically so I could wrap it in a bunch of Panels to house the heading and dropdown image.

The end result, as I alluded to in a post from many moons ago, was FrankenBlog. A blog only a mother could love (but not my mother). The controls were so intrinsically tailored to the CodingHillbilly theme, the code was nigh unreleasable to the general public, lest the coding Hillbilly be scoffed for reasons other than his penchant for plaid. (On a side note...does anyone even know what 'intrinsically' means?)

But I's a smart bumpkin and I knew others might like to know how to do this themselves. And I sure wasn't about to release that code. It was, to continue the Frankenstein theme, abby-normal.

Anyway, enough pre-amble. Here is the HTML for my Links box:

<div id="navLinksDiv">
   <div class="navHeader" id="navLinksHeader">
      <div style="float:left;">Links</div>
      <div style="float:right;"><img id="navLinksImage" style="cursor:hand;" src='<%radio.macros.imageurl( "webpart-up.gif" )%>' /></div>
   </div>
   <div id="navLinksContent">
      <%navigatorLinks%>
   </div>
</div>

Pretty standard HTML and it nicely highlights my disdain for using tables for layout.

And herein lies one of the many Good Things^© about the toolkit extenders. They extend. As in you write your HTML like you normally would and apply whatever extenders you want to them.

One issue though is that all the toolkit samples show the extenders being applied to server-side controls. And they show the extenders as server-side controls themselves. But they don't need to be. The extenders can be applied client-side to regular HTML controls.

The following javascript will add a RoundedCorners extender to the navLinksDiv div above:

var roundedCorners = new AtlasControlToolkit.RoundedCornersBehavior( );
roundedCorners.set_Color( "#706861" );
roundedCorners.set_Radius( 10 );

var theDiv = new Sys.UI.Control( $("navLinksDiv") );
theDiv.get_behaviors( ).add( roundedCorners );
roundedCorners.initialize( );

It looks a little funky but yes, it's javascript. Atlas has abstracted a bunch of things and added an object model that I REALLY hope gets better documentation before release time. Hillbillies get cranky when there ain't no intelly-sense.

So we create a RoundedCornersBehavior object and set some properties on it. Then we create a Sys.UI.Control object which is, I think, a generic Atlas control. There are more specific ones but they correspond to actual form elements like textboxes and dropdown lists. In this case, we're applying it to a div, so we create a Sys.UI.Control.

Note that we pass in the ID of the DIV in the constructor (if I recall, the $ notation is Atlas-shorthand for document.getElementById but don't quote me). This was a little weird for me because now we've essentially got this Sys.UI.Control object that's bound somehow to the navLinksDiv HTML element. And in the next line, we call this method on it that attaches the roundedCorners behavior to it. And somehow this all filters back to the original HTML element, which hasn't really been touched.

Obviously, this code doesn't work out of the box. You need appropriate javascript references. The ScriptManager handles the base Atlas script references for things like the controls in the Sys.UI namespace. For the RoundedCornersBehavior object, you need to include a reference to the RoundedCornersBehavior.js file that is included in the AtlasControlToolkit source code:

If you are using the server-side controls, this reference isn't necessary because the control itself handles the references for you using WebResource.axd, which I understand not at all. As you can see here, I've copied the .js file into my theme folder for easy reference. And the reference to AtlasControlExtender.js I gather is necessary if you're going to do any client-side extender work. All I know is that it didn't work when I just had RoundedCornersBehavior.js references and it did after I added AtlasControlExtender.js.

I'll wrap it up by saying the entire theme is attached. homeTemplate.blogTemplate is where all the action is. (Apologies in advanced on the formatting. For whatever reason, I slugged it out with Visual Studio as my editor and it kept wanting to reformat everything in that annoyingly helpful, Steve Urkel-like way.) There are a couple of other little things like the fact that Atlas will always call the pageLoad javascript function if it is defined and that the AtlasUIGlitz.js function is needed to make the animation in the CollapsiblePanel work. Hopefully the comments are clear.

The end result is: It is possible to use the Atlas Control Toolkit within your themes without having to muck around (much) with the codebase. On reflection, this whole post could have been laid out better had I known I would go into full "how to" mode. If anything is unclear, gimme a holler.

And finally, sweet Jayzus am I ever getting tired of correcting myself when my fingers inevitably type "behaviour".

Evenin' Hillbillies. Got somethin' t'say on my upgrade to dasBlog 1.9 so iffen you'll turn your attention from your squirrel skinnin', I'd be much obliged.

The reason for my upgrade is solely to support FlareItems, something I could have done earlier with one of the intermediate codebases but I don't do nuttin' until Scott Hanselman tells me to.

It wasn't something I was looking forward to because I had bastardized my existing version to wedge Atlas controls into it. As it turns out, though, I was able to learn from my recent trials and tribulations and get the new version of dasBlog working with Atlas controls without having to embed the controls into the codebase itself. So what you see on this har site are the following AtlasControlToolkit controls in action with very minimal changes to the core code:

• TextBoxWatermark (in the search box)
• CollapsiblePanel
• RoundedCorners

In the previous version, I had embedded these controls server-side into the individual pieces, SideBarList, CategoryList, and so on and so forth. Which means these controls were useful in my theme and nowhere else. The brown rounded corners did not really lend themselves to...well...any other theme in the world.

Forthwith, a list of non-theme changes I made to dasBlog to support the inclusion of Atlas and the Atlas Control Toolkit:

• Upgrade the project to VS2005. Follow the instructions. They work.
• Add a reference to the Microsoft.Web.Atlas assembly in both the newtelligence.DasBlog.Web and newtelligence.DasBlog.Web.Core projects
• Add a reference to the AtlasControlToolkit assembly in the newtelligence.DasBlog.Web project. I'm not entirely certain this is necessary. It could be enough that you include the assembly in the bin folder because all the functionality is handled client-side. I.E. There are no actual server-side AtlasControlToolkit controls created.
• Modify the web.config to accommodate Atlas. This and the previous step are detailed here.
• Added the following code to the top of the Page_Load event in newtelligence.DasBlog.Web.Core.SharedBasePage:

Microsoft.Web.UI.ScriptManager manager = new Microsoft.Web.UI.ScriptManager( );
this.Controls.Add( manager );

• Re-compile

The second last step I think might be considered a little dicey. The rest of it is essentially what you would do to any application to Atlas-ize it. But I needed a place to put the ScriptManager and this seemed the logical choice. Unfortunately, it means you're getting a ScriptManager whether you want one or not.

The other option is to include script references to all of the Atlas javascript files in your template which I'm not too comfortable with because those seem to be dependent on the order in which they are loaded.

Anyway, that's it really. Now you can start using Atlas features in dasBlog. You might need to play around with the settings on the ScriptManager depending on what you're doing. The next entry, which I will post shortly, will detail what I did to include toolkit controls into my theme.

Last entry today, I promise. And I'll try not to switch topics so fast. Sorry if I'm giving you whiplash.

If you take a look at the search box at the top, you'll see the TextBoxWatermark Atlas control in action. Tell me it's not glorious!

But to get it to work, I had to rip out the compression module from the web.config. Try as I might, I couldn't configure it to leave the WebResource.axd file alone. I used Fiddler to monitor the traffic and every time WebResource.axd appeared, I saw content-encoding: gzip and X-Compressed-By: HttpCompress. Yes, I have WebResource.axd in my <excludePaths> for the module. Not sure why it's happening on my server and not locally.

So here I am with pages flying around uncompressed. I feel like it's 1998 again.

Next step will be to try and get some other extenders incorporated. As I alluded to in a previous post, this won't be easy. Whereas the search box is nicely contained in an .ascx UserControl, the other controls are all WebControls. Which means creating the Atlas controls programmatically.

In the meantime, I have been seriously neglecting Sid Meier's Pirates! these last few days so I'm off to find some buried treasure.

I'm no designer but there are a couple of things I know I like. One of them is max-width. On my first attempt at a theme, I fixed the width at 775px. I've never liked doing that because it looks so crappy on my 1600x1200 resolution laptop. By the same token, I'm getting too old to read text that scrolls across that entire screen.

So what I really want is to say, "expand this as the window expands, but only up to a point." In other words, I want to set a maximum width on my content.

That's what the max-width CSS property is supposed to do and that's exactly what it does do in Firefox. IE6 doesn't support it but there is a workaround:

width: expression( document.body.clientWidth > 990 ? "990px" : "auto" );

Seems IE lets you insert javascript into your CSS which was easier for them to implement than just following the CSS spec...I guess...Whatever, the reason, my theme uses that (plus a little additional ditty to impose a minimum width) and now I get what I want.

But not without some problems. When I tested it originally in my theme, the maximum width worked in that it wouldn't go past 990px. But it also wouldn't adjust when I made the window smaller than that. In essence, I had a fixed width 990px DIV. But I had seen this working in practice so I couldn't figure out why mine didn't work.

It wasn't until I removed the DOCTYPE declaration for loose.dtd at the top of my theme that it actually did start working. Weird.

The only other major thing I wanted to change is the image at the top. I switched it from an explicit <img> to a background-image so that, again, I could make my page more liquid without having scrollbars appear at inopportune moments.

And it's *$%-ing annoying having to support two browsers again. One of them had better win this war soon...

Yeah, I've been playing with themes. Ya wanna make something of it? It's a work in progress so if something looks wonky, let me know.

My current project du jour is to integrate Atlas into dasBlog. Specifically, some of the controls in the Atlas Control Toolkit. Hence my desire to migrate to VS2005. I notice there is already a dasBlog "port" for VS2005 but frankly, that project kind of baffles me. Not sure how they can get away with rebranding it like that and calling it version 1.0 but more power to them if they feel like taking something like that on.

Before I get started, I'll be making claims about dasBlog here based on my limited experimentation. I'm relying on more knowledgeable people to correct me.

I followed the instructions to add Atlas to an existing applications and lo, it compiled! And ran! Next step: add a ScriptManager, which is where I hit my first snag.

I added it to the top of default.aspx before the placeholder and got an error. The ScriptManager needs to exist in a server-side control, usually a <form runat="server">. By putting it in the default.aspx, dasBlog parses it into the <head> tag. You are allowed to put a ScriptManager in a <head> tag but it must have runat="server" in it and it seems you can't do this in dasBlog. The <head> tag is part of the template and adding runat="server" to it does exactly nothing.

Instead, I added it programmatical in the Page_Load event in the SharedBasePage:

ScriptManager manager = new ScriptManager( );
this.Controls.Add( manager );

Re-compile and refresh and success! We have a ScriptManager on the page in the form of a Javascript reference to WebResource.axd. Note that this requires that the Web.Core page have a reference to the Microsoft.Web.Atlas assembly.

Fast-forward a bit. I added a TextBoxWatermark extender to the search textbox. This required fiddling with the Search.ascx control so that it used an ASP.NET TextBox rather than an INPUT but that wasn't too much trouble.

Re-compile and refresh and succe---waitaminute. It loaded with no errors but my watermark was nowhere to be found. I checked the source code and all the pieces were there: the WebResource.axd and the Atlas pageManager with my TextBoxWatermark reference.

To condense a couple of hours of digging, the reference to WebResource.axd was in the HTML but it didn't return anything. The reason for this is that it was being compressed by some component in dasBlog. The fix is to modify the <blowery.web> section of the web.config (additions in red):

  <blowery.web>
    <httpCompress preferredAlgorithm="gzip" compressionLevel="high">
      <excludedMimeTypes>
        <add type="image/jpeg"/>
        <add type="image/gif"/>
      </excludedMimeTypes>
      <excludedPaths>
        <add path="WebResource.axd" />
      </excludedPaths>
    </httpCompress>
  </blowery.web>

Now, my WebResource.axd is no longer compressed and voila! A nice shiny TextBoxWatermark....

...locally at least. For whatever reason, when I migrated to my server, it complained that the ScriptManager needed to be in a <form runat="server"> tag which I thought it was. So despite all this, that's why you aren't seeing "Enter your search text" in the textbox above.

Hopefully to be fixed soon. When it does, I have a bigger problem because this was the easy part. Adding RoundedCorners (or any extender, for that matter) to the sections in the nav bar, not so much.

Some comments on dasBlog after playing with it for a week.

• No comment spam! Worth the purchase price alone
• Lots of data in the Activity section. I like the clickthroughs because it's helping me find dead links leftover from the .Text conversion.
• Navigating to previous days in the Activity section is kind of a drag. Particularly because it defaults to today's date when you switch from one category to another. And separate dropdowns for Month/Day/Year has never been a favorite navigational construct of mine.
• One thing I miss from .Text: the ability to see all comments in one place. I don't have e-mail set up properly on my server so I'm not notified when comments come in. Luckily, my readership is relatively mute. (update: forgot I changed my password recently. Still would be a nice feature, though.)
• Project is much easier to hack than .Text.
• Just noticed now: Something wrong with the DateTime picker in the Add Entry screen. I think I need to include a reference to the aspnet_client library in my IIS settings for the site.

And finally, converting to .NET 2.0 was not easy but not because of dasBlog. The instructions on this are crystal clear and work fine...provided you have the correct version of Scott Guthrie's Web Application Project. I guess I didn't originally because after several conversion attempts, the web project absolutely refused to convert over as a web application project.

What I did get was a regular .NET 2.0 website with all the string resources moved to the App_GlobalResources folder. Opening the site gave this error:

"Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "newtelligence.DasBlog.Web.StringTables.StringTables.resources" was correctly embedded or linked into assembly "App_Code.el7nt025" at compile time, or that all the satellite assemblies required are loadable and fully signed."

I'm positive this is because, as a .NET 2.0 website, the project no longer has a default namespace so all the string resources were being referenced incorrectly. I'm sure I could have changed the reference in ApplicationResourceTable.cs to remove newtelligence.DasBlog.Web from the namespace but the instructions were pretty adamant that they were correct.

Anyway, removing the Web Application Project and re-installing the most current version worked. There's also a chance that VSTO2005 mucked something up because when I installed the Visual Studio 2005 update to allow the Web Application Project to run, the VSTO2005 installation procedure launched a little sum'n-sum'n first. Regardless, if you get this error, do what I did and all should be fine.

As to why I needed it converted to .NET 2.0, well, that's still ongoing so you'll have to wait.

Sweet Jayzus, how is it possible to migrate from .Text to DasBlog so quickly, so easily, so effortlessly? I had been putting this off for many moons on the basis that it would be a week-long project but here I am a mere four hours later with a fully migrated site. And that includes a break in the middle to watch The Maltese Falcon in its entirety. (Screw Walt Disney. The man I most want to see revitalized from a cryogenic sleep is Humphrey Bogart.) So instead of an ordeal that I should be ranting about in a series of posts over the span of a month, now I'm stuck with this little pit stop of an article that forces me to think of something new to write about.

There were two, count 'em, two minor hiccups during the installation. Firstly, I originally installed the source code locally and used Visual Studio's Copy Project to copy it to my server. Not all the theme files are included as content (nor are all the themes included in the project) so I got an error that took longer to find than it should have. Solution: Copy the entire themes folder (ditto for the images folder).

Secondly, I had to create the content and logs folder in the web's root. I believe the documentation said something to that effect but I only scanned it.

That's it. If you're starting a new blog, there is nothing else to the installation. Just configuration. It was mind-boggling in its simplicity.

Looking through the code was a good experience for me, too. Easy to follow. Some stuff I might have done differently (and in many cases, wrongly). Lack of comments. And the ones that exist are little notes akin to the ones I might write for myself to ignore. All in all, my main thought while scanning it was, "Hanselman *is* mortal after all".

Migrating from .Text took much longer than it should have and here's why: Don't waste your time looking for someone else's solution. I kept running into dead links from posts claiming to have done it already. Even found something on SourceForge that I discovered, upon downloading, is missing a key file that prevents it from compiling.

Instead, these are the only two links you need to know: migrating posts and comments and rewriting URLs, both on Scott Hanselman's site. The first is just as easy as he claims it is and second just plain works.

There is still some work to do with images and local files I've referenced in a couple of posts but the basics are there and ready for indexing by Google. And, of course, this theme is unbefitting a hillbilly of my calibre. Gonna have to downgrade before my audience starts making 'ssumptions about me.