in-fisherman.com home pageMediacurrent collaborated with InterMedia Outdoors, Inc. to redesign their family of interactive websites using the Drupal content management system as a foundation. This required the migration and restructuring of content from several websites hosted by a legacy content management system (CMS.) The result was a fresh, modern web design and a social network that allowed Intermedia’s users to access a vast repository of content quickly and easily. This case study focuses on www.in-fisherman.com, the first website Mediacurrent developed for InterMedia Outdoors, Inc.

Company Profile

InterMedia Outdoors, Inc. (IMO), is the leading multimedia company serving the needs of outdoors enthusiasts. The IMO brand boasts the largest network of websites (16 total) dedicated to hunting, shooting and fishing; a portfolio of 15 magazines including powerful brands such as In-Fisherman, Florida Sportsman, Guns & Ammo, Petersen’s Hunting, and Fly Fisherman; 25 market-leading television productions; 2 syndicated radio shows; 200+ hours of television programming and one television network – The Sportsman Channel. InterMedia Outdoors serves the interests of 80 million devoted sportsmen in the pursuit of their passions.

Challenge

In-Fisherman.com is the premier online destination for anglers worldwide. The site serves to complement the print magazine In-fisherman, a 30 year staple in the outdoor publishing industry. In-Fisherman.com was initially built using a proprietary CMS that was inflexible and troublesome to customize - features such as social networking and tagging were difficult and time consuming to implement. However, these challenges played into the strength of Drupal.

The aggregate site traffic of IMO’s portfolio of sites reached nearly 100 million page views during the first 6 months of 2008, and numbers continued to climb. More specifically, the In-Fisherman.com site averages 67,789 user visits, 266,379 page visits, and an average of 4:1 page visits/user visits in a typical month. Thus, scalability was at top of mind throughout the project.

Why Drupal?

The decision for IMO to use Drupal came after an unsuccessful attempt to build out In-Fisherman.com with another CMS. The deciding factors for selecting Drupal were:

  • Scalability - Drupal was perceived as the most scalable and extensible open source option.
  • Cost - No licensing fees.
  • Multi-site / multi-database architecture - Drupal’s flexible multi-site configuration would allow IMO to store content and user data in multiple databases for a single site. Multiple databases would keep distinct areas of the site operational in the event of database failure from server load. The user data is stored in its own database and the gear/angler/www sites are set-up to seamlessly pull user data from that separate database.
  • Hosting - The expected traffic for the site demanded a low-cost enterprise level hosting environment. Drupal and the LAMP stack were a natural fit.
  • Flexibility - IMO's previous CMS was inflexible, making it difficult to implement new and innovative features. Drupal’s modular framework, API and theme override capabilities made it the top choice.
  • Theme customization - Drupal’s separation of presentation and business logic through the theme layer allowed the In-Fisherman.com UI to undergo significant revisions during and after development.
  • Active development community - A fragile economy encouraged open source software vs. a proprietary vendor solution. IMO was looking for a community with solid leadership and momentum. In addition, the Mediacurrent offices were local to the project stakeholders and allowed for enhanced interaction.

Goals

In our initial planning sessions, several primary goals were indentified. The most important success factors included:

  1. Usability - Create an engaging web experience for users by leveraging IMO’s vast repository of sportsman-related content and video. The new site functionality would take user participation to a new level.
  2. Branding - Provide a more modern, contemporary look and feel that reinforced the magazine brand.
  3. Content - Give anglers the ability to quickly find the information they’re seeking by using a well defined taxonomy structure and lists of articles tailored toward a user’s individual preferences. This needed to work for both anonymous and registered users. The objective was based on articles the user has previously visited as well as interests specified in a registered user’s profile.
  4. Scalability - Build with scalability in mind. IMO has several high traffic sites in their corporate umbrella. Careful consideration needed to be given to scaling, isolating points of failure and configuring the site to fail “gracefully.”

Hosting Architecture

