I’m happy to report that some PHP-based initiatives are still cooking! This week we launched one of those, Project Dropout.

Project Dropout is a collaboration between WGBH and our friends at WBUR looking at the student dropout crisis in Massachusetts. It includes a radio series, a television series and, if course, the blog.

The blog was built using WordPress. As I’ve previously discussed, we had to give some thought to whether to build this blog using Drupal or WordPress. We decided on WordPress for this project mainly because it’s meant to be a short lived, stand alone effort, quite distinct from WGBH.org (i.e. no shared templates or look and feel involved, no need to tightly integrate it with the rest of our main site, etc.).

Plus, by going with WordPress, much of the work (including theming) could be handled by others (both WGBH and WBUR staff) without requiring much work from Pete or I. That’s always a plus! My work involved installation and configuration and helping out with some of the trickier theming and CSS issues. All in all it’s been a smooth ride and a fun project to be involved with. Please check it out.

In other news, I’ll be attending the Intergrated Media Association’s Public Media Conference next week in Atlanta. I’ll be arriving Tuesday night so as to make the Tech Summit on Wednesday. I’ll be at the general conference as well, through Friday evening, when I return to Boston.

I’m looking forward to seeing some familiar faces and meeting new folks. If you see me wandering around, say hello! I’ll be the guy who looks kind of like this (minus the beard, which I just shaved off):

I hope to see a number of you there!

Tags: CSS, IMA, Project Dropout, Public Media Conference, WBUR, WordPress.

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!

Much like tax professionals, we’ve been very busy here at WGBH these last few weeks! As the kids like to say, here’s the 411 on all that.

Our good buddies in the WGBH IT department (note: always make friends with the folks in the IT department) have installed and configured several new servers for us! It’s like Christmas came really early (or very late). Here’ what we found under the tree:

Code Repository

We’ll be using Subversion (SVN) to manage our code base. We’ve now got a stand alone server for this repository. Currently, we use CVS (the concurrent versioning system, not the drug store), with a repository piggy-backing on our current development server.

Development Server

We’ve got a new development server that’s now running PHP, MySQL, Apache, phpMyAdmin, SVN (client), CVS (client), etc. and so forth. As the name suggests, this is where we will do all of our development work. More on that below.

Test Server

We’ve also got a new test server, that will be used as a staging area for proper QA. Software installs will mirror those on the development server. This will replace our current test suite, which consists of separate web and database servers.

Now that our new development server in place we can really plow forward with development of our new TV Programs and Schedules module. It also means it’s time to make (and implement) some big decisions. Allow me to elaborate.

Drupal Version

As I mentioned earlier, I was holding off on making a final call on whether to build on Drupal 5 or 6 until the new development server was up and running. Up until now we’ve been doing preliminary coding on a Drupal 5 install. Well, after doing some reading, soul searching, chatting with my religious counselor, etc. Pete and I have come to the following decision:

We’re going to go with…

(drum roll, please)

Drupal…

(more drum roll)

version…

(dramatic pause)

6!

I made this call after looking over the state of major contributed modules that we would need to proceed. These include (among others): CCK, Date, Devel, FeedAPI, Image, Image Assist, Pathauto, and Views. It seems that all of these modules (except for Image Assist) have at least a development (or alpha or beta) version that works (to some degree) with Drupal 6. The big holdup here seems to be the completion of Views 2, upon which much depends.

Our thinking is that it’s better to suck it up now, live with the Drupal 6 growing pains at the outset, and end up with a site on the latest version of Drupal, before the next major release early in 2009. If we build on 5, we’re looking at launching a site on a version of Drupal later this year that will quickly be two major releases behind. Also, Drupal 6 just has lots of nice improvements that we’d like to take advantage of. Or should it be “of which we’d like to take advantage?” Wish I’d paid more attention in 10th grade English class.

So, we’re going with 6. No worries, no regrets. No pain, no gain. I’m out of cliches.

Development Environment

