Case Study: Saint Louis Review News Website

The Saint Louis Review is a local Catholic diocesan newspaper serving the nearly 500,000 member Archdiocese of Saint Louis. The newspaper has had a website since the late 90s, which was ported to a custom-designed CMS in 2001. The PHP/MySQL-based site ran quite well throughout the first decade of this millennium, but was in need of either a serious overhaul or a redesign, to go along with the paper's new tabloid layout in April 2009.

The decision was made in 2007 to port the website to Joomla, but after a few months, a new editor, and more work, it was determined that, due to its extensibility, flexible out-of-the-box permissions, and standards/SEO-compliant codebase, Drupal would be a better fit for the site. Work was begun in January of 2009 to transfer the custom CMS' articles database (over 17,000 articles) to a Drupal site, create a new template based off the colors and design of the new tabloid-format paper, and integrate an easier-to-manage ad system and back-end.

Preliminary Work (a.k.a. Finding Help!)

Since I would be the only one managing the templating, transfer, fit and finish, it was determined (by me) that I would not be able to do all the work myself in the alotted time (January - April of 2009), especially since I had to work on three or so other large projects during the same time frame.

I had a look-see in the Drupal 'Paid services' forum, and found a very knowledgeable and efficient programmer to help code a few custom modules within a few hours. Drawk, an active Drupal contributor and programmer, wrote custom scripts and modules to help with the MySQL database transfer, the subscriptions database, and a few other needed custom functions (including 301 redirects from the old article paths). Drawk's site, whatwoulddrupaldo.org, isn't the most frequently updated in the Drupal community, but is definitely worth a subscribe!

We communicated primarily by email, and within a few days, I had the full database from the old site installed on the testing site, which made working with the taxonomy, views, and layouts oh-so-much easier. (Working with lorem ipsum text is not necessarily a good idea... but there are differing opinions).

Theming

As I've written before, I'm extremely excited with the direction Drupal is moving with regard to helping designers do what they do best—design. Even though many nice theming features will have to wait until Drupal 7, there is a lot a designer can do with Drupal 6, even on a tight schedule. Having had a small bit of experience with Zen, and having only a week or so to go from PSD to reality, I knew I couldn't scratch-build a theme, and would create a Zen sub-theme for the site.

First, the color scheme - I received a PDF of the new newspaper design's layout, including the new color scheme, and I simply built my own little color palette out of that:

I worked out the original design in Photoshop, after scribbling down rough ideas and a some math for the grid sizes on a piece of paper (which I've conveniently lost, and thus can't post here). You can view the original (somewhat simple) design here (straight from the .psd file):

With an eye towards the limitations of CSS in current-generation browsers, but a good knowledge of ways to cope with potential disaster, you can take most any grid-based design and hash out a rough Drupal theme within hours, especially if you start from an excellent base theme system, like Zen or Genesis. The above design was relatively rough, but the site's layout ended up being almost exactly the same, placement-wise.

