Fenix on Open Source

I have a search I monitor in my Twitter client for “drupal“. As the awareness of the tool grows in traditional and new media (especially following the high-profile relaunch of whitehouse.gov), the relative backlash in the feed is startling.

I don’t really blame people, though. Drupal probably isn’t for them, and drupal.org and most Drupal advocates are doing a terrible job of setting expectations. So much so that I feel this trend of pushing Drupal onto everyone for everything is hurting Drupal’s reputation and perception.

Drupal is NOT in any way, shape or form a turnkey solution. You cannot download and install the package from drupal.org and get anything resembling a functional, maintainable website. Drupal is NOT a content management system, it’s a content management platform.

To most people that distinction is meaningless and does not adjust expectations. All one has to do is count how many times a day people ask on Twitter whether they should choose “Wordpress, Joomla or Drupal” to recognize where people’s expectations are when talking about Drupal.

When first installing Drupal 6.x, most people quickly realize:

• It has no WYSIWYG
• It does not generate search engine friendly URLs
• It has no media management
• Does not produce image galleries or embed video
• Has a confusing, cryptic admin interface that doesn’t distinguish itself from the user-facing site

To a user expecting something like Wordpress, Drupal looks like complete and utter garbage, and they’re quick to express this point of view on blogs, twitter, message boards, Facebook, LinkedIn and in comments on posts like this.

Drupal is designed this way intentionally (as counter-intuitive as this may seem). No two websites are the same, and so Drupal tries to make as few assumptions about what kind of site you’re trying to make as possible. Upon installing Drupal, the expectation is that the user then proceeds to head over to http://drupal.org/project/Modules, browse the buffet of functionality and proceed to “build your own content management system”… but no one tells the user that.

With the right amount of patience, research and experience, Drupal has the capability to produce massive, complex, highly customized site management tools for any size organization. This is the main reason many web shops are shifting their business toward providing professional Drupal services. In a nutshell, it lets developers build very customized sites for clients quickly and at lower costs.

There is much debate happening within the Drupal community about whether or not the current approach of shipping the core product with as little as possible is the correct one or not. Some feel shipping with a WYSIWYG and a more concrete set of metaphors is necessary for Drupal’s wide adoption while others feel this takes away from Drupal’s core strengths.

Whichever side of the fence you currently sit on, I think we can all agree that the current state of the messaging to new users sets errant expectations and new users may look upon the tool more favourably if they come into it with the expectation that upon installing Drupal, their job is only starting.

Acquia, Drupal founder Dries Buytaert’s commercial venture, is betting on their Drupal 7 based hosted service,Drupal Gardens, to start changing perceptions by demonstrating what a “productised” implementation of Drupal can do. Whether Gardens will help or hurt the cause remains to be seen as the product is in invite-only beta as of this writing, and Drupal 7 itself has not reached a stable release yet.

Even still, Drupal isn’t for everyone or every site, and that’s OK – I’m a big believer in selecting the right tool for the job. If you’ve found yourself in a position where you’re unsure about whether or not your organization is suited to jumping on the Drupal bandwagon, check out our literature on open source software, and/or give us a shout.

As anyone who has developed a Drupal site with devel module’s query logging on can tell you, a Drupal implementation can quickly get out of control when it comes to hammering the database. Personally, I’ve seen Drupal run well over 300 queries to render a single page. In a hosting setup where the bottlenecks exist at the memory usage and MySQL levels (which refers to nearly all non-dedicated hosting packages), this can quickly become a problem.

I’ve summarized a series of simple setup and configuration tips behind the jump that can help any site running Drupal 6.x improve performance and the subsequent user experience as a result.

1 – Disable Re-Building of Theme Registry

When a Drupal implementation is under development, themers and/or developers will often enable an option that forces Drupal to rebuild the theme registry on every page load. This registry tells Drupal what template files and overrides exist in the theme’s directory. This is a very costly operation and would cause noticeable slow down on any production website. It is important to disable this option upon going live. Under Administer > Appearance choose the Configure option for your theme and scroll to the bottom of the page. Make sure the option named “Rebuild theme registry on every page.” is disabled.

2 – Enable Page and Block Cache

Another simple option to enable is Drupal’s caching engine (Administer > Configuration > Performance). When enabled, Drupal will render the page and associated blocks once, and then save that result in the database. This can drastically reduce the number of database calls run on a page since the results are pre-rendered.

A point to consider about caching is that the more interactive the site is, the less effective the cache may be. Especially if complex permissions are at play, Drupal won’t be able to effectively cache since most of the page content may change depending on the permissions of the currently logged in user.

Drupal’s caching engine is most effective for anonymous visitors – if your site is mostly “read only” and doesn’t have visitors logging in, caching can make a dramatic improvement in site load speed.

