The WGBH.org Development Blog

What better way to warm up for Thanksgiving then with some blogging tools talk! Always puts me in the holiday mood.

Anyway, so far as public broadcasters go, WGBH is one of the biggest, in terms of production, people, departments, projects, etc. and etc. This means that, in addition to our main web site, WGBH.org, there are any number of other related web sites out there floating around. The involvement of our group, WGBH Online, in these related web ventures ranges from full fledged ownership and support, to technical consulting, to completely hands off.

While the ongoing redesign of WGBH.org continues to trudge along and hang over our heads, there are a number of these other related projects which are coming on to our plate, to one degree or another. Many times, we are finding, these small web properties can really just be handled as blogs, whether the request is framed that way or not.

Of course, now that we have a Drupal production site up and running, supporting these related sites should be simple, no? If somebody here needs a blog, well, no problemo! Drupal can easily support multiple blogs, all under one code base, making for easy maintenance, theme sharing, logins and on and on, so that should be that, right?

Well, maybe. But maybe not. At least not always.

Recently, we have been tasked with supporting at least two new blogs. While our initial impulse (and general preference) is to build them in Drupal under the existing code base, further reflection has made us think that WordPress might, in some situations be the more practical choice.

Much as we love Drupal - and we do love Drupal so - when it comes to stand alone, easy to use blog-authoring tools WordPress is hard to beat. From it’s slick and user friendly administration tools, to its wide choice of plugins and themes to its ease of installation and maintenance, there is much to like!

Personally, I use WordPress for several blogs and we even use WordPress for this here blog!

WordPress also has the advantage of already being familiar to many folks, of both the technical and (very) non-technical variety, so the learning curve is even smaller.

Drupal or WordPress for our global blogging needs is not a clear cut choice and so we are picking and choosing between them on a case-by-case basis. In each case there are several criteria that come into play:

Integration with WGBH.org

The first question is just how tightly the proposed blog is to be integrated with WGBH.org. Does it need to look and feel like the rest of the site? Does it need to pull/display/reference content from the main WGBH site? Should its content show up in searches on WGBH.org? Basically, the more tightly integrated it needs to be, the more we lean towards Drupal, since everything would be in the same content management system.

Development Needs

Does the WGBH Development (fundraising) department have requirements for the blog, such as being able to capture site visitor information and interactions (e.g. email addresses, comments, etc.)? Will the site require a login? Since our Drupal site will eventually be integrated with our CRM and membership applications (and support single sign on across these apps), Drupal is more attractive if Development imposes such needs.

Degree of Ownership

Does WGBH Online truly own this blog, as in is responsible for look and feel, content, and technical support and maintenance? Or is the blog really owned by a separate group with WGBH and WGBH Online is mainly providing technical support? In the former case we would go with Drupal; in the latter we may go with WordPress, depending on some of the other criteria mentioned here.

Flexibility

How flexible are the requirements, particularly pertaining to look and feel? Does the blog need a custom theme? Or can it use an existing, off the shelf theme? Are there special (and rigid) requirements outside traditional blog functionality? Essentially the more custom coding work that my group will have do the more likely we are to use Drupal. If we are going to use WordPress, we don’t want to spend much time writing custom code or themes for it. Any heavy technical lifting should remain in the Drupal realm.

Time to launch

How quickly does it need to be up and running? If it has to be ready to go soon - and assuming the type of flexibility mentioned above - WordPress is more attractive. The set up time can be quicker and the user learning curve smaller, in general. But, then again, we try not to let time constraints dictate everything, if we feel a little more time will lead to a better solution (like implementing in Drupal).

These are just some of the questions that we are starting to ask when approached with projects tangential to WGBH.org. We’re still trying to figure this out as we go along. As always we reserve the right to change our minds in the future…

Anybody else wrestling with this sort of dilemma? Please share…

Hope everyone has (or had) a great Thanksgiving!

Tags: blogs, Thanksgiving!.

