I have two platforms, both updated to the latest version of of the jquery_update module. However, Aegir won't allow a site migration. The 'compare packages' page shows a different number in parenthesis next to the current and target platforms. What does the number in parenthesis mean, and how do I troubleshoot this? Thanks for your help.

jquery_update 7.x-2.7 (7001) 7.x-2.7 (7000)

CommentFileSizeAuthor
jq_up.jpg4.94 KBdrupal_andrew
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

drupal_andrew created an issue. See original summary.

gboudrias’s picture

Category: Bug report » Support request

It's the update version (the "n" in hook_update_n): https://api.drupal.org/api/drupal/modules!system!system.api.php/function...

In effect, Aegir is telling you this would constitute a regression. This is not a bug, you need to upgrade the version on the target platform.

drupal_andrew’s picture

The source platform's jquery_update module was updated today with drush. The target platform was also created today with a make file using the line 'projects[] = jquery_update'. Both show as being on version 7.x-2.7. Only Aegir seems to think there is a difference. Where is the hook_n documented in the module? I can't find it in the .info file...

Thanks for your help!

gboudrias’s picture

You'll need to look at the .install file, which is where hook_update_n() is. If one doesn't have the extra function ([module]_update_7001), this could be a bug, but I doubt it, seems more likely that you downloaded a dev version. Please post a pastebin of both .install files if you can.

drupal_andrew’s picture

Thanks for pointing out that I can find the hook_update in the install file. Both files are identical at 7000. I re-ran verify on both platforms and Aegir still showed them as different. If I had accidentally downloaded a dev version of jquery_update somehow, wouldn't Aeigr show something like "jquery_update 7.x-3.0-alpha3" in addition to a different hook number? All the dev releases of jquery_update are clearly titled: https://www.drupal.org/node/139405/release.

Pastebin of source (/platforms/production/sites/all/modules/jquery_update/jquery_update.install): http://pastebin.com/KxrLTHU7
Pastebin of target (/platforms/test/sites/all/modules/jquery_update/jquery_update.install): http://pastebin.com/ZbEgV5QE

I then tried manually coping the jquery_update module directory (cp -a) from the source to the target platform. So I *know* they are identical. I re-verified, and Aeigr still won't allow a migrate due to version difference.

I'm new to Aegir, so I really appreciate your help. Cheers.

gboudrias’s picture

Okay, are you migrating a specific site? If so, does it contain jquery_update?

(It's hard to imagine how Aegir would get the update number wrong on only one platform.)

The alpha releases and dev releases are not the same but this doesn't seem relevant after all.

ergonlogic’s picture

The 7001 here is referring to the 'schema version' reported by the site itself. Try running the following query:

echo "SELECT schema_version FROM system WHERE name='jquery_update';"|drush @example.com sqlc

I expect the result will be:

schema_version
7001

If that's the case, then you'd need to fix that on the site. Otherwise, it would indicate a bug in Aegir. Please let us know either way.

Also, please confirm whether you're actually running on 7.x-3.0-beta2. The current stable release is 7.x-3.2.

drupal_andrew’s picture

Yes, I'm attempting to migrate (or clone) a specific site. The source is a clone of my production site, and the target will be for development. I'm in the process of creating a make-file that will re-create the production platform exactly - and this jquery_update version mis-match seems to be the only hang-up.

drupal_andrew’s picture

Does Aegir 'loose track' of modules if using drush to update them directly, rather than migrating to a new platform?

Case:
The expire module was showing up in the Aegir web interface under the packages tab for mysite.com.
I updated the expire module via drush.
Verified the site and platform.
The expire module does NOT show up anymore in the Aegir web interface. It's just gone.

Could this be related to the issues I'm currently experiencing regarding the jquery_update module?

gboudrias’s picture

Did you see ergonlogic's comment? What does the database say?

The way you update a module shouldn't matter, but changing a version in sites/all is not recommended.

drupal_andrew’s picture

Version: 7.x-3.0-beta2 » 7.x-3.0
drupal_andrew’s picture

The result was 7001. So now my question is, how does Aegir keep track of modules (packages)?

I understand that best practice is to (1)create a new platform, (2)update the module, (3)then migrate. However, I didn't do this on one occasion (with several modules). I used drush to update a module manually. That module has disappeared completely from Aegir's list of packages.

Now I can't get Aegir to allow migrations because it either doesn't see a module, or doesn't see the correct, installed version of it. Running verify does not seem to force it to re-recognize modules.

Sacrome’s picture

I'm experiencing the same problems with the Wysiwyg module. This module has had its last update on 2012-Oct-02, so I'm sure both platforms are using the exact same module code. Using you MySQL query I found that indeed the schema version for the old platform was updated to 7202. The new platform is using version 7200.

In #7 you were saying it needs to be fixed on the site. How should I do that?

St_Dekker’s picture

Had a comparable issue with webform module, that was 'blocking' a migration / clone operation in Aegir hostmaster.
Webform version on 'curent' was 7.x-4.13 (7431) target 7.x-4.14 (7430)
Which was a bit odd, because there is no schema update to 7431 in 7.x-4.13

Here's what I did:

1. Manually update the webform schema version in the database (drush sqlq "UPDATE system SET schema_version = 7430 WHERE name = 'webform';")
2. Updated the webform module files (= removed the current files, and downloaded the 7.x-4.14 version)
3. Did a platform verify

After that I was able to migrate.

Question that remains is how webform got it's 7431 schema version.
I suspect a -dev version has been used at one point, and got deleted later. But that's a hard one to reproduce.