I’m working on a project that partially involves the development of a website in Drupal to act as a directory of people who have graduated from a given University. Seems easy. I went into the project thinking it would be a trivial application of Taxonomies, or maybe some generic CCK fields.

Nope. Turns out the problem is much more difficult and complex than I initially thought.

Taxonomies won’t work, because of the need to tie a number of values together, namely the year the degree was awarded (say, “1992″), the type of degree (say, “BSc”), the specialization of the degree (say, “Zoology”), and the granting institution (say, “University of Calgary”).

That could be an easy thing to solve with CCK - just add four text fields. Done.

BUT - people can earn more than one degree. Of different types, in different years, from different institutions.

Taxonomies fail. Generic CCK fields fail.

What I came up with is a new CCK field type, cryptically named “University Degrees”, that defines the four values that describe a degree. This solves the problem quite tidily, and supports multiple values, predefined valid sets of values, and can integrate with Views to be used as filters and sorting fields.

In building this module, I leaned heavily on a couple of web pages (CCK Sample and What is the Content Construction Kit?) that describe how parts of the module should work, and provided some sample code. In the spirit of contributing back what I learned, I’m going to document the module to help others needing to do similar things.
Read the rest of this entry »

I’ve been struggling with this problem for some time now, and am a bit stumped. Bits of it are trivial to solve, but when I start hooking things up, there’s a pretty big gap and disconnect.

On the surface, it’s a simple problem. I’m using Drupal, and am building a website to store things like profiles for individuals. That’s easy. I need to add lists of the degrees they’ve been awarded. Like this:

D’Arcy Norman

• Bachelor’s of Science, 1992 (University of Calgary)
• Bachelor’s of Education, 1994 (University of Calgary)

Sounds easy. Could just be a CCK content type, with a text field that allows multiple values. Enter whatever text you want.

buuuuut…

I also need for the site to be organized such that I can list everyone who’s earned a BSc in Zoology from UCalgary, or everyone that’s earned a Bachelor’s Degree in 1992, or just people who have earned a BEd from UBC in 1998. Or potentially any combination or permutation.

So, simple text fields don’t cut it. They solve the display problem but not the data modeling and querying problems.

Taxonomies seem like the natural way to store the data - I can set up a Taxonomy vocabulary to represent the full hierarchical structure that is needed.

The problem with a hierarchical taxonomy is that I can’t seem to get it to actually display the hierarchy, with the full lineage shown. On the node display page, I get something like this by default:

First, that shows all terms from all vocabularies. In this case, “calgary” and “ucalgary” are from the Tags vocabulary, and “Bachelors” “Education” and “Science” are all from the Degrees vocabulary. Except they’re all munged together. And the hierarchy is completely gone.

With a bit of custom code, I can separate the vocabularies, like this:

Getting closer. But the hierarchy is still gone. I can’t get it to show something like:

Degrees:

• Bachelors > Science
• Bachelors > Education

The specifications call for the end result to look similar to this:

And there’s perhaps an even bigger problem - I can’t associate a year or institution with the degree. Under this strategy, there is no easy way to say Bachelors > Science (University of Calgary, 1992) and have the data be stored in such a way as to be properly searchable and meaningful as opposed to be essentially for display purposes only.

The other thing I’m hitting my head against is the need to keep data entry as simple as possible. Some really nicely designed forms have been sketched out with ease of use as the primary concern. But they’re going to be pretty darned difficult to implement in Drupal without writing custom modules. If ease of use wasn’t such a big concern, I could probably just use text fields for display so I could enter whatever text I wanted to represent the degrees, and have a set of Taxonomy vocabularies to be used to represent the data for querying and filtering. But that’s redundant data entry, and would be very confusing to anyone actually entering the data.

One other idea I had was to model institutions and degrees as nodes (using a custom content type) and use the node relation CCK field to tie it together. That could work, and we’ve used that technique on other projects (like the Great Teachers website) but I’m not sure that’s the best angle to take in this case.

