A blog by the Brick Factory The Brick Factory

Five More Nifty Drupal Modules

Back in February I wrote about Five nifty Drupal modules we use, and I thought it was time to add to the list of the ones we have found very useful.  Please note that the availability of these modules may vary across the different versions of Drupal (5, 6, and 7), and in some cases module features and functionality differ some as well based upon Drupal version.

1. Boost

We have found that Drupal’s out of the box caching functionality is very helpful in improving the performance of our sites.  However, there are very few ways to configure the caching.  That’s why we like Boost; it allows us to configure caching more.  For instance, the module allows us to disable caching on specific pages while leaving it enabled on the rest of the site.  In regards to Drupal 6, it also has a much more efficient cache due to the fact that it is a file-based cache instead of the database based cache built in to Drupal.

2. ThemeKey

A theme is a basic design template for a Drupal site.  Drupal sites can have multiple themes.  In some cases we use one theme for the main version of a site while we use another theme for the mobile site.  However, there are times when a section of a site needs a different theme – regardless if it is viewed using a mobile device or not.  We recently implemented a blog section of a client’s site, and we used ThemeKey for that purpose.  There are many rules you can set up to govern which pages use which theme, and in this case we based upon the node’s alias.

3. Colorbox

On many of our sites we use pop-ups for splash pages, social share options, image and video embeds, and other similar content.  The Colorbox module provides such functionality and is very helpful when setting up pop-ups.  While this is not a surprise, it is nice that one can use css to modify an pop-up’s appearance.

4. Features

We are constantly tweaking and adding functionality to many of our Drupal sites.  Before we implement major changes, we’ll get them set up and approved by our clients first on our development sites before pushing them into our production environments.  Pushing new and reconfigured content types, modules, blocks, and similar features from a development to production environment is tricky at times since the environments are rarely truly synced.  Further, in some cases this requires that one remembers a multitude of changes to settings. The Features module provides mechanisms that aid in this process by allowing users to export new features from a development site as a module for installation in another environment.

5. Google Analytics

I’m not a big fan using modules for simple things like adding Google Analytics tracking script to sites.  That’s simple enough to do.  However, sometimes once you look closer, modules like this have a lot more to them.  For instance, this module allows you to control when the tracking script appears on the site.  One common thing to do is to not display the script for admin users.  Why would you want to track what you or your staff is doing on the site when what’s important are the actual site visitors?  This module allows you to control that.  Another cool feature is it allows one to add custom variables for custom reporting purposes using a very easy interface.  Thus, one doesn’t need to understand how to modify the script properly execute these changes.

What does a Sci-Fi site do when it is taken out by Frankenstorm?

io9 is a Gawker-owned site that covers science fiction and related culture, science, and other geekiness.  In an interesting turn of events, the Hurricane/Super Storm Sandy wiped out the power to the site’s data center.  Thus, the site went down.

It seems kind of fitting that a sci-fi site was blasted off the planet by some freak weather event nicknamed “Frankenstorm.”  That seems much cooler than them saying: “Sandy didn’t like what we said about hurricanes.  Then she knocked out the power to our data center.  She could’ve just left a comment on our site or tweeted her rage…”

In all seriousness, io9 (and its Gawker site siblings) found a decent solution.  Granted, the Gawker people likely freaked out when their data centers went down and their sites were displaying 503 error pages.  However, it is clear that they calmed down and thought of a way to continue despite the situation. The error pages now state what happened and now point people to their back up sites using Tumblr that the staffers set up to continue publishing content while the data center situation is straightened out.


For instance, the io9 503 error page now automatically redirects to the io9 Updates site; its introductory post io9 Has Survived Frankenstorm! states:

Welcome to io9’s emergency space station data center. When storms took out our New York City data center, we had to start broadcasting from low Earth orbit. We’ll be here for as long as it takes for the engineers working planetside to get io9.com back up! Welcome.

