The transition to Drupal 7 is probably the biggest challenge this year for the Drupal community. As discussed in previous blogs the intention has been that 3.4 would be the last release supporting Drupal 6. Unfortunately many sites aren't ready to upgrade to Drupal 7. The hidden risk of this is that if a sizeable portion of CiviCRM sites are not using 4.1 then the number of people testing, fixing & enhancing 4.1 will be much reduced. The cost of not having a drupal 6 release is likely to be higher than the cost of having one - even for Drupal 7 and Joomla! sites.
One of the things we have looked for at the codesprint has been Tim Otten's suggestion of supporting Drupal 6 as a separate CMS (like Joomla! & WordPress). The good news is that we think that a Drupal 6 release for 4.1 is a realistic option. Of course resources will continue to be a problem so please commit to helping or contribute to the MIH. If 75 donors would commit to $10 per month on an ongoing basis we could keep drupal 6 support alive as long as the donors are onboard (within reason).
Back to the sprint. There are 2 aspects to continued D6 support, tidying up the exisitng interaction with the various CMS & figuring out how to manage the Drupal specific folder.
We have done the first part this week (pending a bit more testing). From my perspective this involved a lot of nodding & pretending to understand what Tim was doing combined with a bit of code tweaking. Apparently we have restructed the code that interacts with the CMS to be more polymorphic (I don't have a clue what that means but Tim says it all the time :-)).
So, in 3.4 /4.0 we call
require_once 'CRM/Core/BAO/CMSUser.php';
CRM_Core_BAO_CMSUser::checkUserNameEmailExists( $params, $errors );
In 4.1
$config = CRM_Core_Config::singleton();
$config->userSystem->checkUserNameEmailExists( $params, $errors );
The issue is at http://issues.civicrm.org/jira/browse/CRM-8730
The second part of the challenge relates to the drupal modules folder. In our first test we found that existing sites would happily continue working if we added a second modules folder called Drupal6. However, this seemed to come undone in later testing and although the correct .info file is picked up the .module file is selected by doing a filescan.
It seems we will have to somehow manage one core code base but 2 versions of the drupal folder through our version control system. This is mostly a problem in terms of figuring out a good process for developers using an SVN checkout as the official releases will hold only the correct version of the drupal folder. At this stage we are looking at moving to GIT before 4.1 is released and Jamie from PTP is bending his intellect around CiviCRM's version control needs.
Comments
This isn't far from what we saw with Drupal 5 and while there was a vocal group to maintain support we weren't able to muster support and that effort died. I fear this will fall that way also.
While I understand tension, and am myself going through the same tension, I'm not a fan of promoting feature's being maintained for two branches of Drupal/CiviCRM. We have a responsibility to push our clients and non-clients to get involved (insert plug for MIH here) in the development of the software and this is not going to help with that effort. IMHO we should only support only Blocker and Critical bugs and Security Issuse (I understand the definition of critical/blocker is subjective) for the 3.x branch of CiviCRM. Now I do think we should be supporting those till Drupal 6 EOL but the fact that we can't raise $7,500 towards this cause is pretty telling to me.
The scenario I fear the most is a large set of organizations implementing CiviCRM will not upgrade until, or even when, Drupal 6 support dies. This has the potential to leave organization with an unsupported version of the CMS that CiviCRM relies on as it's first line of defense in reference to security and user authentication. Then we have to scramble to get people on Drupal 7/CiviCRM 4.x while trying to support development for a Druapl 8.x version or, even worse, go through the tedious arguments about continuing to support Drupal 6 after it's official end of life.
I get that change is bad and all, but it's life. :)
So the current plan is that only the drupal folder will be maintained for 2 versions of drupal, both will use the same version of core. The drupal 6 version of the drupal folder should be fairly static.
There are certainly still organisations out there using drupal 5 & CiviCRM 1.9 and there will still be organisations that lag in drupal 6. What concerns me is not the laggards but where there is a significant volume lagging. The organisations we work with have invested in a siginificant amount of our time on fixing bugs and improvements for 3.4. One organisation in particular has invested several thousand dollars in bug fixes. The organisations we work with who have contributed to 3.4 won't be moving to Drupal 7 for some time if we leave them behind in a dead branch they won't be contributing to 4.1. This seems like lose-lose to me.
Note that I wouldn't expect drupal 6 views integration, for example, to be kept up with drupal 7 views development.
Many clients are between a rock and a hard place. Clinent d6/3.4 installs use other Drupal modules not available in d7 yet. Client lacks budget to sponsor d7 version of necessary module. Hence, client stays at d6. That's why I'm giving myself (and raising money for) d6 support through 2012. This will buy us time and will allow d7 to mature enough so that an upgrade for d7/4.0 is more affordable for clients.