Any Drupalistas out there with some ideas on how to properly represent multiple bits of hierarchical data to store and display things like sets of degrees granted in given years by given institutions?

I just recorded a (very) quick and dirty screencast to demo the EduGlu sandbox prototype that was put together in Drupal. It’s a 23 minute session, and clocks in at 28 MB. I probably rambled a bit more than I should have, but you’ll get the idea…

(The Anarchy Media Player displays a smallish video embedded on this post, but you can download the video to view at 640×480 if you want to try to read the tiny text in the screencast)

EduGlu Screencast

Download EduGlu Screencast

EduGlu is a concept that came out of some discussions at Northern Voice 2006 - almost exactly 2 years ago - as a way to make sense of an individual’s distributed content in the context of a course. The problem is on one hand very simple - a person publishes a bunch of stuff, and all they need to do is pull it into a course-based resource. On the other hand, it’s really quite hard - how can software provide what appears to be a centralized service, based on the decentralized and distributed publishings of the members of a group or community, and honour the flexible and dynamic nature of the various groups and communities to which a person belongs?

One of the problems I’ve had with the EduGlu concept over the last 2 years is actually a problem that is pretty common in software development - I was overthinking things. By several orders of magnitude. My initial response to EduGlu was to start drafting database schemas, planning out code and applications, and to think about building the perfect course-based aggregator system. This overthinking went on for awhile, with an evolution and streamlining of the schemas and plans for the application. A project was set up on EduForge to act as the repository for the code that would be developed.

I realized that for this concept to be sustainable, it shouldn’t be a custom application. An “educational application” for this wouldn’t work. I started looking at every application as a possible way to implement the EduGlu concept. I played with Drupal and Aggregator2, but it wasn’t quite ready for prime time. I thought, maybe Elgg? Not quite.

Then Bill Fitzgerald recommended a more robust feed aggregator for Drupal, and things started clicking into place. That was back in May of 2006. It didn’t quite work, and wound up getting shelved for awhile.

In February 2007, at Northern Voice once again, the idea of EduGlu got tossed around by a bunch of people hanging out after the conference. It was generally agreed that there was something to the idea, but that it was too nebulous and ill-defined to make much sense at the time. WHAT. IS. EDUGLU? I played with Yahoo Pipes as a possible implementation. That didn’t work out very well. It wasn’t flexible enough, and didn’t provide enough control to each individual.

In May 2007, I started playing with BlogBridge Feed Library. It’s a very cool directory application, and I installed a copy of it on a server to experiment with it as an EduGlu implementation. It worked pretty well, with users able to add feeds to groups, and tag them as needed. It imported and exported OPML, and provided a web interface to view the feeds in case someone wasn’t using their own aggregator. It was close, but the workflow wasn’t quite there - user management wasn’t advanced enough to scale to the size of a large class or institution, and the concept of directories/folders/libraries was a bit inflexible for what EduGlu would need. It’s perfect for a relatively static directory, but for something where students may be adding and dropping feeds on a regular basis, and adding them to multiple contexts, it didn’t quite fit the bill.

Fast forward a few months, and Bill Fitzgerald is at it again. This time, he posts a full recipe for building a flexible feed aggregation application using Drupal and the much more robust FeedAPI aggregation management suite of modules. Very cool stuff. He’s got the aggregation stuff nailed.

Then, I start thinking about how we’ve been successfully using Drupal to power the websites for some active and dynamic course-based communities. The thing that is different on those websites is that they allow members to form their own groups at will. To create, join, and leave groups all on their own, without interference from any institutionally mandated concept of classes or departments. This is enabled by the incredible Organic Groups module for Drupal. Getting closer, but still not quite there.

And then Cole Camplese kicked things into high gear by posting a link (was it on Twitter?) to a site his group worked up to integrate feed aggregation and social rating. It let students rate the aggregated items ala Digg, and that rating data is used to determine importance of the aggregated content.

