Since last weekend, I spent my evenings manually moving content on deninet. It many ways, it was an exhausting process, but it gave me something to do while I suffer through the last two seasons of Star Trek: Voyager. Let me chart how I arrived at this point. 

Over vacation time in December, I decided to conduct a little experiment. I would attempt to upgrade the current deninet website from Drupal 6 to Drupal 7. When I had attempted this a year ago, it did not go well. The upgrade process crashed spectactually, leaving me with a lump of a database. Thankfully I was doing this on a local copy, and not the live site. I had speculated that in the interviening year, Drupal would have ironed out a lot of the edge cases I originally ran into. So, I copied off the site and tried again. To my astonishment, it worked. 

This created a dilemma. The previous year I had created a new deninet website by manually copying content from the version based on Drupal 6 to the new one based on Drupal 7. When all the features I needed to run the site were available, I'd switch to the new site. I had maintained the D7 fork from time to time, manually importing nodes and to make sure the two sites where in sync. At the time, this seemed the best way to go. I would lose things like comments and break all the URLs, but the end would be a good move. 

Except that the new site never seemed to get anywhere. 

I had reservations about the URLs and the comments. While I could bury my feelings, claming it was for "the greater good", it still bothered me. There was the bigger issue that I really wasn't getting anywhere with the D7 site. It sat and languished, while I couldn't resolve the issue. 

After successfully upgrading the site, I began to wonder if I could take a more fluid approach. I used Pathauto to create URLs that would be the same for both the current D6 site, as well as a D7 site -- upgraded or new. The biggest problem was images. 

Yesterday I took the opportunity to poke at the production version of deninet -- version 6. While there wasn't anything to fix, the site has certainly seen a lack of maintenance since I put my eyes on deninet7. 

First off, there were several modules that were enabled, or simply installed, that weren't being used. Given my recent explorations into Drupal's guts, I've learned an enabled but unused module equates to wasted instruction cycles. I pulled out the modules, and cleaned up what small gaps that remained.

Then I started poking at a few other functional components. First off, the former FAQ section. It was a half baked idea when I conceived of it. The idea was that if questions were submitted, we could create a vote-sequenced knowledge base for site use. Not a bad idea, but one that does not work with a user base of three or four. I deleted the content that needed deletion, and moved the remaining post to a back-dated blog entry. Later, I may move it again to another content type depending on long-term plans.

The removal of the FAQ section allowed more modules to be removed, leaving me to wonder what else could be done. I killed the link to the deninet cafepress store, since that was another silly, half-baked idea no one used. The next idea I had was to look at the Springboard. The Springboard was meant to be a dashboard of subscribed deninet activity for registered users. For the most part, it does what sets out to do. Unfortunately, you need to specifically visit the Springboard by going to deninet.com/my.

Other websites with similar functionality skip this step altogether. They dynamically change the home page to be different depending on if you are or aren't logged in. I quickly found the ability to do this within Panels, and merged the home page with the Springboard. I also added blocks to the sidebar using similar conditional logic. It's rough, but it requires a little less thinking now.

By the time I finished setting that up, it was already quite late. I began to wonder what would happen if I tried to upgrade deninet6 to Drupal 7 in place. Originally, I created a forked version of the site that broke all the URLs. I spent most of Christmas vacation last year duplicating all the posts into the new forked site. A lot of editing to said posts happened in the process. The biggest change was reorganizing all images into blog post-bound galleries, and into "Creations" -- a new content type -- for all pieces of artwork. 

Upgrading in place would maintain the URLs for content as they are today. It wouldn't, however, deal with the editing of posts, or correct some of the rookie mistakes I made when setting up deninet on Drupal 4.7 years ago. The upgrade process itself also looks frightfully painful. I plan to give it a try anyways just to see how painful it is on a development server. Keeping URLs may not mean much any more in the age of search engines and human-readable URLs. Still, I want to find out.

I've never been particularly good at taking vacations. I've become particularly bad at this in the last two years as my job and private life have become hectic. The last week summerizes this well.

While last weekend I busied myself with errands and visiting a friend to watch movies, when Monday came I found myself unsure what to do with myself. I decided to try to work on some patch code for the Organic Groups Dupal module. Unforunately, the developer and I seem to have an impasse about how to develop a particular feature. When I started working on implementing it, I discovered that it wasn't in mind with the bigger picture of the module. I stopped working on the code, feeling embarrassed and more than a little self-conscious. 

I don't remember much of Tuesday. I'm sure I played Halo 3 for several hours that day, but all I can really recall is generally being in a really rubbish mood for most of the day.

Wednesday was better. Pazi and I set out to run some errands including going out to lunch and buying her a new phone. I came home feeling much more accomplished and deserving of some relaxation. I got really frustrated with Halo (the first game), but eventually I calmed down and worked through it. What followed was a lovely little evening involving gluten-free pizza and Fugitive Alien. 

Today, Thursday, has been perhaps the most vacation-like day this week. Pity it only took me three days to get here. Most of the morning was Halo, with a dash of Futurama at lunch. This afternoon was gelato at a local coffee shop. I have designs on roast salmon for dinner, along with a watching of Lathe of Heaven (PBS version), and yes, more Halo. 

I should try my hand at more Drupal coding this evening. Despite my embarressment at the beginning of the week, it's best to dust myself off and code something. I'd love to write some Rules code that will set or unset permissions when a group of a particular content type is created. That'd solve another issue for me with deninet 7. 

Yesterday I decided enough was enough, and I set up a new web server on Linode. 

We've been looking at switching our hosting provider for some months now. Dreamhost never supplied enough processing power for Drupal's intensive database needs. Instead of investing with Dreamhost PS, we instead moved deninet to a VPS that we share with a friend's websites. We're now planning to reverse the arraignment -- have her share our space.

Both as a test and as a matter of conveinence, I uploaded the development version of Deninet 7 to the new server. As one might expect, the new site is....unfinished. There are a lot of planned features we need implemented prior to cutting over. Blog posts need access security enabled. Workspaces need to be created. There's a whole host of Views and configuration that needs to occur before the site is even close to ready.

The problem is, the clock is ticking.

Every day, our members at deninet make posts to their blogs, to book pages, and other content. Each of these pieces of content need to be copied and pasted into the new site as there's no advanced integration between DE6 and DE7. As of this moment, there are months of backlog I need to copy and paste into the new site. Don't get me wrong, I don't want our members to stop making posts. By all means, continue doing so! 

The consequences of waiting to cut over to the site rest with me. The longer I wait to make sure the new site is "feature complete", the more work I need to do to maintain two versions of the site. At some point, it just seems like a waste of time. I could continue to work on the new site, in private, hacking away at what features I think we need until the new site is polished and perfect, or I can accept that the entire process will be ugly and painful. 

Accepting the process will be ugly and painful leads to a complelling way forward. When a website undergoes a major redesign, it is often available internally for company employees or users to provide the vital feedback necessary in order to make the site work the way everyone needs. We're not a company, and we certainly don't have what's necessary to make an "internal site" work. I've tried it before, but it usually ends up being ignored by our most regular users, leaving me to guess what we need.

I don't want to do that this time. 

Instead, I propose that as soon as we have one feature implemented -- blog post security -- we cut over to the new site. No waiting to perfect or even start other features. No custom theme design. Nothing but the bare minimum to start. Why do this? For one, it minimizes my work. I will only have one site to administer after that post. Furthermore, everyone needs to use the one, unfinished web site. This way we can develop new features in the open, with everyone involved. Point of fact: I need feedback to get this right. Using the new site when it's not finished is the best way to get that feedback and change or fix features before they become entrenched.