3 – Increase Cache Lifetime

An option for some sites may be to increase the cache lifetime. This determines how long Drupal will hold onto a cached result before it will re-generate the page. If you have frequently changing content, you may want to set the cache lifetime to only 5 minutes, but if your content doesn’t change often, an acceptable value may be several hours.

On high-traffic sites, the less often Drupal has to re-generate pages, the better.

4 – Optimize JavaScript and CSS Files

Also in the Performance settings is an option to optimize both JavaScript and CSS files. When enabled, Drupal will consolidate all CSS and JS files included on each page into a single file, and compress the code by removing whitespace. This will reduce the overall file size and improve page load speeds.

5 – Disable Un-used Modules

Due to the staggering array of available contrib modules listed on Drupal.org, it’s common to download and install dozens of modules to test out and see if they meet your site’s needs. In the process of doing this, it’s easy to forget to uninstall the modules you don’t end up using. Additionally, the default install of Drupal comes with a minimum number of modules pre-enabled. Again, if your site isn’t using it, there’s no reason to keep it enabled.

Drupal will fire callbacks for all enabled modules which may come with their own database queries. Be sure to take the time to clean out your enabled modules list before going live with a site.

6 – Configure Cron to Run

One thing that’s easy to overlook is setting up Drupal’s cron tasks to run. Most web hosts provide a way to configure “scheduled tasks” or “cron jobs” in the hosting panel. Drupal’s cron.php fires updates for RSS aggregators, launches the search indexer, and any tasks defined in installed modules. In addition, it will perform some basic maintenance tasks like deleting temporary files and clearing logs.

The Drupal installation guide covers cron in detail with several methods for configuring it.

7 – Disable CCK Content Permissions

While this tip technically falls under tip 5, I figure it’s important enough to be explicitly outlined. The CCK module comes with several sub-modules. One of which is “Content Permissions”. This enables site administrators to set permissions on a per-field basis. Unless your site absolutely needs per-field permissions, this is a no-brainer to disable.

The less permission checks your site has to run the better!

8 – Disable Database Logging

Again, another one that technically falls under tip 5, but I feel is especially important is disabling the database logging module. This module will log a wide variety of actions performed on the site to the database. If you’re the only administrator, this module’s usefulness is greatly reduced and should be turned off. Alternatively, you can enable the syslog module which ships with core instead. This will write the more technical log entries to the server’s standard log on the file system and save the database queries.

9 – Use a Third Party Comment System

This one isn’t necessarily Drupal specific, but an easy way to off-load quite a bit of processing on a popular site. Since Drupal’s caching system is far more effective when only serving to anonymous users, if the only reason you have user registration enabled is to allow them to write comments, you may consider off-loading that task to a free third party service like Intense Debate or Disqus. A small clip of javascript is all you need to include into your template (or include it via a block), to embed a robust comment system into your site. Also, if your visitors read other sites that use Intense Debate or Disqus and already have an account (or use OpenID), they’ll already have an account to comment on your site.

As of this writing, there is a published module to add Disqus support as well.

Hopefully you find some of these simple tips helpful in keeping your Drupal-powered site running at peak performance! When it comes to scaling Drupal, these hints are only the tip of the iceberg. Drupal is perfectly capable of supporting large, high-traffic websites with the right environment in place, but we’ll save some of the more advanced server-side tips for another post.

Fenix announces the launch of another Drupal initiative, this time for Gennum Corporation, a leading Burlington based semiconductor company. Designed, developed and executed in under two months, the Gennum site was a significant Drupal endeavor requiring 15+ templates, 1500+ pieces of content, faceted search feature powered by Acquia, an innovative context sensitive block module, and laid the foundation for the development of the accompanying secure extranet which we will begin developing in the next few days.

“With each Drupal implementation our team impresses me more,” says Fenix Founder Jennifer MacKinnon, “and this project was no exception. The speed and sophistication with which we can deploy an enterprise class environment, complete with a complex feature-set and numerous custom components is exciting and we are happy to be able to offer this level of service, quality and professional capability to our clients.”

“Gennum Corp is a great company and we have enjoyed working directly with their team to see Phase 1 of this initiative to completion. Our two teams worked hard, but more importantly worked well together, mutually ensuring the success of this project.”

Adds Leanne Labelle, co-Founder of Fenix Solutions “Open source solutions are being more and more widely accepted, particularly by large, and international, organizations. Companies seek us out because of our Drupal and open source experience, passion and capabilities. The benefits of open source solutions are compelling and we are seeing a noticeable shift in thinking, resulting in the demand for our kind of offering deployed on open source software. It’s exciting for us to be leading this charge.”