One of Drupal’s greatest strengths is it’s huge catalog of modules and themes. At the time of this writing, Drupal boasts over 15,000 modules and almost 1,500 themes on Drupal.org. The challenge is knowing which modules, themes to use and how to maintain them with custom code and other customizations throughout the life-cycle of a website. While there are tutorials and blogs out there that can help, there isn’t exactly an instruction manual on which modules to use and which to avoid for production sites. The truth is that out of the large catalog of themes and modules, there is a much smaller subset of modules that are used over and over again by the community. When planning a new Drupal project there are many pitfalls out there that can cause real maintenance problems down the line and that is the problem is what I want to address in this article. It is my belief that many developers can gloss over this problem because ‘we can worry about that later’ and many CIO-types and business owners are unaware that the decisions today can dramatically affect the longevity of a website.
From my time as a developer, I have learned the hard way that not planning ahead can cause headaches later on down the line. I want project owners and developers alike to have a ‘maintenance first’ approach when scoping out their next project.
This blog will attempt to answer the following questions:
- How do I implement a project that can survive the next major Drupal upgrade?
- How much thought should we put into maintenance in general when we are planning a project or a new feature?
- Should we create a custom theme or sub-theme from 'framework' themes like Omega, Fusion?
- What modules should we use on this project? Which modules carry more risk related to maintenance and upgrades? What about custom code?
How We Got Here
When I was at Drupalcon Denver this year, one of the presenters noted how in the early days you could go onto Drupal.org and download every module to try out it. If you did that now you would be flipping through almost 400 pages of modules (This was the page I landed on which I clicked ‘last’ page. I got on board with Drupal somewhere around 2005 and I distinctly remember being able to flip through every page in the modules area. We no longer have that luxury. Now it’s google a module ‘idea’ or maybe search on http://drupalmodules.com.
We also weren’t enabling 100+ modules, it was a much smaller number. Now on enterprise websites, a Drupal site can easily have 100-200 modules installed (Many distributions in fact enable 100+ modules on install). How in the world can we make sure all of these modules are going to work together?
Another key difference for me is that the rate of change for Drupal major versions has gotten much larger in scope. A lot more stuff changes now from version to version. I predict the jump from 7 to 8 will be at least as big from 6 to 7. Drupal 7 was a turning point for me. Prior to 7 the upgrade cycle in my opinion was not as difficult. I do not recall the upgrade from 4 to 5 or 5 to 6, being nearly as dramatic as 6 to 7. Perhaps this is revisionist history, but I think it would be difficult to argue that a combination of the module expansion paired with the dramatic rate of change from version to version has made maintaining Drupal through version upgrades a difficult proposition.
Re-doing the Website is not Always an Option
I would love to see some data on the average life-cycle of a website in the sense of maintaining a consistent codebase. For instance Amazon.com has been around for years, but like most websites Amazon has a makeover every several years.
Somewhere north or south of 5 years is probably a typical life-cycle for a site when you think about a website’s codebase as well as the overall look, content architecture, etc. If you look at the Drupal project life-cycle of late, you can sense that a new version will come out every 3 or so years, with a year buffer for the new version to get adopted, and a couple years to phase out the old version. If a Drupal site is built in year 1 of a new version then you might get another 5 years of support before the site falls 2 versions behind, which means it is no longer community supported.
For some, there might be a temptation to just ‘wait it out’ a few years until the client wants a new redesign, site architecture, etc. and just completely revamp the entire site then. This is not always an option. Also, I think clients would be justifiably annoyed to find that the codebase cannot be upgraded without a complete overhaul.
Is this situation avoidable? Can a large Drupal implementation be constructed in a way that insulates it from ‘overhaul’ madness? This important question I will address in my next blog post.