The WGBH.org Development Blog

One of the great things about open source software is, obviously, that there are all of these great people out there writing code and making it available to everyone. In the world of Drupal this means that there are tons of great contributed modules that are pretty much invaluable to a site like WGBH.org, like Views and CCK.

It also means that those of us who have to maintain a Drupal site need to keep up with the improvements and changes to all of this code by periodically upgrading the code bade. Often times this usually just means grabbing the updated code and running the upgrade script. Things usually go pretty smoothly.

Except when they don’t.

Take, for example, the other day when I saw (thanks to the CVS Deploy module) that there was a new release candidate version of CCK (from 6.x-2.0-rc6 to 6.x-2.0-rc7). I went ahead and grabbed the new code and ran the upgrade script against my development installation (don’t want to do this on the live system!). Then I checked out our TV schedules grid and it looked like so:

Using my years of web development experience and my highly developed technical acumen I quickly deduced that something was wrong! The quesiton was, what?

So I went to the issue queue for CCK and found that, indeed, the latest RC version of CCK required the latest development version of Views.

OK, since I’m reluctant to use development snapshots of modules, I figured that there would probably be a new RC version of Views coming out soon with the required fixes to allow CCK and Views to once again play nice together. Sure enough, in another day or two there was a new version of Views (6.x-2.0-rc1 to 6.x-2.0-rc2). I then upgraded Views (again, on the development suite) and got this:

Hmmm. Better, but still not quite right. Basically, there seemed to be a problem with passing in date arguments to the view used to generate the schedule grid; there was a similar problem with the full day schedules.

Soooo, I then went to the Views issue queue and, sure enough, found out there was a problem with the new RC release of Views and it’s interaction with the Date module. Namely, that the date filters normally available to Views were now missing, which is what I saw.

Once again I figured that, rather than go to the development version of Date, I’d just hang tight and see if a new RC of Date was released soon. Bing, bang, boom - the next day it was! After then upgrading Date from 6.x-2.0-rc2 to 6.x-2.0-rc3 (and also upgrading Views again, as a new RC was released in the meantime, to 6.x-2.0-rc3) and checking the site I saw…. this!

Whew! Everything was back to normal.

The lesson here? Some might look at this and say, boy, what a pain in the rear this open source stuff is! But not me. On the contrary, I think it demonstrates the greatness of open source and the community of people out there responding to problems, fixing bugs and generally making my life much easier. Sure, patience is sometimes required, but that’s a very small price to pay, in my opinion.

So, a big thanks to all the folks who build Drupal and Views and CCK and Date and all of those other modules! Well done, folks.

The new WGBH TV Programs and Schedules module has been up and running on Drupal for almost a month now and - knock on wood - everything is working great! In fact, things have been going so well, operationally, at least, that all has been … quiet!

Quiet is good.

Now that this phase of the project is all done we are turning our full attention towards the real goal: porting all of WGBH.org to Drupal and completely overhauling the information architecture and user interface. We’re currently busy doing content audits, wireframes, schedules and all that sort of fun site redesign stuff. Nothing is ready yet for actual development.

In the meantime, we’re also addressing a few small desired functionality changes to TV programs and schedules that we chose not to address during the build. At the top of the list is the way that we generated the list of related (i.e. You might also like) programs on our episode pages.

Currently, this list is generated automatically using tags applied at the program (series) level. We developed a simple TV Program Genre vocabularly to potentially apply to each program.

Content producers ultimately have the ability to override the automatically generated list if they like, but, for the most part, what you see is generated on the fly based on the tags.

The upshot here is that by only applying tags at the program/series level, each episode of a given series (e.g. all NOVA episodes) will display the same set of related programs. So while NOVA may generally be a science program, a given program may be focused on, say, a physics problem, but this isn’t reflected in the related programs list. Our tagging scheme doesn’t currently allow us to relate programs on a more granular level than the simple genres we’ve defined.

Initially, we had planned to support tagging at the episode level for the initial build for use in generating the related program list. However, when we sat down to hash out how it should work it quickly became clear that using tags at both the program and episode level made things far more complex.

For example, right now, with tags only at the program level, it’s pretty simple. On a given episode page, we fetch the tags on the parent program, then using a view, generate a list of other programs with the same tag(s) and display three of those. Easy-peasy!

But once you throw episodes into the mix you now have to make decisions on issues, like, do matches on program or episode level tags count more? Should we weigh episodes with matching tags that are part of the same series more - or less - than similarly tagged episodes from other series? Etc and etc.

So, we tabled the issue for the first release and just went with program level tags. Now we want to start tagging episodes and come up with rules to generate a more granular list of related programs. That’s something we’re hoping to work out this week.

Have you run into a similar problem? Any thoughts on how best to do this? Speak now!