For those of us in the northern hemisphere, fall has arrived! In between raking up and burning piles of leaves (and useless 401K statements), we here at WGBH Online have continued to fine tune our new(ish) TV Programs and Schedules pages.

As you may recall, not long after launch in August, we began to revisit the whole notion of how we’re tagging our TV programs and episodes. The main reason was to improve the way we generate lists of related programs, so as to suggest to visitors other shows they might like. Our initial approach was simple: just tag the programs (not individual episodes) and use a Drupal view to generate a list of up to three related programs.

But this soon proved restrictive. Sure, Frontline is a News and Public Affairs program, but individual shows in the series can be about different things (technology, politics, science). So, we wanted to be able to capture this more detailed level of information and use it to generate more useful lists of related programs for our visitors.

After much thought and discussion (not to mention headaches), we came up with an expanded tagging scheme and more sophisticated program matching logic, which has now been implemented on the site. Here’s what we did:

We renamed our existing TV Program Genre vocabulary to TV Program Primary Genres.

The terms remained the same (a small set of high level classifications) and these are still only applied at the program level.

We then added a new vocabulary that can be applied to both TV programs and episodes: TV Program/Episode Secondary Genres.

This secondary list has many more terms that now allow for a more sophisticated level of classification. tags applied at the program level apply to all episodes in a series. Tags applied at the episode level are only applicable to that particular episode.

Once we had that in place we then had to think about how, using these tags and given a single program episode, we would define rules for identifying “related” programs and episodes.

This is where the aforementioned headaches started to kick in.

Once you started to think about it, all sorts of questions cropped up, like, which carries more weight, matching primary genre tags or secondary genre tags (or should they count equally)? Or, assuming two related programs have the same tags as the target episode, how to break the tie? Or, do we match an episode within one series to other episodes in that series or restrict it to episodes of other series?

Pass the aspirin, because I’m getting a headache just thinking about it again.

Luckily, we have some fine folks working here who sat down and really noodled through this to come up with some matching logic. When written out, the matching rules looked something like this:

1. Match at the episode level
2. Cull only from upcoming or recently-aired episodes
3. Look for most tag matches, with all tags equally weighted
4. Only allow one episode per program/series to appear in “You Might Also Like” box
5. In a tie, give priority to episodes with same “Program Primary” tag
6. If still a tie, give priority to episodes with exact same tag makeup (i.e. both have only one Primary tag)
7. If still a tie, give priority to the episode with soonest upcoming airing.

The idea was then to use the tags and these rules to generate up to three matches for each episode to display in the “You might also like” block in the right hand rail.

Well, up to three matches, unless there were more than three episodes with the exact same tag structure as the target episode. In that case, we will display up to five such matches.

No sweat!

In order to actually implement this, we could no longer just spit out the results from a view. Nope. Instead, we had to jump through a whole bunch of hoops. Here’s the thumbnail sketch of the implementation:

1. Given the tags for a target episode, query a view of TV programs, fetching all programs that match at least one Program Primary or Secondary tag.

2. Filter this list of programs, including only programs with an airing in our schedule data window (one week back, two weeks ahead).

3. Then count the exact number of tag matches and calculate a matching score for each program, based on the above rules. Then store the program in an array.

NOTE: I won’t go into the exact matching score formula here. Suffice it to say we came up with a formula that encapsulates the above matching and ordering rules. Please pass the aspirin again…

4. Next query a view of TV episodes, fetching all episodes that match at least one Episode Secondary genre of the episode in question.

5. Filter this list of episodes, including only those with an airing in our schedule data window. For each one count the exact number of matching genre tags for the episode and calculate the matching score. See if the episode’s parent program is already in the array of matching programs. If so, replace it with this episode if the matching score is higher.

6. Given the final array of matching episodes, reorder the array by the matching scores and display the top three (or five) entries!

The resulting PHP code to implement all of this ran to about 240 lines and looked a little something like this:

