Ever heard: All I wanted was to update my modules - why did my site crash?!


Israel Office



Europe office


Ever heard: All I wanted was to update my modules - why did my site crash?!
submitted by: Zohar Stolar
One of our clients mailed me with an urgent problem: His site crashed! Quoting (bolded made by myself):
The amount of testing we need to do with each update makes it almost impossible to keep updating risk free. We would have to test for so long, that by the time we're done, the next module will be ready. It's just too complex a site with too many contrib modules. Maybe if we had a full time person just on that. Despite what the "community" says, my tendency is to only update security changes.
Looking at the error message, it took me less than a minute to tell him the writing was on the wall... Well, maybe this is a too obvious case, but let's admin it - maintaining a Drupal site and keeping it up to date, is not always that easy. We all have other things to do, and keeping the site with the latest versions of module X, is not always a top priority. How should one do, to keep his site safe, and his soul sane? There's no one good answer, but for most of site owners, who are not full time Drupal developers, here's a bunch of advices:
  • Don't install modules you don't need - stick with the minimum. Every additional module obviously adds some more tasks and maintenance to the overall.
  • Don't update immediately - verify the update contains the fixes you need, and the features you were missing. If there are new features - test them first. Updating only when a security update is available is not necessarily wrong.
  • Read the release messages - they contain valuable information about changes that might affect your website
  • When in doubt - search for more information about the module, and about it's maintainer.
  • When still in doubt - read the module's code, and face it with your suspicions
  • Sometime in the future - let some 3rd party solution, such as Carbon, or Spokes manage the updates for you. Deal with your site's content and strategy, and not with it's platform.
Drupal 5 Modules Chart, By Kent Bye
One other point worth mentioning, is that testing is becoming an integral part of coding for Drupal core, and will hopefully drill down to contrib as well. This will make releases of modules less bugful (or more bugless). So have no fears! Your platform is mature, and so does it's community. It is not free from bugs and mistakes, but it deals with them properly. Nothing is being swept under the carpet, and the improvements are being proposed and put into action not only for modules, but also for their development and the discussions around them (man, we have 2(!) annual meetings!).


"Despite what the "community" says, my tendency is to only update security changes."

"community" says: use Update status advanced settings then.

Despite what the "community" says, my tendency is to only update security changes.

This is our policy. We run dozens and dozens of sites, if a new update doesn't fix a bug that we're experiencing, or have a new feature that we need, we don't install it. Only security updates.

One other item that is missing from your list is "Use a development server to test any updates before updating your live site". I know moving changes from dev->staging->live is a royal pain in the ass, but isn't breaking your site worse?

Amen. The dirty little, unspoken secret in Drupal is that with thousands of contrib modules, there is no way that they are tested in combination.

The two things that you can do to mitigate this are: Keep the number of contrib modules that you use to a minimum; and Use a staging server to test new updates. It might be hard to do the former, but the latter is a must.

I know it is a figure of speech, but try to avoid the phrase "dirty little secret" here. Secret implies that folks are will fully withholding information. I have never seen that, and I'd be surprised if you have too. And dirty emphasizes that there is some nefarious intent behind the secrecy. In all, this phrase is extremely counter productive to Drupal's growth and reputation. It has no basis in fact. You have a valid point, but please state it more thoughtfully.

I wonder how far acquia will take the "combination" testing of their supported modules.
They will support several modules (at least 50) in their distribution and as the requirements rise from their clients the numbers will raise as well (there are hundreds of packages in a linux distribution).
Now because of the hook system any module can alter the behavior of the system but it can do so differently if it will have a similiar hook run by a different module before or after.
So to 100% foolproof test the system they will need to test the systems in a vast number of configurations my math is pretty lame but when notching down on paper the combinations that arise from 4 components in different configuration I get 8 combinations.
What this means is that Acquia will need a MASSIVE virtualization setup creating hundrads and thusands of possible configurations to prooftest 100% everything.
The question is if they will expose testing information to the larger community ( I vagually remember that spikesource did that but could not find any note of that in their currewnt sites).
Anyway I think exposing the test outcome will server as a good marketing strategy because they can address the anxiety of clients (like our client Zohar described).
This is certainly the mission that the Acquia team took upon themself - now the only question is - Will they deliver?

Add new comment


Welcome popup block