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
CRM_Core_BAO_CMSUser::checkUserNameEmailExists( $params, $errors );
$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.