In-Fisherman.com needed to handle thousands of page views per day. The hosting environment required the ability to balance anonymous page requests, authenticated page requests and traffic spikes effectively. IMO’s system administrator spent months of research, planning, and devising an internal hosting infrastructure that was enterprise caliber. The hosting architecture consists of a series of shuttle servers storing cached content, a file server and a dual database cluster. Page requests are routed through a Cisco Load Balancer. The balancer identifies a shuttle server that’s “open” for serving the input based on the number of requests it’s processing at that time. Stress tests on the enterprise server architecture proved that Drupal was more than capable of handling. The idea of using memcache or Xcache was tossed around, but abandoned in the end, because the hosting environment’s performance testing exceeded requirements.

Hosting Architecture diagram

Development Process

IMO’s team developed the initial requirements document, which was beneficial. Mediacurrent adopted an Agile methodology for developing the site. A team of 2-6 developers simultaneously worked in conjunction with IMO’s management team throughout the process. Development progress was tracked through the open-source project management tool called Active Collab, and its web-based ticketing system. Active Collab’s commenting feature helped the Mediacurrent team collaborate effectively. There is no shortage of other project management tools out there, but for what it is worth we felt Active Collab fulfilled our needs. Overall, task management and dialogue between IMO and Mediacurrent was primarily handled by a project manager, and frequent updates were exchanged on a daily basis. Weekly stand up calls with IMO stakeholders provided an opportunity for more formal question and answers, and for valuable debriefing time.

Design & Theming

Intermedia Outdoors tapped a New York-based agency to create the user interface design for the site months before Mediacurrent started site development. Mediacurrent chose the Zen theme to adapt the In-Fisherman.com design. The Zen theme dramatically cut design time. As requirements shifted, the highly relevant CSS structure of the Zen theme allowed for impromptu changes to the UI without breaking page layouts. Mediacurrent also built several custom modules to streamline theming.

The custom content module was used in place of Panels (at the time Panels 6.x was not recommended for production use). This allowed for complex content presentation on the front page and species channel pages. Several custom Flash-related modules were written to provide XML data to Flash widgets across the site. These modules create XML data based on taxonomy. Mediacurrent’s final theme was extensible and flexible enough to withstand numerous IMO design changes just before the site’s alpha release.

Significant Obstacles & Solutions

As with almost any sizable enterprise site there were some challenges to overcome. The most notable included:

  1. Timeline - Developing 3-4 enterprise class sites in a compressed timeframe (5 or 6 months).
  2. Limited information architecture specifications - Project stakeholders met often to discuss items such as data query logic for blocks and layout format of node edit pages. The use of a ticketing system helped the process tremendously.
  3. Multiple themers - With several developers involved in theming, the team needed to coordinate everyone’s efforts. Team members notified each other via IM whenever new CSS classes were created so as not to duplicate effort.
  4. Search - For a general site searching, the Google Search Appliance (GSA) was used. Mediacurrent had to modify it according to client requirements, which called for sorting by criteria unavailable in the standard GSA. The solution was to limit the number of results, which were then reordered if the default sorting was not used. Mediacurrent also added a theme function so the result set would match the user interface design.
  5. Sharing Data across multiple domains - The In-Fisherman.com site uses several databases to support high-volume traffic. The technique used relied heavily on Drupal’s multi-site configuration. Drupal points to a particular database, based on the subdomain of the URL. This posed a problem for blocks that presented data across multiple subdomains. IMO didn’t want to make database calls from one subdomain to another. To solve this, Mediacurrent created a set of modules that would “flatten” a block’s content to a serialized array and store it in a flat file. Thus, block content on one subdomain could be read by another subdomain without a database request. Another challenge of multiple domains is making Drupal’s menu system point to the correct domain when routing a page request, without having to use absolute URL’s. Mediacurrent created the Multidomain module to pass navigation and /user paths through a custom_url_rewrite_outbound() function. A switch statement in the function assigns the correct domain for a given path. Without this module, absolute URL paths would have to be written everywhere to accommodate multiple domains.
  6. Optimization of multipage nodes - The article content type needed to present up to 6 pages of content. Mediacurrent decided that the pagination module would not meet IMO’s specific requirements. Our development team employed multipage articles, using a combination of theme overrides in template.php and customization in the node.tpl file. For search engine optimization, the article URL’s needed a page number appended to the path instead of appended to a query string. This was challenging because Drupal perceived the additional argument as a new path alias. The development team wrote a custom module to intercept the clean URL and detect a page number at the end. The page number is stored and Drupal redirects to the node page.
  7. Data Import - IMO had lots of content (1200+ fishing articles) to be imported. Prior to Drupal, the IMO editorial team managed these articles in FilemakerPro. IMO’s team created a PHP script to parse a FilemakerPro XML file and generate a CSV file that was compatible with the Node Import module. The wide array of metadata required that Node Import and various other modules such as File Field and Image Field to be customized extensively. Once these modifications were complete, Drupal processed the import to completion in an hour. Images were uploaded via FTP to the development server and placed in the “files” directory.
  8. Enterprise level hosting and establishing fault-tolerance - To meet In-Fisherman.com’s stability needs, the IMO team configured a hosting architecture that did not require additional optimization and caching modules. Multiple databases for content and user accounts ensured that the site degraded gracefully in the event of database failure. IMO’s system architect devised a technique to accomplish this by leveraging Drupal’s multi-site capability along with prefixing table names with database names in the site’s settings.php file.