How Pete and Josh and I (and maybe others) will be developing the new site is, clearly, an important thing to think through at this point. We want to set up an environment that allows for the most efficient development, while also being easy to use, secure, easy to push out to new developers as well as staging and live environments, etc. Lots to think about.

Here’s the plan.

All development will take place directly on the development server. Since none of us travel much, if at all, we don’t have much need for working locally offline (like on an airplane). By developing directly on the server, all we need is Internet access and a VPN connection and we can go to town. Each developer will have his own database and copy of the site code (or possibly more than one of each, if need be). It will all reside on that server, which makes backup and maintenance easier.

As mentioned above, all code will be managed using SVN. Core Drupal code and contributed module code will be downloaded using CVS from the Drupal CVS repository. This code, along with our custom code and any changes to code or module code will be tracked locally in SVN. Developers can get code updates from others using SVN updates. Nice and clean and easy.

Code will be rolled out to the staging and live versions of the site using SVN. We will not be doing any commits or code distributions on an automated basis. One tricky aspect here is the propagation of setting/code/content stored in the database to other developer installs or staging or live environments. There is no easy solution to this well-known problem. Initially, our approach will be the following:

• Create a WGBH.org installation profile - This profile will be used when rolling out a new developer environment or when initially setting up staging and live installs. This will enable the required modules (both core and contributed), set certain variables, and create base users and roles. I’d like to keep this profile small, since we won’t be using it all that much. This will need to be maintained over time as basic changes are made to the site.
• Use custom module install files - We will use custom modules for (among many other things) managing database changes (both DDL and DML). So, for example, our custom TV Programs and Schedules module will have an install script that creates a number of CCK content types, populates some content nodes and sets some additional database variables. As development proceeds, this file will also be used for making required database updates to existing installations. We will do a similar thing with other custom modules as the greater site rebuild proceeds. This should help to modularize the maintenance of all of the various database setting, objects and records.

At least that’s the theory.

There you have it. Now, if you’ll excuse me, I have quite a bit to do…

P.S. If you have kids, Horton Hears a Who is excellent! I highly recommend taking the little ones to see it. If you don’t have kids but enjoy hallucinogenic drugs, I’d wager you’d also enjoy it quite a bit. Just a guess.

Hello world, indeed!

Welcome to the grand opening of the WGBH.org Development Blog! We’re glad you could join us. Pull up a chair and get comfy.

WGBH is a public media broadcaster in Boston, Massachusetts, as well as a producer of content for the public broadcasting system (PBS). As we like to say WGBH produces content that informs, inspires and entertains. Read more about what WGBH is all about here.

WGBH.org is the web site which supports and enhances all that WGBH does, by featuring TV and radio program information, live radio streaming, podcasts, video clips, news, community events and lots of other interesting and original content. Perhaps you’ve seen it already…

We’re the folks primarily responsible for the technical development the site and the content management systems that are used to populate it. Read more about who we are here.

WGBH.org is a complex site with lots going on behind the scenes; it’s also about to undergo a major redesign, including a completely new information architecture and back end infrastructure. In honor of this impending overhaul we’ve decided to launch this blog to share, from a technical perspective, how we’re going to do it. Since we’re a public media company and since we’re going to rely on (mostly) open source tools to do this work (e.g. MySQL, Drupal) and since we’re not doing anything top secret we thought blogging about the process in an open way only made sense. We plan to share what we know and hope to learn from you what know and are willing to share with us.

Be aware that the content of this blog will be pretty nerdly in nature, as it’s aimed at web developers, site architects and assorted IT folks. As such we’ll make heavy use of such terms as HTML, PHP, MySQL, CSS, XML, RSS, SQL, bandwidth, capacity, servers, loads and other such dorky acronyms and buzzwords. However, we promise to never, ever use the word synergy. Whoops, well never, ever starting right … now!

This should be enough to get us started. In the coming days I’ll provide some more background on the current site and the plans for the rebuild.