The Trinidad Guardian, one of 3 popular newspapers in Trinidad, re-launched their website on New Years Day 2009 using Drupal 5. The site has a simple 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.

Why was Drupal chosen?

The old site was a plain html site and did not provide much (if any) flexibility in terms of multiple updates, RSS, scheduled workflow or fostering a community website with features such as comments. Drupal was decided upon internally as the CMS of choice to overcome such drawbacks. It was imperative that the editors be allowed to update the site simultaneously, remotely and without much programming skills....features that were not possible with the old site.

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 colors corresponding to the menus correlate to the print editions as well. The colors (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.

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']-&gt;field_stretch[0]['value'] == 'No') {<br>&nbsp; $stretch = theme('imagecache', 'article_main_image', $vars['node']-&gt;field_main_image[0]['filepath']);<br>}<br><br>else {<br>&nbsp; $stretch = theme('imagecache', 'article_main_image_stretched', $vars['node']-&gt;field_main_image[0]['filepath']);<br>}<br>$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.

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.

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.

Of course, 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.

Managing Spam and Inappropriate Content - the easy way

Spam is a nightmare for most websites, especially where end users are allowed to contribute via web forms such as this particular website. Mollom took care of most of that. With a few other smaller modules, I was able to ease the work load of the web administrators and pass this onto the end users of the website.Comment mail was used to email the web team all the comments posted. Additionally, comments were set to be approved immediately. As most comments were generally OK, there was no need for the comment approval queue and any comments that were submitted that were deemed inappropriate were caught by at least one person via the email. The flag content module was used as a backup so that end users can flag comments that may have been missed.

Using this strategy, coupled with Mollom, literally shifted away the work load from the web team allowing them more time to concentrate their efforts elsewhere.

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 scaling and 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.
• Comment notify was used to foster community contributed comments with replies going back and forth between interested (subscribed) readers.

Miscellaneous Modules

• Devel - Very useful module for module and theme developers.
• Flag content - Used to allow users to flag content that is deemed inappropriate but not necessarily spam. I would really recommend this module for community driven websites to ease the workload of web administrators having to constantly monitor user contributed content.
• Tagadelic - Used to create the typical tag cloud so that users will see the most popular content by their tags and weights.
• Webform - Used for all of the forms on the site except the contact form (which comes with core).
• Weather - Used to pull weather from an external source for display on the homepage.

Drupal 5 or 6?

Right now this site is running Drupal 5. There is absolutely no reason why this site cannot be upgraded to Drupal 6. During the business proposal stage of this project important modules were still "iffy" or in the Drupal 6 alpha stage and wasn't quite ready for a production site, so hence the reason for choosing to go with Drupal 5 in the proposal. There was a significant time lapse between when the actual project started to when the proposal was written as well. Right now though, the upgrade path to Drupal 6 is pretty straight forward.

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 (developer)
• Ms. Maxie Navarro (graphics design)

Drupal version: Drupal 5.x