Module List

The In-Fisherman.com site used a large, diverse set of contributory modules – thank you Drupal community. There were staples like CCK, Views, PathAuto and Imagecache, as well as an assortment of others. DrupalModules.com became a terrific resource for module reviews, release state and descriptions. Some of the other more noteworthy contributory modules included:

Nice Menus: This easy-to-configure module gave the site’s primary navigation a set JavaScript drop down menus.
Fivestar: Allows site users to rate content.
Workflow: Gives content contributors the ability to promote content and have it approved by an editor before it’s published.
Transliteration: This module “sanitizes” file names for user uploaded content, helping oddly named files become readable by the file server.
String Overrides: Gives site administrators a simple way to replace text that’s passed through the Drupal API t() function.
TinyMCE: A WYSIWYG editor that gives content contributors the ability to style web site copy.

Custom Modules

Developing the site involved extending or completely customizing quite a few modules – many of which will be contributed back to the community. Here is a summary:

Alternating Content Background Manager: This allows site administrators to update the background images used by an accordion flash widget without having to update XML manually. New images are saved to specific filenames referenced in the XML.
Block Flattener and Block Flattener Reader: These modules allow block data to be shared between subdomains without directly accessing a database for block content.
Gear Related Articles: This module outputs block content to a flat file for sharing across subdomains, similar to the Block Flattener module.
Profanity Input Filter: This provides rudimentary, context-based input filtering via a modifiable set of rules. Site administrators can insert custom string rules of prohibited content. The module then replaces the prohibited strings with asterisks.
Fish Profile: Adds radio button-based fields to the profile form and reorganizes the fields.
Gear Related Articles Export: Saves block data to a flat file for use by blocks in other subdomains thereby reducing cross domain database calls.
IMO import Fix: A helper module that assists in correcting file paths, taxonomy assignments and string replacements during the article import process.
In-Fisherman Form Alters: Handles all form alter logic for In-Fisherman.com.
Multidomain: Manages the subdomain links for a multi-site Drupal install.
Node Process: Processes node page calls, allowing nodes to have multiple pages.
Profanity Input Filter: Provides an input that can filter profane words or phrases based on a set of rules.
Solunar Month: The In-Fisherman site provides solunar calendars, which provide the best lunar fishing phase in any given month. This module supplies the solunar_month content type for the calendar. CCK couldn’t be utilized because the number of fields required by this content type consistently maxed out PHP’s memory allocation when loading the node edit form. The module also supplies a dynamic XML menu item for a given month and year together.
WWW Advanced Search: Generates an advanced search form page, containing category-based filters.

Training / Documentation

Training and Documentation site Documentation was implemented using a Drupal intranet that could be referenced and updated by IMO staff, while development was simultaneously taking place. The online nature of the documentation enhances knowledge transfer and allows for commenting, interaction, and help updates far faster than traditional methods.

The site uses the book module to organize topics in a “tree” structure. A tagging scheme allowed help topics to be displayed by subject. A WYSIWYG editor (FCKeditor) makes editing easy and efficient for neophyte staffers and provides easy uploading of screen grabs. Terms and concepts between help articles were extensively hyperlinked, allowing users of all skill levels to drill down to the appropriate level of detail.