Bingo.

The magic combination of features for EduGlu are:

Aggregation of feeds + Groups + Social Rating + Tagging

Plugging all of these concepts together results in a workflow that looks something like this:

Students add feeds to the system, placing them in any relevant groups, and tagging the feed appropriately. Items from these feeds are then aggregated, inheriting the feed’s tags and group settings. Students are able to view the incoming content in any (or all) of their groups at a glance, and apply social rating to sort and rank the items - items ranked over a threshold are pushed to the front page of the site. Tag clouds are generated, allowing easy browsing of content. And a full search engine is available, providing some pretty fully featured data mining tools. The aggregated items are archived for as long as needed, and discussion can occur within the context of the EduGlu website rather than being spread across dozens/hundreds of blogs and other applications scattered around the web.

The beauty of this implementation is that it involved no custom code. I didn’t write a single line of code. All I did was integrate a set of off-the-shelf modules for Drupal. This is all generalizable and re-implementable in any number of various ways.

I’ve been monkeying with a Drupal site that looks like it could fulfill most (even all?) of the mythical Eduglu concept - a website that aggregates all feeds published by students in a class/department/institution, and helps contextualize them in the various groups/cohorts/courses each student participates in. It’s getting really close - it can currently suck in all kinds of feeds, auto-tagging items, and even lets students create their own groups and associate feeds with them. There are issues, to be sure, mostly with respect to honouring the original tags in the aggregated items, and with taking advantage of the social rating system added to the website, but it’s so close I can taste it.

At the moment, there are almost 1200 items aggregated from feeds published by 19 users. It’s only been running for a week, so that’s not a bad start…

One added bonus of using Drupal for this, is that I can drop the Tagadelic module into place to generate a tag cloud representing all aggregated items’ tags. Here’s the tag cloud from the current prototype site:

Just seeing that aggregate cloud makes me smile. I’ll have to work on things like adding a group-only tag cloud, and maybe a tag with date parameters (which could be REALLY useful to build a movie displaying the shifts in tag weights over the course of a semester or year…)

As an aside, I’m pretty sure that this is the first post that I’ve added to all of the main categories of my blog: General, Work, and Fun. I’m pretty sure there’s something to that…

I worked with our Faculty of Education to build a community blogging website for use by after-degree student teachers as part of their personal/professional development, reflection, and collaboration process, as well as to collect materials for use in ePortfolios. They had a set of pretty simple constraints. Because the student teachers would be writing about activities in the K-12 classroom, and likely would be posting media (photos, videos, etc…) they needed to restrict access to the site - there could be no public access to this content. Additionally, they needed to control with a fairly fine granularity which individuals within the community would be able to see specific pieces of content. Because of these constraints, we couldn’t just load up WPMU and set them free, nor could we just point them to WordPress.com or Blogger.com. What to do…

Drupal, of course. It’s got a blogging module available out of the box (it takes a checkbox to enable it). OK. Blogging is taken care of. Members just have to click “Create content” and select “Blog post”. Easy peasey.

Want to allow members of the community to create their own groups? Organic Groups. It’s amazingly flexible, and has an added bonus, in this case, of also enabling access control to content based on group membership (after enabling Organic Groups, go to the settings page for the module and enable “Access Control”). Meaning that the student teachers could create as many private group contexts as they like, and then grant access to their content to any of their groups (and only those groups) if desired. Very powerful stuff.

OK. So now we have a bunch of student teachers blogging their brains out. That’s a lot of content to keep track of. Their professors and practicum teachers need to keep up on all of the relevant posts, and provide feedback in a timely manner. How to provide tools to let individuals track content that they’re allowed to see, that they haven’t seen yet, and that they need to respond to… Views. Drupal’s Views module is killer for this. It’s basically a database query generator, where you can provide a set of criteria to filter content, and create a display on the website. So I created a couple of handy views to help people keep up.

