The WGBH.org Development Blog

Apologies to all of our loyal readers who were disappointed by the lack of a post last week (that’s you mom!). See, I was on a family vacation at an undisclosed location working on my farmers tan and spending just about every last cent we had in the bank to entertain the wife and kids.

It was a good time that unfortunately had to end, so now this week I’ve been back at it, closing in on the launch of our new TV Programs and Schedules module. Whilst I was gone Pete was busy fielding bug reports and questions from our testing team. The good news is there seem to be relatively few actual bugs. The code is pretty solid and we are plowing forward getting the production environment ship shape in preparation for launch!

However, that does not mean we are without issues.

One issue that I knew would come up eventually has already come to the surface, a bit earlier than I had figured on. It has do with modifying published content and previewing pages that contain information from multiple nodes, like our episode pages, for example.

See, our current site and CMS have lots of flaws and unsightly blemishes, but one thing it is good at is allowing content producers (CPs) to create multiple revisions of a page or content item, publish one revision and continue to tweak the content without overwriting the published version until the appropriate time. Also, our current site has very sophisticated previewing functionality, allowing CPs to preview just about any given page to see unpublished changes, including the ability to preview by date, showing what the page will look like at a future date, based on scheduled publish and expiration dates for content items.

Know what I mean?

Drupal, natively, doesn’t seem to do either of these things particularly well. Or, if it does, I still haven’t figured it out. Oh sure, you can configure content types to allow multiple revisions, but all that really does is archive earlier revisions of a node, in case you want to roll back later. That’s good, don’t get me wrong, but what we need is the ability to publish a revision, then create a new revision that isn’t published until we say so. We can sort of use the current functionality to do this. You could publish a node, update it and create a new revision (which immediately publishes the new revision), then revert back to the original revision and roll it forward when we want the new revision to be live. However (a) that’s an annoying number of steps and (b) you can only edit the currently published revision. Not so useful.

I recently played with the Revision Moderation module, which gets us closer to what we need. Basically, that module will create a new revision for you without publishing it until a user with the proper permissions chooses to. However, we’ve decided not to implement it now because the code for Drupal 6 isn’t even in alpha state yet and also because there seem to be issues with one user seeing the unpublished revision created by another user, etc. etc.

As for previewing, our new episode pages are fairly complex and draw on content from multiple nodes and content types (e.g. program descriptions, episode info, related content boxes, etc.). The problem they’re having is that they need to modify some pieces of content on a published episode page and, in doing so, need the ability to preview their work in the context of the page in order to get the layouts right. Right now there is no easy way to do that. The preview functionality provided by Drupal on the node edit pages is fine, but it doesn’t allow CPs to preview, say, right hand rail content boxes in the full context of an episode page.

What we really need is the ability to look at a published page and pass in a preview flag, which would then display the latest (potentially unpublished) revisions of the nodes on the page. Even better, this preview functionality should allow for a date parameter, which would then also take account of Scheduler publish and expiration dates.

Now tell me that that wouldn’t be sweet!

Anyhow, I knew this would be an issue sooner or later, but chose to put off dealing with it for the TV Programs and Schedules module. However, as we look to rebuild the whole rest of the WGBH.org and move everything to Drupal, we will have to come up with a better solution. In the future, our home page will be made up of view lists of content boxes, each of which could have its own publish and expiration date, multiple revisions, etc. Being able to properly preview the page will be key for us…

Any ideas? Let’s hear em.

It’s official - WGBH Online has gone into testing mode for the new TV Programs and Schedules module!

I’ve whipped up a whole mess of this:

I’m talking about the user documentation, not the coffee. All of our documentation has been posted to the WGBH Online wiki.

The obvious advantage here is that not only can everybody access the documentation but they can edit it as they see fit! Love that.

Anyhow, yesterday I shared this documentation with our little content production team and had a training session on the new system. They will now spend the next week testing out the functionality and implementation on our test suite. That means Pete and I will shift into bug fixing mode for a bit.