The documentation was written with the layman in mind (i.e. new user/developer to Drupal). This is more difficult than it sounds, because as developers get more entrenched in the project, they tend to forget the issues that stymie beginners. The availability of content in a web environment was seen as being more beneficial and user-friendly than a traditional training manual in paper or PDF form.

Each help topic was summarized, then interviews were conducted by the documentation specialist to determine the details of module dependencies and logic flow.

Lessons Learned...For the Next Time

Here are some takeaways from the project for developers and corporations (especially publishers) who are contemplating Drupal for a sizable implementation:

  1. Break the project down into chunks – there were are a lot of moving parts and concepts; keep the core group of stakeholders as small as possible to streamline decision-making.
  2. Use a proven recipe of modules – although we did a lot, avoid customization whenever possible.
  3. Acquire original source code from all third-party front-end widget developers as soon as possible. Upon receipt, immediately test to verify Drupal is “talking” to the widget correctly and vice-versa.
  4. Orient designers on the “Drupal way” and overall theming best practices. Have your development team review designs during the creative phase to ensure the designs reflect features and functionality established by the selected module set.

About the Developers

Mediacurrent is an Atlanta, Georgia based interactive firm that has developed a specialization and consulting vertical within the free, open-source content management system (CMS) called Drupal. Mediacurrent offers strategic direction and tactical implementation of an array of creative and technical solutions. For more information regarding Mediacurrent’s services and portfolio please visit www.mediacurrent.com.

Comments

skullcap’s picture

Nice lay out the automatic starting video and sound is kind of annoying though and the flash is hard to wade through to find the articles.

I also noticed the “The In-Fisherman System” comes up blank in IE and seen not to run right in FF.

I love going fishing and am into the subject but would probably click x when the auto video starts and I see the flash.

heinz.wegener’s picture

The In-Fisherman System comes up fine in IE6 and IE7 for me, and runs fine in FF for me. What version of FF are you using, and what version of the Flash plugin are you running for these browsers? Any other details you can provide would be extremely helpful so we can determine exactly what is going on and so no one else experiences these same issues.

Thanks for the feedback!

skullcap’s picture

I have FireFox 3.0.7 now I get this notice where the flash players should be-

“”Featured articles

In order to view this Flash widget, you need to download and install the latest version of Adobe Flash Player. Follow these steps to download and install the player:

1. Bookmark this web page
2. Go to http://get.adobe.com/flashplayer and follow the instructions.
3. Re-open your browser and go to this bookmarked page.””

I tried to down load the exc. File from the provided link and it wouldn’t install for me, but didn’t spend much time on it.
I just use FF to read code and test sites.

kaakuu’s picture

Firefox says it blocked a pop-up. This is annoying although I am not a fire-fox fan. The other problem is that sound starts by itself all very loud with apparently no control to stop it. The contact link tries to open Outlook where ideally it should be a webform.
Otherwise a very attractive site.

chason’s picture

Can you point out the page that has the Contact link that opens in Outlook so we can get that fixed?

kaakuu’s picture

It is the very first page or the home page or the index page.
Further pointing is not possible as it has no node number or any other attributes.

But I will try - it is approx 280px from left margin and 70px from top margin
besides the In-fisherman logo on the top left corner and below the word Beta -
there is a contact link which says "Report a Problem" - it links to mailto:webproblems@imoutdoors.com?subject=Problem(s) with In-Fisherman BETA site

Drupal has Contact form in the core or if you do not want it other ways and modules.

chason’s picture

Thanks for pointing that out! I'll take note and review this with the development team.

escoles’s picture

You say:

Hosting - The expected traffic for the site demanded a low-cost enterprise level hosting environment. Drupal and the LAMP stack were a natural fit.

This is counter-intuitive for me. Could you expand on what you mean by this? From your architecture description it sounds like you're co-locating, but that doesn't sound like what you're describing here.

chason’s picture

A co-location facility is used for hosting, but it's basically just housing the hosting hardware. Does that answer your question?

kwinters’s picture

This is similar to the setup we use. The colo is really just so we don't have to deal with things like the backup power supply or swapping out a failing hard drive. We manage all of the software on the servers ourselves.