All that just to generate this on the front end:

Anybody know the limit on the number of aspirin you can take in one day?

One great thing about Drupal is being able to easily put your site into site maintenance mode. For example, if you need to perform some site maintenance work (like installing core or contributed module code updates) you can easily put the site into this mode by clicking a button on the following form:

What this will do is then direct all anonymous and non-admin users to a page using your chosen theme with a message that you write, which you plug into the message box. For WGBH.org, the page looks like this:

So - easy!

However, this page can’t be used for some types of site maintenance, like, for example, maintenance work that takes the database offline. No database, no Drupal-generated site maintenance page. Bummer.

We recently faced this problem when our fine friends in the WGBH IT department needed to do some MySQL maintenance work (they wanted to do a little cleanup and reorganization of the database files on the production server). Since this type of work comes up now and again, I wanted to devise an easy way to post the same site down page that all requests for the site would get directed to, with the minimal amount of work, so IT could incorporate it into their process for future maintenance work. I wanted a simple process to make everybody’s life as easy as possible.

My first thought was to have an alternate Apache config file for the site, which would point to a different document root that stored the site down code and graphics. This would work well enough, but would require stopping Apache and then restarting it using the new configuration file. Not too complicated, but still more steps then I wanted.

After some coffee and deep thinking the solution popped right out me: symbolic links!

The document root for the site is actually a symbolic link to the real directory of Drupal code. So, I figured, if we just change that link to point to a new document root, containing the site down code, then - bingo - we’d be done! That’s even easier than using an alternative Apache conf file.

So, this is what we did. There was just one other fine point here: where to put the site down directory?

Initially, I figured on a directory completely separate from the Drupal tree. However, that would then mean we’d need to copy all the required images and style sheets from the Drupal tree to the site down tree, making future maintenance a bit more work (we do tweak the site down page according to what’s going on at the time). Kind of a pain.

What we did instead was put the site down directory within the Drupal directory tree. That way the page code could reference the appropriate images and style sheets. Plus, that code then gets managed via SVN as part of our Drupal code base. The final approach, then, involved the following:

* Create a site_down directory under the top-level Drupal directory.
* Create an index.html file in that directory that contains the source code from the Drupal-generated site maintenance page.
* Tweak the source code to use absolute, rather than relative, links to images and CSS files.
* Create an .htaccess file to make sure all page requests get redirected to the index.html page.

Voila! Using this method, all IT had to do before performing their database maintenance was change the docroot’s symbolic link to point to the site down directory. Then, when the work was done, change the link back. No need to even stop/restart Apache.

So - once again - easy!

If only fixing the economy were so simple…

Do you have a different method for handling this sort of thing (or for fixing the economy)? Talk amongst yourselves then please share!

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.

Visitors to WGBH.org often come to the site seeking out information about a specific TV program. Maybe they enjoy Frontline, and they want to find upcoming episodes. Or they caught the last 5 minutes of a show about hot dogs, but they can’t remember the name of the program and they want to know if will be airing again.

So one of the requirements of the TV Programs and Schedules was that we implement a scoped search – an advanced search page that would only return a list of TV episodes in the results.

In the past, I’ve used some interesting modules that modify or expand upon the core Drupal search. The Views Fast Search module offers the flexibility to define the content you perform a search on, which really enhances the searching capabilities. Unfortunately, the module is only available for Drupal 5 (although parts of Views Fast Search made it into Drupal 6). Drupal’s built-in advanced search form is also capable of limiting a search query to specific content types — there are several different approaches to achieving this. And the Restricted Search module allows administrators to exclude content types from the search index entirely.

But simply blocking other content types from the query won’t quite cut it for several reasons, and excluding content from the search index would not be a good long-term solution, because eventually we will need to make use of the full site search in addition to this scoped search. Also, just to spice things up a bit, the additional criteria for the TV search specified that:

• • The search should only return TV Episode nodes. The Airing and Program nodes do not show up in the search results, although they do play a factor in the indexing of the Episode nodes and the ordering of the results.
• • Search results should include the program and episode title, a brief description, a link to the episode page on WGBH.org, and a link to the program web site, if there is one.
• • In ordering the search results, keyword relevance is the most import factor, but upcoming airings are a close second. For example, a search for “Curious George” would yield a long list of episodes for that program, but the episode that is airing this afternoon would be at the top of the list, followed by the episode airing tomorrow morning, and so on.

The real heavy lifting of Drupal’s search mechanism can be broken down into two areas: the indexing of the nodes (hook_update_index()) and search query (hook_search()). Both of which involve some code that quickly made my head hurt. But as luck would have it, I pulled out our copy of Pro Drupal Development and discovered a whole chapter dedicated to search. That, combined with Robert Douglass’ very detailed blog post, Drupal Search: How indexing works, worked wonders like a big bottle of ibuprofen.

Indexing

When cron runs, Drupal will index any new nodes, and reindex nodes that have changed since the last run. The title and body of a node, with all HTML tags intact, are parsed — Drupal uses the HTML tags to give additional weight to words. Text in an H1 tag must be important, so those words would carry a very high score, while linked text would carry a lower score (although higher than plain text). Words that are bolded, italicized, or underlined also get a small boost.

This is why a node with “Nova” in the title scores higher than a node with “bossa-nova” in the description, when the search term is “Nova”.

Overriding the Index

For our purposes, when we index an Episode node, we also want to include the title and description of the parent Program in that index. It is entirely possible that an episode of Nova, for example, might not even mention the word “Nova” in the title or description, so we must include the Program title and description.

To achieve this we use hook_update_index() to loop through any new Episodes. We load both the Episode node and the parent Program node, and then build a string with both the Program and Episode titles in H1 tags, and append the body of each node with all HTML tags intact. That string is then passed off to search_index() where each term is counted, scored, and added to the index.

Search Query: Ordering the Results

As the requirements specified, the results of the search query should be weighted with keyword relevance and upcoming airing date being the primary factors in determining the order.

Keyword relevance, of course, is a standard part of the Drupal search ranking mechanism, but to affect the score based on upcoming airings, we construct an additional ranking query. That query, which returns the difference of the upcoming airing timestamp and the end of the data window (or 1 if there are no upcoming airings), is passed to Drupal’s do_search() function. An array of node IDs is returned and passed off to the theme level.

One very nice thing about Drupal’s search is that this custom search was developed without impacting the existing full site search capability. No core code needed to be touched, and in the future we can add scoped search to other areas (like Radio) by replicating several functions and adding a few case statements.

I don’t want to belabor the whole space travel analogy, but, what the heck - life is short! Let’s belabor-away!

Earlier this week we took one small step for TV schedules and one giant leap for WGBH.org by officially launching the new Drupal-based TV Programs and Schedules section of WGBH.org!

Aside from finding a significant bug literally 10 minutes before launch, it has all gone quite smoothly! Drupal is behaving like a champ and everything is humming along.

In fact, for a worry-wart like me, you could almost say it’s going too well.

So, now I’ve jinxed everything. Oh well. Like I said, life is short.

The list of people to thank for making this all happen so smoothly is long. At the top of the list is my friend and co-developer Pete Bull who did a great job from day one and has saved my bacon on a bunch of occasions already (including tracking down and fixing that aforementioned last minute pre-launch bug). Our good buddies in the IT department, especially, did a ton of work to get a whole new development, testing and production infrastructure in place for us, so a big thanks to Peter M., Bruce D., Sarah, Larissa and all those folks. You guys and gals rock.

Also, our project manager Louise, designer Tyler, WGBH Online Director Darleen and all of our patient content producers were great to work with under the sometimes-trying circumstances. Finally, but not leastly, our former director Bruce K. and my old buddy and our former designer Peter L. (note: WGBH apparently has a rule about employing a large number of guys named “Peter”) played big roles early on in the process.

