CiviCRM needs to work securely with Drupal 6 for a couple of years not a few months

2011-06-08 23:56
Written by

My UK based organisation the Association for Learning Technology launched a brand new web site on 20 April based on Drupal 6 and CiviCRM. We are very pleased indeed with the overall result and having all our membership process now running within a unified web-based environment we've been able to reduce transaction costs and give our individual and organisational members a much better service all round.

For a small charity like us, the development of the new site and transitioning across to it from our previous systsm was a major but very productive challenge; and we are now "set up" for the future.

Yesterday we held a review meeting with our hosting company Positive Internet and our developers Futurate. We considered a timetable for eventually migrating to Drupal 7 and concluded that we should plan this in late 2012 and probably do it in late 2013.

We are alarmed at the prospect that CiviCRM will cease to be maintained for use with Drupal 6 much sooner than this, and we think that other organisations that are reliant an Drupal 6/CiviCRM should be alarmed too. We know that Open Source software does not grow on trees, and we believe that users of it should be prepared to contribute to the maintenance and development of OSS, particularly if, like us, they do not do employ staff who can be part of the development process.

There is a "Make it Happen" to extend Drupal 6 and Joomla 1.5 support. We think this support will be needed, in practical terms, untill well into 2013. Though we will be contributing to the Make it Happen, and though we would urge organisations that have Drupal 6 and CiviCRM at the heart of their operations to do likewise, we think that a further 18 months of extension, to, say Septebmer 2013 will fit much better into the practicalities of the Drupal 6 to Drupal 7 migration. What do other users think?

Alongside this we are interested in liaising with other organisations using Drupal 6 / CiviCRM with a view, potentially, to some "lightweight" coordination and pooling of efforts on the migration to Drupal 7 / CiviCRM.


Seb Schmoller, Chief Executive, Association for Learning Technology






Filed under
Click thumbs up if you thought this blog post was useful (login to vote or to comment)


One problem with the current MIH is that so far there are only large donors. I have a feeling that although seed funding really helps to meet the target seeing that 3 people have donated over $1000 each doesn't really encourage smaller donations. So, if you are reading this & feel you could put up $10, $20, $50 or $100 without flinching I encourage you to do so straight away - I fact writing this comment I just talked myself into doing just that & the average donation is now under $1000 :-)


I heard a saying recently - "He who gives early gives twice"

maybe we should consider a separate MIH that extends support for J15/D6 for security revisions only. so assuming the current MIH is fully funded, we'll have v3.5 released with v4.1. at that point, support for J15/D6 with C35 may extend for a year, but only address security or data-loss related bug fixes. The v4 cycle will continue and add new features.

I'm guessing the budget for that would be more reasonable, and it would help orgs ensure that they can remain with the 3.5 version on J15/D6 through end of 2012, and not be pressured to upgrade.

@lcdweb That sounds like a feasible way forward. One issue for me is the assumption that people know about and understand the roadmap for CIVI. I certainly don't. And for medium to large organisations who might see the sense in committing some proper money to this or a different MIH, the person or group that approves the financial committment needs to understand the decision in business/security/functionality terms, not in "version this or version that" terms. Is there someone in the community would could provide such a summary?

I'm happy to help try and "translate" between tech speak and business impact terms, so do contact me if there are other bits that need explaining - you can message me on the community forum.


In this case, the key issue is that if security flaws are discovered in the version of the software that most charities are running, the developers' recommendation will normally be to upgrade to the newest version, which costs more than many charities can afford. This Make-It-Happen initiative will allow security flaws to be fixed for everyone without the additional cost of paying a consultant to help you upgrade. (Small security flaws are regularly discovered and fixed in any software - CiviCRM and Drupal both release patches several times a year, just like Microsoft regularly sends out patches via Windows Update.)

A while back, I posted in the forum about this, but aside from the ever-present and helpful Lobo, I got no response.,19761.msg82384.html#msg82384

Security is the biggest problem, in my opinion. I have a pretty specific plan in there that I believe would mitigate this problem if it were adopted by the community. Specifically, it would mean that security updates would be provided to a CiviCRM version that works with the oldest currently supported Joomla! or Drupal version. Thoughts?


Lots of good sense being spoken in this thread.

I've been aware of the plan to close support for D6 for a while and i guess i've just ignored it up until now. I  look after a number of D6/Civi sites for clients and projects I'm involved in, and for at least some of them upgrading to D7 simply is not an option - there are too many dependencies on contributed modules that are not being upgraded to D7 anytime soon. To say nothing of the time and cost involved in moving to D7.