This was some smart thinking with a splash of the site’s personality.  I’m sure that Gawker will explore options in geographically distributing their hosting and data center solutions more after this mess all ends to hedge against another Sandy.

As I think about it more… io9 claims to come from the future.  I’m sure that the staffers from the future chose Tumblr to remain compatible with our “vintage” or “retro” (let’s give ourselves credit and not rely upon unhip terms like “obsolete”) technology.  However, if they truly come from the future, why didn’t they see Frankenstorm coming and prepare in advance by using data centers out its path?

Regardless if you and your organization can or cannot anticipate future events that seem straight out of sci-fi, following Gawker’s example won’t hurt if you’re caught in a similar situation.  Hat tip to the peeps at Hubspot for their recent Internet Outage Crash Your Website? The Marketer’s Response Plan post, too.

Living in a HTML5 World

Web development is sometimes like playing Whack-a-Mole. Since there are several different browsers (Internet Explorer, Chrome, Firefox, Safari, others) running on different operating systems, it is really frustrating to develop for all of them since each has their own quirks. Fortunately, the most recent versions of Chrome, Firefox, and Safari render sites enough alike that we rarely run into differences between them. However, when dealing with Internet Explorer 7, 8, and 9, the rules completely change, causing us to spend a ton of time tweaking sites to render correctly when using them. It is important to keep the differences between browsers  in mind when incorporating new technologies like HTML5 — the focus of this post — when performing web development work. Understandably, older browsers (even those that many people still use) do not support newer technologies, and accommodating older browsers should remain part of the strategy.

HTML5 is a new version of HTML that is continuing to gain more widespread adoption.  It offers web developers new opportunities, but older browsers — including IE 7 and 8 — don’t support it.  Further, since HTML5 is a evolving standard, browsers support different HTML5 features.  Even considering all of this, we have decided to develop features in HTML5 — even if we have to account for older browsers.  As web browsers and the Internet continue to evolve, using HTML5 is a must.

Another important reason why we’ve done this is to better conform to the rapid rise of mobile browsing. For instance, Apple’s iPad, iPhone, and iPod don’t support Flash, but they do support HTML5.

Here are three factors that we keep in mind when developing sites with HTML5.

Backwards Compatibility

So, if HTML5 isn’t supported by older browsers like IE 7 and 8, then how can we use HTML5?  Fortunately, there are workarounds for older browsers.  For instance, we have used javascript libraries like Modernizr to modify the HTML5 elements in older browsers so that they work.

There are times when such workarounds are not sufficient, and that is when it is important to develop an alternative version of a feature for older browsers.

Two Pronged Development

HTML5 uses elements like svg (scalable vector graphic) images well.  However, there are some known issues with such elements in some browsers.  For instance, in IE svg graphics don’t work well.  An example of an issue is when there’s a transparent overlay above the svg image  to add additional information to the image, the overlay prevents events that occur when one hovers over or clicks on a section on the svg.  Thus, when using a svg image for an interactive map, this would require a Flash version that is used in concert with browser detecting code set to display specific versions in specified browser versions.

Mobile Development using HTML5 and device specific apps

When it comes to mobile development, using HTML5 has its advantages.  For instance, by using HTLM5 developers can focus on one user experience versus variations between multiple versions of applications (one for iPads/iPods/iPhones, one for Droids, etc.).  For awhile Facebook decided to place major emphasis on the HTML5 browser version of its site so that it could more quickly update it across multiple mobile platforms. However, Mark Zuckerberg concedes that this approach has a significant negative side when he said, “I think the biggest mistake we made as a company is betting too much on HTML5 as opposed to native.”  That is because they did not write the HTML5 application in a way that was as efficient as it could be on mobile devices.

While Facebook still needs to focus on HTML5 since many people still access Facebook through their mobile browsers, it devoted “too much” attention to the HTML5 version of the site, and in hindsight Zuckerberg feels that Facebook did not devote as much attention to developing and improving its device specific apps as it should have. Recently, it has rectified that by releasing a new version of its app for Apple devices that has better performance.