There were also any number of outside folks who also helped out at different stages, including Drupal-gods Robert Douglass and Moshe Weitzman and the fine folks at Lullabot. Of course, there’s also all the faceless folks in the Drupal community who contribute modules, create patches and document all sort of helpful things. We love open source!

Whew! See, lots of people have contributed here.

Now, of course, the real fun begins: a full blown overhaul of all of WGBH.org, including new information architecture, look and feel and, of course, a complete port of, well, everything to Drupal.

Should be no sweat!

Sadly, though, unlike for the Apollo astronauts, there will be no ticker tape parade. Maybe next time…!

Hours before they were launched into the space, and few days before two of them became the first men to walk on the moon, the crew of Apollo 11 sat down for a hearty breakfast of eggs, toast, coffee and - of course - Tang!

Well we here at WGBH Online are getting ready for our own launch in just a few days. We’re not quite ready for the pre-launch breakfast, but we should probably go shopping for all the ingredients real soon.

A whole bunch of people are working feverishly right now to dot all the i’s and cross all the t’s on our new TV Programs and Schedules module. Everything is going smoothly - knock on wood - and I think we may pull this off as planned. Suffice it to say, lots of coffee is being consumed.

The biggest development of late is that Pete has worked wonders to get the Boost module working for us on Drupal 6. Initial benchmarking tests indicate that Boost has increased our throughput by about ten-fold over the traditional Drupal database caching.

Boy, we love that.

Anyhow, keep your eyes peeled here for the big launch announcement - and get ready to start the eggs!

As they say at NASA we here at WGBH Online are in official launch mode! I can almost count on both hands the number of days until we light the candle under our new TV Programs and Schedules. The clock is ticking and we’re very busy trying to make sure this rocket won’t explode on the launch pad.

Our new production system is up (well, mostly) and ready for our content producers to begin entering content in preparation for launch. This mainly involves adding information to TV programs that we don’t get through our PBS/TV Guide data feed (series descriptions, photos, related sidebar items, etc.).

The only piece of the puzzle that we’ll be unable to have in place in time for launch is memcache integration. As of now, there isn’t a version of the module yet for Drupal 6. I asked Robert Douglass - one of the memcache module maintainers and somebody we’ve worked with in the past and a good guy - about the D6 version of memcache and he said it’s coming soon. In the meantime, we’re preparing to launch with traditional Drupal database caching.

What could wrong?

So the plan here is to get the content producers producing, well, content on the new system next week while Pete and I and our beloved buddies in the IT department work on system and application benchmarking and tuning. We’re having a MySQL consultant come in next week to help tune that end of things. I’ve been running benchmarking tests using Apache’s ab utility, and Pete has been tinkering with getting the Boost module (a file-based caching mechanism) running on D6. I was aware of Boost before but we hadn’t been planning on using it at launch, but now that memcache is on hold we’re giving it a go.

Again, really, what could wrong?

Oh yeah, plus I have a bunch of work to do to integrate the new TV schedules with the rest of WGBH.org which is not yet being ported to Drupal (like, um, the home page).

The biggest news of this week, however and by far, is that we had a visit by a very special guest - Drupal core developer (and local resident) Moshe Weitzman! You know somebody is important in the Drupal world when they have a URL like drupal.org/NAME.

We made the connection with Moshe a few weeks back and he’s been kind enough to offer some Drupal help and advice that’s already saved us a lot of headaches. So, we wanted to meet him in person to say thanks.

Moshe came by and we gave him a tour of the new WGBH facilities and then he, Pete and i went across the street and had a nice lunch. Moshe is a very nice guy and we had a great time meeting him and talking Drupal (amongst other things). In fact, Moshe was the one who encouraged us to give Boost a try. Thanks Moshe!

There you have it! Now, if you’ll excuse me, it’s time for me to get back to mission control.

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!