Site update to Graffiti
WARNING: This is really long and most likely boring to most people. I’ve posted in just in case someone else is migrating their Community Server site over to Graffiti and runs into the same things I did.
I was sick last week and missed quite a bit of work. This weekend I was supposed to go to Mammoth Cave with the in-laws but was still recovering (and no, it wasn’t an excuse. I like my in-laws). So, with the house to myself and not feeling really well enough to drive anywhere I decided to upgrade my site from Community Server 2.0 (CS) to Graffiti CMS 1.0. I’ve a project on my list to update my site for quite a while so about two weeks ago I pulled down Graffiti to see if I’d like it.
First let me say that I can’t complain much about CS. I’ve used it for about three years now and it’s been great. My only issues with it were the upgrades that seemed to take forever and often required hand tweaking sql scripts or knowing which errors you could “safely” ignore. The big issue was the CS was MUCH more than I needed for my personal site. I used the photos feature for quite a while, but then a few months ago moved over to SmugMug. That left really only my blog and a few download files on my site. The download capability let me know how often something had been downloaded, but I eventually just stopped looking at that anyway. So, I decided that CS was too big for my little site and started looking around.
Graffiti peaked my interest and after I played with it a little while I really liked it. I thought this weekend would be a great time to site down and do an update. Kudos to the guys at Telligent for the use of the canned Web Developer Web Server to let you try out Graffiti even without IIS. There is an executable you start up that starts the WebDev server and opens your browser to the local instance of Graffiti. You can try out the product without much more than unzipping the download and running an executable.
Well, the migration has eaten much more of my time than I would have liked. I’m glad the family isn’t here. Most of the time loss is my own fault, while some of it is related to troubleshooting issues during the deployment.
First up, last night I looked through the available themes for Graffiti and decided (for some stupid reason) that I wanted to build my own from scratch. So, I read some forum posts and looked at the theming capabilities. WOW. Much nicer than CS 2.0 was and even nicer than CS 2007 in my opinion. I have a complete theme with only seven files (three of those are images). Of course, this took most of my time last night since my memory of CSS was very vague and I was often scouring the search sites for CSS tutorials on how to do things. I did find a cool color wizard site which lets you enter a color code and get some complimentary colors to use for your web site design. Very helpful for someone like myself who can’t pick out complimentary colors on their own. The header image was from a picture I took at the Cincinnati Zoo. I thought the phrase Application Simian went well with it.
To make sure I didn’t screw up my live site I requested a database backup from my hosting provider. I setup a local instance of Graffiti and started walking through the migration process. Out of the box Graffiti uses VistaDB as it’s data store, but also supports several others. I choose to continue to use SQL Server as my data store since that is what I used with CS. I have lots of existing posts I needed to use the Migratory tool that also comes in the box. I ran into several issues with the Migratory.
The first issue I ran into with the Migratory was when I attempted to import my posts I received an that the input string was not in the correct format. I ran out to the Grafitti CMS forums and found that this was a known issue. The fix was to make sure you selected a category when you imported. Hmmm, I looked at the Migrator screen and didn’t see a category dropdown. The table displaying the posts was wider than the browser window and there was no horizontal scrollbar. I opened the actual aspx page for the migrator and saw that there indeed was a category dropdown, but it was just located off the visible screen. I altered the aspx page to put the category dropdown in an area I could see. I then ran the migrator again.
The second try at the Migrator brought up a different error. This time it told me that the field ‘SpamScore" was invalid or some such nonsense. This prompted me to check the CS version I was running on my existing site and noticed I had 2.0. CS 2.1 is the lowest CS version the migrator supports. I pulled the 2.x to CS 2007 upgrade SQL script out and ran it against the database. That cleared up the SpamScore issue.
The third try at the importer brought up another issue. This time some of the posts were flagged as failed with an error saying that the default.aspx page (the one for the migrator) was in use by another process. What the?! I look at the code. It’s doing client side work and making ajax calls to perform the migration. As for what the heck is locking the page, or why that even matters I have no idea. I see where they are simulating a thread limit in the client side code and set that to be single threaded. It took longer but I no longer got the odd error. SIDE NOTE: no one on the forums reported this as a problem. I first thought that it was because I was testing it using the WebDev (that only takes a certain number of simultaneous requests, so I switched to hosting locally in IIS and still got the issue).
So on the fourth try the Migrator moved all my posts and comments successfully in my test SQL database. Yeah! (or so I thought). My next move was to figure out how I was going to handle all the redirects from my old URLs and permalinks to the new scheme Graffiti uses. I found two options in the form of Graffiti Plug-ins: one from James Avery and one from Rich Mercer. James’ was a more general purpose redirect plug-in that worked with configurable Regular Expressions and the one from Rich was more specifically to handle CS migrations. After some playing around with them I decided on the one from Rich; however, I had a problem.
Several times in my migration practice runs the Migrator reported it failed to import a post. It actually did import the post, but then failed to pull in the comments. When I re-ran the Migrator again against the supposedly failed posts it would pull in a duplicate. Nice.
It seems that when the Migrator runs it pulls the “postname” value from cs_posts and uses that as the ID of the post in the url. For example, my post on the review of the LS800 had a postname value of ls800 so the next post would be found at http://example.com/blog/ls800. If the Migrator found that the postname value was NULL it simply tried to create one by stripping the subject of the post of spaces and illegal characters. The problem stemmed from the fact that CS (2.0 at least) would use the actually ID from cs_posts for posts that had a null postname. So if your postname was null your permalink would look like http://example.com/blogs/blog/archive/2008/02/02/1234.aspx where 1234 was the ID of the post in the cs_posts table. Well, since the Migrator was nice and gave all my posts names none of the permalinks would have worked even if the redirect plugin was there. Great. It took about an hour and half to figure out this issue but only about two minutes to fix it. I created a script that updated all the postname values in CS 2.0 that were null (and were for my blog) to be the PostID value. I then made this a step in my migration prior to running the Migrator utility.
So now after about five hours and multiple restores of my test database I finally had my migration plan nailed down and thought I was ready to go. I started making my changes and got to the part where I had the new web files in place on the live site and it wouldn’t come up. I kept getting the “some error happened here and you need to turn Off custom errors to see it” screen. So I updated the web.config to turn off the custom errors, but it kept telling me the same thing. Odd. I then remember that my site has been stuck in ASP 1.1 running CS 2.0 and wasn’t set to ASP.NET 2.0 yet! DOH! This is a 5 second change if you have access to IIS, but on a hosted site it apparently can take up to 24 hours (odd).
I found on my host control panel where I can update this and it requires a hosting plan change! Not just flip the switch but a full plan change! No cost difference associated, I just have to run through the plan change. While doing this it stated I couldn’t use the new .NET 3.5 plan with the SQL Server I had. Turns out that my DB was a SQL 2000 and not 2005. Nice. So I go through the steps of updating my SQL Server per the instructions in the KB. Relatively painless. But now, as I write this paragraph, I’m still waiting on the plan request change to go through. Oh Well. I’ll wrap this up once the site is back up and I can post again.
//Many hours pass//
So it took about 20 hours for the hosting service to move the web site from their servers that handle .NET 1.1 stuff to their new .NET 3.5 servers. Hmmm, seems a little odd to me, but hey, I’m not familiar with their infrastructure. Anyway, as soon as the site was moved Graffiti came up immediately!
After the site was up I tested the redirect for the permalinks and those worked like a charm; however, the RSS feed url was NOT redirected by the plugin. DOH! I quickly put up James’ plugin and using a regular expression redirected the RSS url as well. Now I’m using feedburner!
So, the site is now up and running again. Things should transition nicely, but if you run into any dead links or something please let me know.
Things to suggest for your migration:
- Double check all of your post contents in CS prior to the migration to make sure that if they make reference to any files, images, or pages on your site that those will exist or have redirects ready for them. I had a few images that I had to ensure made it to the new site. Get a copy of your existing CS database and run through the migration multiple times. I think I restored and ran through the migration a total of six times before I got a clean migration and trusted the migration to attempt it on my real data. Note that when I ran the migrator for real I still had it limited to a “single thread” for the updates so it took a while, but all 539 posts came over correctly, complete with comments. Once you get a test instance migrated make sure to test your redirection plan and mechanism to ensure your permalinks will still work. The issue with the postname being null and the post ID not being brought over caught be by surprise and I’m glad I found it in my test migration.
Overall I really like Graffiti and I’m looking forward to expanding my site a little to include new pages and content. I like the fact that I can add pages and content on the fly without having to FTP files. Another benefit is that my SQL storage requirements dropped tremendously. With CS 2.0 I had a SQL DB footprint of about 90 MB. With Graffiti it’s about 10 MB.