It is important for organizations to make an assessment of their mobile strategy. How many resources should the mobile version of the site receive? If developing an app is deemed important, how much attention should that enjoy to ensure that the apps run smoothly? The answers to these questions will vary from case to case.

The cost of Search Personalization

Many Internet companies (like Google, Microsoft, Netflix, and Amazon) tout the virtues of search personalization.  By using a multitude of factors, the companies can provide more relevant information to a person.

I agree that there are benefits to it.  When I google “Montgomery County Public Libraries,” search engines can use my IP address – that indicates that I’m in the Washington, DC area – to assume that I’m looking for the libraries in Maryland instead of Pennsylvania, Texas, or Alabama.

However, as I noted in June 2011, Eli Pariser examines many drawbacks to personalization in his book The Filter Bubble.  Many of his points are about privacy concerns and more erudite qualms about web sites only presenting information that conforms to one’s world view, and Orbitz – the travel site – now provides a clear consumer protection argument against personalization.  The Wall Street Journal headline says it well, “On Orbitz, Mac Users Steered to Pricier Hotels.”  Basically Orbitz found out that Mac users tend to spend more on travel, and to capitalize on it, the company now presents pricier options to people using Apple products than it does to PC users.

Search personalization can both help us and work against us.

Drupal and WordPress aren’t Free

For the past few years here at The Brick Factory, we’ve fully embraced using open source content management systems (CMS) – particularly Drupal and WordPress.  Why?  Put simply: They work.  By using them we don’t have to start from scratch on building a web site and can focus on fine tuning the design and functionality of the site for our clients.  Although they don’t cost money to use like a commercial CMS, they do have costs.

Although we acknowledge these costs, we still believe that Drupal and WordPress are more economical than using a commercial CMS or building something from scratch since these same costs also exist for those options.

Here are some costs associated with Drupal and WordPress:

Creating a design – While there are many themes available for purchase, most organizations and businesses require a design that fully incorporates their existing branding.  This requires the work of graphic designers who can design an interface and then apply it to the CMS.

Configuring functionality – There are plenty of modules for Drupal and plugins for WordPress; they add specific functionality to a CMS.  However, they sometimes malfunction, conflict with other aspects of the site, or are unstable prototype versions.  That’s when it is nice to have some programming know-how on your side, and unless you’re a programmer, you likely have to pay one to help out.

Staying up to date – Open source CMS communities regularly update core CMS code and the associated modules and plugins.  These updates fix bugs, add and enhance functionality, and plug security holes.  Sometimes these updates require minimal effort, but sometimes they break aspects of the site and design.  Thus, programming and design expertise come in very handy sometimes.

Optimizing performance – Depending upon the complexity of a site, it can take some sites longer to load than others.  Sometimes this complexity is not tied to functionality or content, this can involve the configuration of the entire CMS.  There are plenty of caching options for both Drupal and WordPress, but enabling caching can sometimes break functionality on the site.  Thus, it requires attention to fine tune caching.  Further, I have seen plenty of CMS driven sites where the owner – not the developer – piled on modules or plugins but then either didn’t use them or configure them correctly.  An enabled module or plugin doesn’t have to be used, but even if it is not used, it does affect the performance of the site if it is enabled.  Optimizing site performance – through caching and module/plugin management, for instance  – can sometimes take advanced technical knowledge, and unless you have it yourself, you have to pay for that expertise.

Handling the “Oh, Crap!” moments – Recently I made a seemingly very minor configuration change to a module on a client’s Drupal site.  When I hit the save button, I got a blank white screen; the site was down.  It took our systems administrator about 15 minutes researching and working on the database to get the site partially back up.  It took him and a programmer another 45 minutes or so to get the entire back up again.  The process required yanking the module out via ftp and then figuring out how to remove any settings in the database since enabling the module again without clearing the database would take the site down again.