After that our next big step is to get the staging suite configured and running properly. What’s the difference between our test suite and our staging suite, you ask?

Good question.

Well, the test suite is a stand alone server, much like our development suite, with everything on the same box (MySQL, Drupal, Apache, etc). The test suite is used for testing functionality, design implementation, etc.

Our staging suite, on the other hand, is meant to mimic the real live environment in which the new site will run (e.g. separate web and database servers, uses Memcache, etc.). It will allow us to ensure that the new site will function properly when we launch it live and, more importantly, that it will coexists peacefully with our current site. Recall that we’re not converting all of WGBH.org to Drupal just yet. The first phase will only involve the TV programs and schedules. All of our other content (home page, radio programs/schedules/playlists, kids section, etc. etc.) will remain in our current CMS and be served by our existing application for the time being.

So, we need to ensure that the two systems will work properly together. The staging suite will also be a place where IT can work out system upgrades and such before attempting them on the live systems.

Once we have our staging suite configured and running smoothly, we will focus on application and database tuning. After that, we’ll be ready to begin the launch phase!

Exciting? That’s one word for it.

Of course, we’re also busy thinking about life after the launch of TV programs and schedules on Drupal. That’s when things will get really interesting. We’re rethinking everything: information architecture, look and feel, personalization, the whole she-bang. While we’ve been busy with TV schedules, others have been busy meeting and thinking about the bigger picture. As part of that process, we’ve diagrammed out all of the content currently on the site. It looks something like this:

Actually, that’s only half of it. Here’s the other half:

You can see we still have lots of work to do…

I’m on vacation next week meaning Pete is running the shop! Lucky him!

NPR.org has launched a blog with a very similar intent as the WGBH.org Development Blog - Inside NPR.org. It looks very interesting. Take a look-see at your leisure!

Congratulations to Andy Carvin and Daniel Jacobson for an excellent idea. Bravo gentlemen!

I hope everyone had a great 4th of July! I had what I would call a successful 4th - I didn’t lose a single digit! All the better to build the new WGBH.org with, I say!

This week we are getting ready for some full blown functional testing. Our project manager Louise is busy assembling the testing team and working up a testing plan. I’m busy writing up user documentation for the TV Programs and Schedules module, which I’ll use as a basis for a training session this week for the testers. This documentation will get posted on the WGBH Online wiki where the whole team can access it and modify it. I mean, really, who doesn’t love a wiki?

I thought I’d take the time now to give you a peek at some of the contributed modules that we’re currently using for the TV programs and schedules module.

First up, CCK! We have multiple custom content types, including TV Programs, TV Episodes, TV Airings, and Content Boxes.

We make use of the Date module for setting airing dates for TV programs and generating schedules.

The Devel module is vital for use during, well, development.

We use the FeedAPI module for importing our TV program and schedule data, which we get from PBS as an XML feed. Note that we use the SimplePie parser.

The Image and Image Assist modules allow us to upload, find and reuse images in the most straightforward way. The Image module will also generate thumbnails and preview versions of images at upload time.

We use a number of other contributed modules along the way. Since we use CVS to download core Drupal and contributed module code we use the CVS Deploy module helps us to keep track up of new releases. The Pathauto module automatically generates URL aliases for our nodes, according to patterns we define. Porter-Stemmer and ReIndex modules are used for search. The Scheduler module allows us to schedule node content for future publication or expiration and TinyMCE gives us a nice WYSIWYG editor for textareas.

Finally, we couldn’t do much without Views and we’ve also developed two custom modules of our own, the WGBH TV Schedules module for handling the bulk of the custom programs and schedules code and the WGBH TV Search module for some custom search functionality.

You can also see the various states of completion of these modules. We’re still working with a bunch of alpha/beta versions here. As they say, it’s not for the faint of heart…

No doubt this list will continue to grow over time. Here’s a big shout out to all of you who develop and maintain these contributed modules. This is what makes an application like Drupal so useful to so many. Go ahead - take a bow - and keep up the good work!