I'm migrating sites from our Drupal 6 platform to our Drupal 7 platform.

Our Drupal 6 and 7 platforms have third party modules installed in the all/sites/modules directory.

I'd like to upgrade the sites one at a time.

However, Drupal 7 upgrade directions specify that third party modules should be disabled *and* moved out of the way during the core upgrade (if they are left in the modules directory, then Drupal will run the upgrade steps on modules that aren't enabled, which causes errors).

What's the best strategy here? I could move the Drupal 7 platform sites/all/modules directory out of the way, but then any sites currently using that platform will break.

Am I missing something? Any suggestions would be appreciated.

jamie

Comments

anarcat’s picture

anarcat commented
Status: Active » Fixed

I would create an intermediary platform without the modules in sites/all. Wouldn't that be sufficient? Platforms are fairly cheap...

jmcclelland’s picture

jmcclelland commented

Brilliant! Thanks, that's a perfect solution.

jmcclelland’s picture

jmcclelland commented

Well... maybe I spoke to soon.

That solution only postpones the problem.

Once I have my site fully upgraded to Drupal 7 in the transition platform (that has no third party modules), I then try to migrate to the final Drupal 7 platform that has the third party modules available.

During this migration, aegir runs all available database updates on the new final Drupal 7 platform, which includes updates provided by third party modules (which are disabled in the database).

Some of these third party module updates fail because they call functions only provided by the module itself. However, since the module is disabled, the function is not available.

I'm not sure it's an aegir bug - honestly, I'm baffled by why Drupal would try to run database updates on modules that are not enabled.

I can think of two work arounds:

  • Create a new site on the final platform and then sync the database from the transition platform site to the final platform site. Then, enable all third party modules. Then run updates.
  • Change the module status from 0 to 1 via the database on the transition platform site (since properly enabling them will fail since they are not available). Then, migrate the platform, which should trigger the updates on the enabled modules
jmcclelland’s picture

jmcclelland commented

It doesn't feel right but running this command before migrating worked:

drush "@site.example.org" sqlq "UPDATE system SET status = 1 WHERE schema_version != -1 AND status = 0 AND type = 'module'

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

danepowell’s picture

danepowell commented
Version: 6.x-1.6 » 6.x-1.8
Status: Closed (fixed) » Active

I'm going through the same thing right now and while I appreciate the suggestion in #4, it seems like a total hack :) What on earth would be proper solution here? Surely we are not the first two people to go through this!

(Specifically- my site uses Strongarm and Ctools, and when I migrate it from the D6 platform to the D7 platform, the migrations fails with the error "Call to undefined function ctools_include() in strongarm.module on line 8")

steven jones’s picture

steven jones commented
Status: Active » Closed (duplicate)

Really sorry, but it seems that basically this is a problem with those modules, in that they shouldn't be using functions in their module files in update hooks, a core issue that tries to deal with this mess is here: #734710: API functions that invoke hooks don't work as expected when a disabled module is being uninstalled