escoles’s picture

That helps. I construed your phrasing as meaning that you were using commodity hosting, which to me is shared-server or VPS.

Jordan.Schmitt’s picture

You guys did a fantastic job. Thanks for the write up. Did you guys explore the "boost" module for anonymous users?

stlrealtor’s picture

Great Website, I really like the layout. I hope to catch a fish here in Missouri that I can send to you. My buddy caught a large mouth bass at a pond in Chesterfield that made the Bass Pro Shops website for a few days. pretty cool, except I dont think they are made in drupal.

chason’s picture

We did not explore the boost module. I think it was still in dev when we started load testing about 5 months ago. Thanks for the tip though, we'll have to keep it in mind for the next site release.

Cool_Goose’s picture

Is that server structure only for in-fisherman.com ?
If so that's a huge resource waste for a website that does 68k unique visits monthly.

If not what's the monthly visitor average on that ?

JohnForsythe’s picture

The aggregate site traffic of IMO’s portfolio of sites reached nearly 100 million page views during the first 6 months of 2008

I believe that setup is for the entire family of sites. (if not, it does seem a couple orders of magnitude too much hardware..)

Cool_Goose’s picture

So that's 17 mil pageviews per month. Well that sounds more sane if so, especially if they are heavy on file distribution (images, videos etc).

chrishaslam’s picture

Yep a MySQL cluster and load balancing for 250k impressions is just a little overkill it's obviously for all their sites touching 20m impressions ;)

Always interesting to see more detail on the hosting side such as hardware specs, the MySQL cluster and the CDS

Cheers

---------------------------
Managed Drupal hosting from Ixis IT

drupalninja99’s picture

I am working on other IMO sites and their setup is for their family of sites, not just in-fish (at least the ones being ported to drupal, to my knowledge).

jkmickelson’s picture

This architecture, as-presented, can handle 220 million pages views per month of dynamic content, or 6.7 billion pages views of static content. The scaling is 100% completely transparent to Drupal and requires no modules or changes to the core or LAMP stack. This means that the Drupal developers have no caching or module issues to contend with.

Additionally, even if the web-facing "shuttles" should become sluggish due to exceptionally high traffic, the internal facing CMS remains responsive for the corporate employees (editors, developers, etc). Scaling is fairly linear by adding additional web-facing shuttles.

The "other" earlier, proprietary CMS used the same level of server resources, but could only handle one site - barely.

- JKMickelson, Systems Architect - Enterprise level.

for further reference, see: http://drupalee.com
and http://jkmickelson.net/books/drupalee-drupal-enterprise-edition-drupal-6

reaneyk’s picture

Great article with a good example of how Drupal can be scaled using an enterprise architecture to fit the needs of high traffic sites.

Thanks!

saltcod’s picture

Good site - thanks for hte case study.

Though this is a technical review, I had some comments on design. I think the site would greatly benefit from a better outer-content wrapper. On the frontpage, the elements aren't being wrapped together enough. I'd like to see a white/#f1f1f1 wrapper with a hairline gradient border for adding depth.
http://moblin.org/documentation does this very well.

I'm not to be nitpicky with this, but I do think that the design could use some finishing touches, and that the site still looks a little half-finished.

Again, I'm trying to be critical with this, not negative.

Thanks,

Terry

barryQ1974’s picture

Pretty awesome looking site. Usually outdoors sites and fishing sites are very poorly designed and coded, this is like the BBC of fishing sites lol

cbh’s picture

Great article! Just curious, was the previous CMS another open source product, or some "retail" package?

Thanks!

Mediacurrent’s picture

@ cbh - Thanks for the kind words about the site.

The other CMS was not open source - I'm trying to be diplomatic, but it was a fairly well-known, proprietary package. The Drupal advantages were really significant when stacked against this other CMS. We can elaborate in more detail later, but did try to explain the "why factors" to other organizations contemplating Drupal for an enterprise level site.

flavor’s picture

I built http://www.coastsidefishingclub.com using drupal and vbulletin its been around for 6 years now - just updated the drupal side with a new theme.

This club has become very involved and well known in northern ca fishing circles.

J -

doeboy’s picture

