The tech story behind the Trinidad Guardian - a newspaper website

The Trinidad Guardian, one of 3 popular newspapers in Trinidad, re-launched their website on New Years Day 2009 using Drupal. The site has a simplistic design done by their in-house graphics designer Ms. Maxie Navarro. The Drupal developer behind it, Shivan Jaikaran, would like to share his techniques as a tech case study.

The Homepage

The homepage has a different look from every other page on the website. This was done using a custom page-front.tpl.php and Panels. The main sections of the website (the same as their print edition) are the main menus (or the primary links). The colours corresponding to the menus correlate to the print editions as well. The colours (on hover and active) were done using simple CSS.

The Internet Editors needed to decide which articles go exactly where in the centre column of the homepage. For this, Nodequeues were used extensively.

Scheduling

Deep thought went into what scheduling technique to use. The editors wanted to be able to create the stories from the day before and schedule a time for it to be "published". Initially, it was thought that the Workflow module was overkill for this and that a simple combination of Views and CCK date fields can handle this. But in the end it was easier to use the Workflow module and its built-in scheduling of transition states were used quite successfully. I ran across this bug, but a simple fix became available soon after.

Data Architecture

All news articles on the site are of the same content type. They are all "articles" after all. And as with all newspapers website, they have more or less the same kind of fields (strap, slug, drop, byline, title etc). The editors wanted the ability for each article to have a main image. This was simple: use a image CCK field. However, their request was that sometimes the image might be a vertical one (where the body text would then wrap to the left of the image as shown in the example to the right) or the image might be a horizontal image (where the image would stretch the full width and all body text starts underneath it). To get this functionality done, I had to use two imagecache presets. But how then would Drupal know whether a horizontal or vertical image was uploaded? After I beat my head around this for a few hours, I finally came to a dirty solution that did the trick. I simply added another CCK drop down field called "Stretch" with two preset values Yes and No. "Yes" would mean stretch the image horizontally and No would mean the opposite. The code inside template.php looked like this:

if ($vars['node']->field_stretch[0]['value'] == 'No') {
$stretch = theme('imagecache', 'article_main_image', $vars['node']->field_main_image[0]['filepath']);
}

else {
$stretch = theme('imagecache', 'article_main_image_stretched', $vars['node']->field_main_image[0]['filepath']);
}
$vars['stretch'] = $stretch;

Not too nice, but hey it worked! If you have an easier solution to this, I'd be interested to know so you can always leave a comment.

Caching Strategies

It was quite obvious from the forefront that this was a high traffic website and that caching strategies had to be thought about at some point. During testing it was realised that the site became sluggish with the surge in traffic during peak hours. In keeping with the existing web hosting set up at the time, a combination of different caching strategies were used.

Ofcourse, Drupal's built-in pagecache and minimum cache lifetime values were set.

CSS aggregation, MySql Query Cache and Panel's Simple Cache were used.

Even with the above implemented, it was still sluggish. At that point eAccelerator, an increased HTTP KeepAlive and Memcached were the major players that turned a sluggish site into a fast responsive website.

Module Highlights

Without the Drupal community contributed modules, none of this would have been possible. A great fat THANK YOU goes out to each and everyone of you.

• Node queue - This was used extensively throughout the site on the homepage as well as in each section page. This allowed editors to easily put a node into its correct queue right after the node was created. The queue, coupled with Views and Panels, then handled where the content was placed.
• OpenX Adserver Integration - On their old site, OpenAds were used, so this module came in very handy for the new site. The Ad module was a bit primitive at the time of development. That module could not handle flash ads which was a major requirement for their site.
• CCK - this site uses about 40 CCK fields and I can't personally imagine any Drupal site that does not use CCK.
• Feedback - This module is used to get the Feedback link to the top right.
• Imagecache - Again, used extensively basically anywhere you see an image. This allowed the flexibility for the editors to upload any dimensions, and then Drupal takes care of cropping the images so it fits nicely into the theme.
• Service links - This module provided a basis for the Article tools section of every article.
• Pathauto - This is a must have module for any site that cares about Search Engine Optimization.
• Views - Again, I can't imagine any site that does not use Views, especially for a newspaper site where content is mangled and twisted almost beyond the stretch of your imagination.
• Autonodetitle and Token. These little modules helped automatically title the nodes in a user friendly way...something which can be overlooked with many news sites.
• Mollom - I knew right away SPAM would be a problem from the start and it still is. But this module took care of about 99% of the spam that is coming through.

Misc: Devel, Flag Content, Tagadelic, SWF Tools, Webform, Weather.

Challenges

Well in case you missed it, there was only ONE Drupal developer that worked on this site and the timeline was 3 weeks! That meant many hours a day, no sleep and plenty Drupal bandwidth.

• As usual IE6/7 is always a pain and required their own CSS hacks.
• The site had to be developed keeping in mind that it should be accessible to persons with disabilities. With that said, every effort was made to make the code XHTML Strict.
• The old site consisted of Archives that are in plain HTML format (static files). There was no easy way to transfer this into the new Drupal site to my knowledge.
• The secondary links background had to be changed depending on what section the person is in. This required a dirty hack in template.php to add special CSS classes based on the path. Took me a while to come up with this solution after trying out other solutions that didn't quite cut it.
• Some of the Panel pages would have "No Title" in the breadcrumb, so I had to do a bit of custom breadcrumb in template.php for most of the main section pages and 3rd level pages.

Newspaper sites and Drupal

As you can probably tell, Drupal is becoming the CMS of choice for newspaper websites. You can join the Newspapers Group if this topic interests you.

Contacts

• Shivan Jaikaran
• Ms. Maxie Navarro (graphics design)

Update: This story has also been posted in the Drupal Showcase Forum