The first view was a simple “all content that has been posted to any of your groups, sorted in reverse chronological order” - this is the “river of news” display, which meant that members didn’t have to go hunting through their various groups (some had over a dozen group memberships) to find new content. It’s all merged, sorted, and presented to them on the front page of the site. This let members keep their fingers on the pulse of the community - they could see at a glance what was being published in all of the groups they cared about. This view also displayed the number of comments (and any new comments were flagged) so people could easily follow up on conversations.

The second view was intended to help members keep up with new content - essentially an “inbox” to be used by professors and teachers. This view was a clone of the first “river of news” view, but only displayed unread items. As a professor viewed a blog post, it would get dropped out of this view for them.

We also used the Book module to create documentation on the site (how to use the site, as well as pages with links to other resources, an FAQ, etc…) and we enabled the Forum module to create a separate non-blog discussion board within the site (but this never really got used much…)

That’s really all there is to it - Drupal just handles the rest, and once it’s configured it takes very little care and feeding.

Here’s the stuff we used (the site was built a year ago on Drupal 4.7, but I’m listing what would be used as of the current Drupal 5.3):

• Drupal 5.3
• Organic Groups module
• Views module
• LDAP Integration module (current 5.3 branch borks on UCalgary’s LDAP, so you might have to play a bit)
• Insert View module (for embedding the views on the front page)
• TinyMCE module (for a rich text editor while creating/editing content)
• Anarchy Media Player (non Drupal - add the Standalone JS version as a block in your site theme’s header and all media will be embedded automatically)

I’ll try to revise this post to clarify stuff as needed, but this is the basic recipe. The best thing to do is just start downloading and playing…

We use the Events module to manage workshops here in the Teaching & Learning Centre, and use the “Upcoming Events” block to display the next few workshops on our website. Works great, but the default text leaves a bit to be desired. By default, it shows the event title, and “(2 days)” - which indicates that the event begins in 2 days.

But, it could also mean that the event lasts for 2 days.

So, I just added a trivial change to the event.module file, adding the following line of code at line 1847 (on my copy of the file, which was checked out on June 4, 2007):

$timeleft = 'starts in ' . $timeleft;

That changes the text indicator in the “Upcoming Events” block to read:

(starts in 2 days)

Which is much clearer in meaning. Easy peasy. I just have to remember to edit the module after updating, if this doesn’t make it in…

I had to debug our TLC website this morning, as it was pointed out to me that parts were misbehaving, and that some content hadn’t survived the upgrade from Drupal 4.7 to Drupal 5.2. The missing content was easy, for the most part. It’s just a matter of renaming the tables to use the content_TABLE format expected by the current CCK module. The exact table names that are expected are listed in the node_type table, under the “orig_type” field - just prepend “content_” to the “orig_type” value for the table name, and CCK should find everything just fine.

One of the CCK content types used the weburl field type under Drupal 4.7, but this has apparently been replaced by “link” in Drupal 5’s version of CCK. That’s fine, I’ll just swap out the data. Shouldn’t be too bad.

What got puzzling, though, was that after switching to link, I was getting segmentation faults on the webserver every time I tried to view, save, or template a CCK content type containing a link. WTF? At first, I didn’t make the connection that it was link that was causing problems. Eventually, I created a “test” CCK content type, containing the same fields as the offending content type (every time I tried to view anything in our “Simple Resource” content type, hell was unleashed). I reproduced the same set of fields, and BOOM, Simple Resource was also bringing down the server. So, I started removing fields. Didn’t take long, since the content type had a total of 2 fields. I started with the Link field. And the content saved, viewed, and templated just fine.

AHAH! It’s something wrong with Link! Maybe it’s trying to validate the URL? Maybe it’s trying to download the content at the other end of the URL to do some processing?