No doubt you guys can can build an amazing website. I have one small but considered negative comment. The most popular sites on the web are very simple, google home page being the most simple and most popular. The site just makes me a little dizzy and if your aim is the fisher person it maybe a small over kill.

simonjo’s picture

very nice site. can you build ecommerce sites with this system ?

Simon Jones

chason’s picture

Yes, there are a couple of ecommerce modules for Drupal:
e-Commerce
Ubercart

drupalninja99’s picture

I've used ubercart in a couple sites and I love it. It's a very flexible system and I'm launching a subscription-based site soon using ubercart's recurring billing options (powered by authorize ARB).

matthylland’s picture

Can you (or anyone) tell me how you got that "subscribe" contact form on the right sidebar?

Great site, congrats!

josh.estep’s picture

@matthylland

The subscribe block is generated by a view that returns the most recent subscription image. This allows these images to be queued. As the image is the only thing that changes, everything else is static and the XML for the flash widget is located in a static file.

LoveCharge’s picture

great site and great presentation congrats!

DeeZone’s picture

Interesting solution to a multisite need for sharing of data.

Sharing Data across multiple domains - The In-Fisherman.com site uses several databases to support high-volume traffic. The technique used relied heavily on Drupal’s multi-site configuration. Drupal points to a particular database, based on the sub domain of the URL. This posed a problem for blocks that presented data across multiple sub domains. IMO didn’t want to make database calls from one sub domain to another. To solve this, Mediacurrent created a set of modules that would “flatten” a block’s content to a serialized array and store it in a flat file. Thus, block content on one sub domain could be read by another sub domain without a database request.

A few questions:

  • My understanding is that you created a custom caching solution (generation of flat files) for shared blocks across the multisite. Why did you take this route when you could have use Drupals multisite configuration options to connect to several databases, build the block contents and cache the results? Granted there would still be some custom code to switch the database connections (I think) but it would seem to be closer to the built in architecture/configuration of a Drupal multisite install.
  • Does your custom block caching (flat file generation) code deal with the generation of content for anonymous vs logged in users differently or perhaps it wasn't necessary?

Thanks for project summary, interesting stuff!

drupalninja99’s picture

The client had a drupal developer on staff who championed the multi-site configuration. They wanted the databases for each domain to be totally separate so that one could go down and the other still be up. Now while that is technically possible the databases are on the same server and use the same mysql instance so it's more likely that mysql crashes and all the dbs go down. So understanding that thought is why we did mostly sharing of blocks through block caching which keeps that database independence at least in theory.

I don't think we had to cache blocks with different states on that site, though I could be wrong. I do agree that changing the db handle is a pretty easy way to share data across domains. That would generally be my advice for how to handle sharing of data.

jkmickelson’s picture

The purpose for multi-database was not for mySQL crashes. It was for speed of database recovery when an outside or internal user corrupted content (unintentionally or otherwise). When using the earlier, unnamed CMS, that primary developer erroneously overwrote some data tables in that "other" CMS. A restore from tape was required, and that developer was not able to merge the remaining current good tables with the restored older tables. Several departments lost a few man weeks of effort as a result. The consequences would have been worse if it had been a live site with users posting their comments and interacting in the forums.

As a result, I decided to keep editorial content, specialty and internal content, and user content separate from one another. This greatly simplifies the recovery process when the data center is asked to restore a single mySQL DB containing only the relevant information. There is no need to reconcile internal tables and various content ids. Only the affected content is restored and the remainder of the site remains up and running while such an event is diagnosed and remedied. This is not simply a corporate web site design, but a fault tolerant enterprise design that accounts for business continuity as well as for the level of expertise of the personnel affecting the restore process.

- JKMickelson, Architect for the original system architecture, called "DrupalEE."

http://drupalee.com

dalegrebey’s picture

Nice site... Consider trying to optimize your site. For example /admin/settings/performance/ - Combine your CSS file together and Javascript together for less server requests. Also make sure that you are running Cron. If not automatically through your server, than manually occasionally (or perhaps look at poormanscron). Some of the information seemed like it could be cached better to make it load faster for the end user. You can also download the YSlow Yahoo plugin for Firefox to help see where you can improve load time.

I like the site.