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!

This week brought good news and bad news. Actually, more like very good news and pretty annoying news. First, the very good news:

We have officially posted some pages for internal testing! Behold…

TV Programs A-Z (click to enlarge)

Nothing too fancy here. On our current site the A-Z list is a popup. But now it’s a full grown page! One note: the Search TV Programs form does not yet work, on this page or any other.

TV Schedule Grid (click to enlarge)

Now we’re talking! The grid is the big magilla of this project. It finally allows us to display schedule information for all of our channels at once. Basically, we’re finally catching up to the rest of the world.

As you can see, the grid displays schedule information in three hour blocks. The user can navigate forward or backward or jump to a specific block of time using the Pick a Time form at the top. There is also the calendar selector, which lets users view the schedules for a given day. Note how the calendar highlights the current day (or the day of the schedule that you’re looking at), as well as the schedule data window, the period of time for which we display schedule data which, as of now, is one week week back, two weeks forward (almost).

We still need to play around with limiting the number of characters in the program or episode title that we display on the grid. There’s always something…

Full Day TV Schedules by Channel (click to enlarge)

As you can see, the full day schedule shares the calendar selector with the grid, and replaces the Pick a Time selector with a Pick a Channel form. Nice!

Now we can proceed with some preliminary testing, while Pete and I get to work on the program/series, episode, search and other pages.

Ok, on to the pretty annoying news. This… (click to enlarge)…

…is still happening.

Under a couple of different scenarios, the underlying PHP process uses up its allotted memory and then - like one of my kids - holds its breath and refuses to continue until is gets what it wants (more memory!). The above error was generated simply by trying to enable the theme developer. It can also happen during our nightly schedule data ingest, though our current allocation of 512MB is enough to prevent this, thank goodness.

So far all I’ve been able to confirm is that it’s not a server configuration issue. It seems to be a code leak and there may be more than one culprit out there. It’s starting to give me real headaches and needs to be resolved in the not too distant future.

However, for now, I refuse to let it ruin my weekend!

Been a low-key week here at WGBH Online World Headquarters, or as we call it WOW HQ.

The big event of the week: I got a haircut. All that goofy hair on my head was making it hard to think properly, so I had quite a bit of it lopped off. Things should really start picking up now.

Pete and I have been finishing up our first pass at the TV schedule pages (a multi-channel grid, full day schedules by channel, and a Programs A-Z list). Doesn’t sound like much, just three pages (basically), but there’s quite a bit involved, as you might imagine.

The plan is to get these pages in shape and then post to our test suite for a preliminary round of testing. This testing will be done by people other than Pete and I and the purpose is really just to evaluate how well the data is being imported from PBS. We haven’t worked up a formal test plan yet, but it will most likely involve comparing the WGBH schedules on PBS.org (which use the exact same TV Guide data) to the schedules we’re producing with the new code. We won’t yet be testing the ability to modify this information locally.

Needless to say, testing is just an annoying formality. The odds of there being any bugs in our code are minimal.

I’ve also been working with our new project manager Louise (Hi, Louise! I know you’re reading this…) to help fully flesh out the project tasks and schedule. That’s been a long process but I think we finally have all of the pieces laid out and scheduled.

In addition to the schedule page testing, we’ve also blocked out a longer period of time for full functional testing after we complete all of the development for this module (i.e. schedule pages and program and episode pages), as you would expect. Again, that’s testing outside to be done by others distinct from the unit testing that Pete and I do during coding. We thought about trying to break out functional testing into a more discreet chunks, but given the relatively small size of this project, it didn’t seem to make sense.

OK, I gotta go wrap up these schedule pages. Don’t forget to call mom on Sunday! I mean your mom, not mine. I’ll handle her.