I decided to stick with a 960px fixed-width layout, with one right column and a large central content area. I liked the right-sidebar design mostly because the site gets about 8% of its visitors on 800x600 screens (it's an older audience, right now). Because of the content appearing on the left, these visitors won't need to scroll sideways to see the most important information.

As time went on, there were many small tweaks that gave the finished product a much more refined (but in some ways 'information-heavy') feel, especially in the header, sidebar, and footer:

Some notes on the final design:

• I ended up customizing the search-theme-form.tpl.php file to allow for some jQuery-enabled text inside the search box, and a transparent PNG magnifying glass to the right of the search box.
• Internet Explorer 8 was released mid-development-cycle, which made it necessary for me to branch IE-specific stylesheets into the IE 7 and IE 6 and below sections. IE 6 can be quite nasty with floats, margins, padding and positioning, but most of the layout on the site was not affected too much.
• After reading Footers in Modern Web Design, an excellent article over on Smashing Magazine, I decided to revamp the footer and add in more destinations for users who have read through the page's content.
• Looking at the site on browsershots.org, I'm pretty happy with the design result. It looks very similar, if not identical, across almost every browser, going back to Internet Explorer 6. Testing in a program like IETester is a must!

Choosing Modules (a.k.a. using Google a ton)

The Review website needed to have quite a few ways to allow people to interact with the thousands of articles on the site, and one of my main goals was to never let a new article stray more than three clicks from the home page. The old site had many categories that were simply lost to the ether, and site search was left on a separate page. I wanted people to find the information they wanted a.s.a.p.

Almost half the site is viewed through one view (provided by Views) or another, and all content types contain many custom fields (from CCK), including imagefields, filefields, text fields, etc. I decided to use ImageCache for the main article images, since most articles have one or no images, and using such a method would allow for future automatic resizing of pictures down the road. Views also provides many of the site's custom RSS feeds (a few of which are listed top right on the home page).

There are a boatload of other modules used for minor site functionality and feature improvement, though. I'll list most of them here, along with the reason we used them:

• Administration menu - I don't have a Drupal site without it anymore. Use it. You'll love it.
• Archive - A quick, easy way to get all of your content categorized by year, month and day, without having to set up any views for it.
• Date / Date API - Used for the scheduler functionality; allows posts to be held until the next day or whenever the author wants it to be published.
• Classified Ads - No easier way to manage a classifieds section on the site... but it's currently in beta and doesn't work that well in D6. Hopefully this will change soon.
• Global Redirect, Path Redirect, Pathauto, Search 404, Service Links - Useful for SEO and for helping users get where they need to go.
• Persistent Login, LoginToboggan - makes it oh-so-much easier to control the login/user account aspects of a Drupal site.
• Service Links - Allows easy content-sharing options on the bottom (or top) of posts. Gives people something to do when they're finished reading an article.
• Similar By Terms - A nice way to give people opportunities to read more and dig deeper into your site. Provides a block of similar nodes, based on the taxonomy terms of the current node.
• Taxonomy Manager - There is no easier way to manage Taxonomies and terms in Drupal. Seriously. (Still in beta on Drupal 6, unfortunately, but works okay).
• Read More Tweak - who's idea was it to put a 'read more' link in the links of a node preview? Having it at the end of the content, and having customizable text is, as it were, 'the bomb.'
• CAPTCHA - Needed wherever anonymous users can submit a form.
• Fivestar - Another way to add a community-like function onto a site without actually enabling comments or forums.
• Print, Email and PDF Versions - there is no better way to implement these three features than by using this module. It's easy to use, does its job perfectly, and looks pretty darn awesome to boot!

Whew! That's a lot of modules! Luckily, the site is only dependent on a few of them; the others simply add in niceties. I like keeping my sites relatively simple, and having too many module dependencies is never a good thing if you plan on staying agile and keeping the site updated quickly for security and performance. (As an aside, one site I work on is still running Drupal 4.7 because it used so many custom modules and non-maintained modules that it is cost-prohibitive to upgrade it at the current time).

The Rubber Meets the Road (a.k.a. Sleep = None)

During the first few weeks of the site being online, I have spent most of the workday, and from time-to-time a few hours in an evening, working on refining the front end of the site, tweaking content-creation processes, and making sure things are as spotless as I can make them. Even so, there's a lot of work to be done before I would consider the site truly finished:

• Training: I will be continuously training the newspaper's staff on how to do things quicker and better to make sure the site and layout don't get messed up.
• Future upgrades/additions: The newspaper will be moving to a new news content management system eventually, and the site will have to integrate with it to the furthest extent possible.
• Subscriptions: We decided to use a third-party module to manage PayPal subscriptions. Currently, lm_paypal isn't quite up to snuff in this area, especially for a site with over 75,000 users.
• Photo Galleries: There are 1,001 ways to do a photo gallery, but I chose to stick to a 'gallery-in-a-node' for the main galleries (using ImageCache + Lightbox), and am developing a user-submitted image gallery section using the Image module.
• Dynamic Redirects: There are still a few redirections that return a 404, but with a site as old as this one, it's almost impossible to get all the 404s cleaned up.

We also moved the site to an entirely new server a couple months ago (via SoftLayer). I had to spend about a day configuring the server and optimizing it for a well-oiled Drupal site. As part of the move, I also did quite a bit of MySQL tuning, set up APC, enabled the Boost module for static page caching, and turned off anonymous sessions in Drupal 6 (the site can now handle over 2,000 requests per second!).

The last thing I did after the initial buildout was run YSlow! on the site's home page to see what little performance speedups I could afford to make. It turns out I forgot to turn on component gzipping, configure my Etags, and set an Expires header properly. I went from a score of 45 to 72 (and 2.2 sec --> 1.8 sec page load from a cold cache) in a matter of a few minutes. Eventually, I'll also combine a lot of the CSS background images into sprites... but that's another project for another day. Want to make your Drupal site fly? Check out this great tutorial on Wim Leers' site.

Lessons Learned

I learned quite a bit during the development of this site, and as a result, I've been able to contribute a theme to drupal.org (Airy Blue). I'm reading through Pro Drupal Development and trying to learn more PHP so I can do more of the module development/tweaks in-house, and perhaps contribute back more often. I'm extremely grateful for all the help of the friendly people on Drupal's forums, IRC, and elsewhere, and I am excited to be working on a few other awesome Drupal projects.

Before I call it quits on this website, we're going to be integrating a new in-house content management system, "NewsEngin," and importing new news items, photos, etc. through the FeedAPI module. This should help with the print + paper production, and keep the two more in sync. I might also look into using Solr for search rather than built-in search. Solr seems like it would be much faster than Drupal's search.module for a site of this size (now 18,000 nodes + 76,000 users and growing).

You can check out my website, Midwestern Mac, LLC, for more on my adventures with Drupal, and you can often find me on IRC in the #drupal and #drupal-support channels.