Consequently an approach whereby support for D6 is limited to security issues is fine by me. I've always thought that Civi development often pushes a little too hard for new features, where a focus on getting what's already there working better might have a higher priority, but them I'm not actively involved in developing the software, and I guess I can appreciate that it might well be a whole lot more interesting creating new features.

I fully support a security fix only future for D6 support - and am able and willing to make a modest contribution to such an MIH, but let's have that support for the next 12 months or so. Hanging in there until late 2013 does feel like a long time, although it may be practical in terms of a security-only approach, but I'd guess that Drupal 8 might even be released by then, in which D6 will be killed off anyways (and I've only just upgraded my last D5 site to D6 ;-0).

Given the minimal support and higher costs of implementing new features for both J15/D6 and J16/D7 - we've already "downsized" the current Make-it-Happen campaign to cover only security patches and critical bug fixes for the 3.x (J15/D6) series. Currently we're half-way there - and as Eileen noted, if lots of concerned folks can pitch in with small or medium size contributions we should be able to meet the goal.


If lots of folks think that the current March 2012 "end of life" date is not far enough in the future - then we could try to set a budget for another 6 months + extension and see if we can make that happen as well.


What would the target need to be to cover security patches and critical bug fixes till March 2013? Secondly, what is the US equivalent of the UK's Yesterday I had a high level exchange with one of NCVO's people who indicated that he would raise the J1.5/D6//Civi3 issue within the UK voluntary and community sector. But I am taking it that there are far more users of Civi in the US than in the UK, for which reason I think that an approach to the US equivalent of NCVO would be worthwhile.

Seb Schmoller

I would budget 10 hours / month for security and critical fixes and periodic releases for the 3.4.x series for both D6 and J1.5. At our current rates, this is $750. The US non-profit org is NTEN: However between our blog and forum blasts, i suspect we cover a significant part of our user base. lobo

iSOS (not verified)
2011-06-09 - 02:56

I understand your concern that your particular choice of solution will not be maintained as long as you need it, but as you're obviously aware from your comments it's open source software, and open source software needs to 'move with the times'. As a Drupal developer I find the benefits of Drupal 7 to be massive over Drupal 6 (and this is the overall feeling I get from reading forums/announcements etc.), so certainly from my point of view I'd want every module maintainer to devote themselves totally to developing D7 versions of modules and forget D6 ever happened! I'm not saying this should necessarily happen but just to give you an idea of the sort of diverse opinions that run across the community.

If you need the extra long term support you should look into investing time and money into the development of modules that you specifically need. In my experience programmers get bored of old tech very quickly, and excited about new tech just as quickly, so module maintainers are always going to be eager to produce code for the latest version of whatever framework they're using. It may sound harsh but if you want legacy software to be supported in the open source community (and legacy is what this will be very soon) you simply have to pay for it, the community will always charge forward with what it thinks is best for the community, not individual organisations.

I appreciate your point about having to move on, but please bear in mind that many of us rely on a large number of third party modules in addition to Civicrm. Many of these are either not updated or are in beta stages, which is not ideal for a transition. In effect, we would be losing important functionality to stay within the timetable you've set.

Not to mention that this "move forward" perspective pertains mostly to developers working on new sites, at the expense of non-developers maintaining older sites. I'm a Drupal developer already building all my new sites in D7, but I also have an enormous amount of sympathy for small non-profits who have very limited tech resources, and need a stable and secure site that will last them several years much more than they need the latest and greatest. At these types of orgs, in the end, they aren't pushing the technology that hard anyway -- they just have the random staffer with the most tech aptitude learning a few backend rituals and repeating them over and over. Upgrading these sites is a very disruptive process and, as excited as I am about D7, I hate to see friends and colleagues pushed to upgrade earlier than they'd like.

Don't get me wrong I completely understand what the op was saying it's a very valid problem. I suppose the difficultly lies in exactly what you've said about D7 modules: "Many of these are either not updated or are in beta stages". I would guess that a lot of these modules are still in beta or dev (or worse) largely because the version 6 module is still being heavily maintained, leaving less time for the developer(s) to push version 7 forward. To be perfectly honest I can't think of a good answer to this problem except for finding more developers to help out with open source!

While I agree that it would be great if all non-profits using Drupal 6 stepped up to the plate to re-create or port over their favorite community modules they use to Drupal 7, that is just not realistic.  Many organizations I work with have a budget of only hundreds of dollars per month, and they run everything in their organization (including CiviCRM) on a shoestring budget.  Nevertheless I'm impressed by the generosity to share what little resources they have trying to improve CiviCRM.  It speaks to the value of CiviCRM and how much non profits appreciate it.


I once negotiated a budget of $300 (they said $400 would be too much) to upgrade a client from D5/CiviCRM 2.0 to D6/CiviCRM3.3.  It took me several MONTHS to convince them this was the right thing to do, and then they cancelled it because they couldn't get the budget approved.  They are still using CiviCRM 2.0 to this day.


Non profits don't think like software developers.  They don't want the newest thing, they want something that is reliable and cheap.


No organization I work with has a PHP programmer on staff, and they barely afford to hire one for more than a few hours on a contractor basis.


Most non-profits don't have the budget to upgrade to Drupal 7, much less port over modules to Drupal 7.  I anticipate some non-profits will continue running Drupal 6 and CiviCRM 3.4 until 2013 and beyond, whether or not D6 and 3.4 are supported with ongoing security fixes.   They simply have no other choice.

Hi Seb,

Thanks very much for putting forth good arguments for supporting CiviCRM for Drupal 6 (they also apply to Joomla 1.5!). While developers may like to implement new sites with the latest and greatest software, organizations need to be able to use a site for a few years before spding on a major upgrade. Drupal is a bigger community and has put in place the necessary infrastructure to provide this sort of enterprise level support especially for security issues. It's great to see some forward looking organizations like ALT committing resources for the same support in CiviCRM. I'm going to pass a link to this page to some of my clients.

I'm not sure if it is easier to maintain a parallel 3.x release stream getting all of the functionality in the 4.x stream, or if it would be better to switch to just fixing security vulnerabilities. I tend to favour the latter after 4.1 on the assumption that it will be much less expensive and will therefore be able to be supported fully until D8 comes out and D6 is no longer officially supported by the Drupal Security Team.

I'm not quite clear on why the major releases of CiviCRM need to be coupled to different CMSs -- isn't CiviCRM already designed, implemented, and tested with an eye for CMS independence? Given that, it seems like one could maintain multiple CMS integrations without getting pulled into the mess of frequently merging and testing parallel branches.


More concretely, I wonder which would amount to the best cost/benefit:


1. On-going, frequent, general merges on multiple codebases (i.e. 3.x/4.x are separate but equal)

2. On-going, ad hoc merges on multiple codebases (i.e. 3.x is old but gets security fixes; 4.x is new and gets everything)

3. Upfront refactoring/cleanup to the CMS integrations (e.g. split UF "Drupal" into two UFs, "Drupal6" and "Drupal7") -- thus negating the requirement to do any on-going code merges, improving prospects for new integrations (eg Drupal8, WordPress), and giving customer orgs greater flexibility with CRM/CMS upgrade cycles.




We had not thought of doing it an option 3. This is an interesting thought and potentially a good way forward. Since the drupal and views API is different, might just be easier to create two new directories for drupal6 and drupal7 (and maybe something similar for J1.5 and J1.6)


From a support perspective, it still will involve supporting the same number of combinations as the other schemes




Thanks for your thoughts.


There are variety of opinions on when CiviCRM should or should not have worked with Drupal 7 (and Joomla 1.6), but this decision was made long long ago.


The fact of the matter is that developers are usually early-adopters who want the latest and greatest, even if it is not perfect yet.  We developers want to tinker, and a bug is just an opportunity to flex your brain and learn something new.


Developer people see Drupal 7 and a new opportunity and think that CiviCRM should adapt and use the new thing.


Non profits see Drupal 7 as an expensive and potentially disasterous change and will cling to Drupal 6 as long as they can.   I don't know about other consultants, but none of my clients are excited about using Drupal 7.


To me the fact that CiviCRM moved to Drupal 7 as quickly as it did speaks to the fact that CiviCRM is run by programmers.  I'm not sure the end-users understand or appreciate the decision, and the decision may not be beneficial to quite a few non-profits.

My organisation (the UK-based Association for Learning Technology) has just contributed USD 1000 to the important Extend Drupal 6 and Joomla 1.5 support till March 2012 "make it happen", which now stands USD 3000 short of the USD 7500 target, with a closing date of 30 September 2011.

It would be great if other organisations that may have been hanging back from contributing (as we have been) could help close the gap.

Seb Schmoller