Nope. Turns out, Link may use the token.module to parse out bits of the URL. But token.module was getting caught in a recursive loop. I had to install token.module to support the current version of pathauto.module - I need that, so I can’t disable token.module. Turns out, there’s an easy way to avoid this recursion-killing-the-webserver segmentation fault problem. In the CCK definition for the link field, just uncheck the “Allow Tokens” option. Yeah. It’s that easy. But it took me all frigging morning to figure out what the problem was, and about 5 seconds to fix it once it was identified.

Links that were useful in diagnosing and solving this:

• Infinite Loop with Link + Token
• content_view() not recursive safe
• Token module causes segmentation fault (this was the solution - see comment #4 on that page)

In the Teaching & Learning Centre, we run a couple of servers, each with a dozen or so Drupal sites installed in a multisite configuration (one copy of Drupal, using the sites directory to respond to various URLs). With every update to core or modules, the update.php file needs to be called for each site. That’s not too onerous, but is a bit of a PITA.

Our central IT shop at the University of Calgary has a whole ‘nother problem. Their Drupal server is currently running well over 400 sites. So, calling update.php on each one effectively means having a bunch of folks (students? interns?) clicking through the update.php screens for each site. Say it takes maybe 5 minutes per site, that’s over 30 hours of labour to update all sites. And new sites are added every day.

There has to be a better way. I was hoping Sympal Scripts had some magic fu, but came up empty. Are there any secret tricks to calling update.php on each site quasi-automatically for a large-scale Drupal multisite installation?

Our main Teaching & Learning Centre website runs on Drupal, with extensive use of CCK, Views, Events and Signup modules. The site had been running on the Drupal 4.7, with only security patches applied. But it was starting to act up (content was suddenly not showing up), so I decided to pull everything up to the current 5.2 line, with updated modules. It’s an easy enough upgrade. When it works.

The CCK update appears to have really botched things. As in, most of our custom content types are now missing data for several of their fields. The data’s safe - I can see it in the database - but it’s not showing up when viewing or editing the nodes. Annoying.

So, my task over the next couple of days (hopefully much shorter than that) is to debug wtf went wrong, and figure out how to manually upgrade the various CCK database tables from wherever they were to where they need to be for 5.2. Fun stuff.

Also, the embedded Views have decided to go TU, so I get to debug wtf is going on there, as well.

Thankfully, I have backups of the data, so can play a bit if needed, but I need to leave the main site up and live to support workshop registrations while I fix things. It’s taken much of today to get the site to the state it’s in now. Haven’t even had a chance to check all of my feeds yet. The horrors!

I may need to dig up one of those circa-1995 “Under Construction” animated GIF images for the site in the meantime…

Update: Thanks to a tip from Webchick, I got the CCK tables manually reconstructed. All I had to do was rename the tables as per the pattern described. It looks like the 4.7 - 5.x upgrade path for CCK got really complicated, and may have been overlooked. My Drupal 4.7.7 site was fully patched, all modules were up to date, as was core. Upgrading from a fully patched 4.7.7 to 5.2 just plain didn’t work, from the perspective of CCK. Turns out it was a pretty easy fix, but still, a bit annoying. Huge thanks to Webchick for the tip. It’s amazing just how active and helpful the Drupal community is.

My last big issue is wrt embedded Views in several nodes. They appear to be ignoring arguments (but not all of the views are misbehaving, making it a bit harder to diagnose). That’s my task for today, to get the rest of the site behaving properly. Then to fix some layout issues that are unrelated to the Drupal upgrade (the UCalgary theme we had been using was a 4.7 variety, and the 5.0 variety has subtly different css, and lacks our custom stuff).

I screwed up in a big way on one of our higher profile Drupal sites. I had configured the default inputformat to include PHP execution, because there are a whole bunch of pages on the site that need to be able to execute PHP, and that was the easiest way to get it done. I was lazy, and didn’t follow best practices. And it resulted in a pretty open security hole, where anyone could create an account and then execute their own PHP (to do stuff like promote their account to Admin, delete the database, send emails, launch ICBMs…). Not cool.

Why was I so sloppy? Basically, I forgot that I’d left user registration open. The site is supposed to be a closed ecosystem, but with user registration enabled, it ain’t.

What I should have done was create a separate “über-inputformat” that included PHP execution, and was only available to admin users on the site. I would then have a separate, more limited inputformat as the default, perhaps with html tag filtering, as well. But here’s where I got lazy - there is no way for me to say “I know that ‘n00b’ is the default format, but I only ever want to use ‘über-inputformat’ so don’t make me choose each and every time I create a node”. Having more than one inputformat available causes the display of a new “input format” control in the node authoring form, and users have to first understand wtf that means, and then they have to figure out why they’d want to choose any of the available options. And if you’re creating a whole bunch of nodes with PHP in them, you have to remember to change each and every one to the “über-inputformat” inputformat, or the code won’t execute. pita.

Which brings me to D’Arcy’s Drupal Pet Peeve #2: Loose inputformat control. You can say which is the default, and then EVERYONE gets to use that. Then, you can add on other additional and optional inputformats, and enable them only for specific roles. But you can’t say that “n00b” is the only available inputformat for anonymous and authenticated users, and that “basic” is the only available inputformat for “members” and that “über-inputformat” is the inputformat to be used by default by admins.

As a corollary to Pet Peeve #2: TinyMCE ignores inputformats. If I have an inputformat configured with PHP execution, TinyMCE is completely happy to try to provide an editor for that, obliviously clobbering the code within the node. You have to go to your account and (temporarily) disable TinyMCE rich text editing before editing any node with PHP in it. It’d be really nice if you could tell TinyMCE to NOT kick in on certain inputformats…

I hate that I have to manually (or scriptedly) call cron.php for every Drupal site I run. Even for multiple Drupal sites on the same server in a multisite configuration. Yes, there are ways to automate it, but eventually they fail. I just manually called cron.php on one of our main sites, after realizing it had silently failed for the last 32 weeks. Hundreds of reminder emails are being sent out now, for events that were held months ago. Yes, there are modules to have cron.php called periodically (poor man’s cron…) but they’re flakey at best, and risky at worst (there is a chance of overlapping cron.php calls if the timing is just right).

Anyway, there endeth the rant. D’Arcy’s Drupal Pet Peeve #1: cron.php

I was just in a meeting with some folks in our campus IT department, where we were trying to figure out what the official University of Calgary supported podcasting solution would be. We were basically trying to decide if we should jump onto iTunesU in a big way, or roll our own service.

iTunesU is a really strong choice, in that all of the infrastructure bits are handled. No drive space to worry about, no backups to remember. Everything just works.  But, it’s outside of our control, and is rather  strongly Apple-branded. Even though it’s not an exclusive arrangement, and the content can/should be in multiple formats, it’s hard to sell that combo to people who are either

1. still thinking of locking content within Blackboard (i.e., iTunesU is too open)
2. wanting to adopt Open Source (i.e., iTunesU isn’t open enough)

Which left us with our second option: roll our own service.

So, over the summer, we’ll be putting together an official campus podcasting solution, hosted using Drupal essentially out of the box (but we’ll eventually add modules like Audio.module, Views, CCK, etc…)

One thing that really impresses me about how our IT folks approach problems is that they don’t react with fear. When we were discussing authentication and restricting access, things that are offered by iTunesU, the response was “we’ll figure that out, and here are some ideas of how we could do that…”

We’ll be, er, inspired by the podcasts.*.edu/.ca websites that are already running. Despite what the press release says, UCalgary is not the first, nor the biggest, podcasting institution…

I migrated my blog from Drupal 5 to WordPress 2 nearly 2 weeks ago. The process wasn’t as painful as I thought it would be, thanks to a handy howto via vrypan.net. Another resource I refer to every time I get into tweaking MySQL rows is UrbanMainframe’s MySQL search and replace tipsheet. Thanks to both of these great resources for helping me through the migration.

This guide is intended only to document what I did. It’s not a polished howto or manual. There is no warranty. If you blow up your database because you didn’t work with offline backup copies, I won’t be able to help you. Actually, if you’re that silly, I won’t be willing to help you, either. Your mileage may vary.

Use a backup copy of your Drupal database, and a fresh WordPress database.

The basic process I followed was:

1. Work from offline copies of the databases. Dump your Drupal 5 database, import it into a fresh database (say “drupalmigration” or something creative). I did the migration on a separate machine from my “live” server - I used my desktop box, with local copies of MySQL and Apache. Anything with a decent version of MySQL on it will do.
2. Install WordPress, (you don’t need to install Drupal for this migration) using the same database server containing the copy of your Drupal database (use “wordpress” as the name of the new WordPress database).
3. Now that you’ve got WordPress and Drupal running on the same database server, in separate databases, run this MySQL script which I modified slightly after the file provided by vrypan.net. The script assumes the WordPress database is called “wordpress” and the Drupal database is called “drupalmigration” - feel free to modify the script to match the database names you need to use, if they differ.
4. That should do it. Log into your WordPress site. You might have to hand tweak the usernames, but all posts and comments should be there…

One additional thing I had to do was fix the comment_ID values in the wp_comments table. After migration, they were too big for the data type, and things went poopy. I’m sure there’s an elegant way to renumber rows in MySQL. I used brute force, by dumping the table to a .sql file and opening that in a text editor to do a search-and-replace to lower the numbers used as primary keys. I then moved the old table out of the way (renaming it to “wp_comments_old“) and imported the new wp_comments table definition and content. It was a funky thing to have to do, but it solved all kinds of comment-related misbehaviour.

Test things out in the migrated database. If all seems well, go ahead and dump the wordpress database to a .sql file, and import it into a new database on your server. Install and configure WordPress on your server to use this new database. You may need to manually change the URL used by the blog, so that it matches the “live” server rather than whatever you used as a staging/migration server. The values are in the wp_options table, with option_name of “siteurl” and “home” - change those values to whatever matches the root URL for your blog.

You’ll also have to make sure all files are in the proper place, so URL references from the old Drupal content doesn’t point off to 404 error pages. That’s an exercise left to the reader. I just SSHed into my server and used a lot of cp -R drupal/directoryname wordpress/directoryname - being paranoidally careful to copy files rather than just moving them. Always keep backups.

Update: I’ve updated the SQL script to automatically set the comment and category counts, so it should appear to work better now.

I’ve been using Drupal for my blog for just over a year now, and it’s been a really great platform to work in. I use it pretty much all day for projects at the U of C as well. But it just feels a bit lacking in the area of managing a personal blog, compared with WordPress which is built solely for that purpose.

I’ve been missing things like email subscriptions to comments, and some of the other niceties that WordPress has had nailed for a long time, but are missing in Drupal.

So, if you can read this, it worked. But things are going to be messy for awhile while I finish tweaking stuff. If anyone knows the quick easy SQL to run to recount all comments for posts, to properly set the value of wp_posts.comment_count I’d appreciate it. All comments are properly in place, but they don’t show up in the comment count indicator until/unless someone posts a new comment on the blog entry.

In the meantime, all static pages (including About, Contact, Links, etc…) are borked. I’ll fix them up as I have time.

Update: Lovely. Looks like new comments are being rejected here. wtf. worked fine in staging before moving here… A blog without comments. Good thing I left Drupal…

Update 2: Things are pretty much up and running. I’ve added a bunch of modules, and will start playing when I have/make time. Overall, I’m pretty happy with it. I miss some of the power of Drupal, but am liking the simplicity of WordPress.