For some modules, update_status is showing old versions being installed, when, in fact, the newer versions are installed and recognized on the site.

Example - update_status reports: Content Construction Kit (CCK) 5.x-1.0-beta while the Modules page reports Content 5.x-1.5 (the correct version).

CommentFileSizeAuthor
#4 AvailableUpdates.png69.22 KBTallDavid
#3 Modules.png196.39 KBTallDavid
#2 content.info296 bytesTallDavid

Comments

dww’s picture

dww
we/he/they
commented
Status: Active » Postponed (maintainer needs more info)

- Do you have any older copies of CCK lying around in your web root that are not enabled?
- Can you provide screenshots of your modules page and available updates report?
- Does this happen for any other modules besides CCK?
- Please attach a copy of your content.info file in a reply to this issue.
- Can you confirm you're using update_status 5.x-2.0-rc2, and that it wasn't an accident when submitting this issue?

Thanks,
-Derek

TallDavid’s picture

TallDavid commented
StatusFileSize
new content.info296 bytes

- Do you have any older copies of CCK lying around in your web root that are not enabled?

  • I confirmed that there is not a version of CCK in the \ directory or in the \modules directory or under the \sites\default directory
  • I confirmed that there is a version of CCK in the \sites\all\modules directory and the content.info file from this directory contains the following information:
    ; $Id: content.info,v 1.2.2.2 2007/01/05 11:57:46 yched Exp $
name = Content
description = Allows administrators to define new content types.
version = "$Name: DRUPAL-5--1-5 $"
package = CCK

; Information added by drupal.org packaging script on 2007-04-12
version = "5.x-1.5"
project = "cck"

- Does this happen for any other modules besides CCK?

  • Actions 5.x-1.x-dev shows "No filedate available"
  • Views Bonus Pack shows "Invalid info"
  • All other modules show "Up to date".

- Please attach a copy of your content.info file in a reply to this issue. - ATTACHED

- Can you confirm you're using update_status 5.x-2.0-rc2, and that it wasn't an accident when submitting this issue?

  • Confirmed: Update status 5.x-2.0-rc2

Requested screenshots to follow...

TallDavid’s picture

TallDavid commented
StatusFileSize
new Modules.png196.39 KB

- Can you provide screenshots of your modules page and available updates report?
Modules screenshot attached.

TallDavid’s picture

TallDavid commented
StatusFileSize
new AvailableUpdates.png69.22 KB

Available Updates screenshot attached.

TallDavid’s picture

TallDavid commented

Doing some further digging, I discovered an erroneous old version of CCK buried under the auto_nodetitle module directory. Aha! I thought. I removed this directory and re-ran a manual check of available updates... the problem remained. I cleared the Drupal & browser cache's and re-ran a manual check of available updates and the problem still remains.

The erroneous extra CCK installation may have been the root cause of the problem, but, why is Update Status still reporting bad information?

Hope this additional information is useful...

TallDavid’s picture

TallDavid commented

Also tried running update.php and the problem persists...

dww’s picture

dww
we/he/they
commented
Status: Postponed (maintainer needs more info) » Active

Thanks for the info (btw, you should set the status back to "active" when you provide the requested info) ;)

A) after removing that bogus cck directory, try hitting the "Save configuration" button on admin/build/modules (even if you don't toggle any of the settings). if it's easy, before you do this, make a DB dump of your {system} table.

B) old dev snapshots didn't include the datestamp attribute that update_status depends on for the dev snapshots. that explains your actions 5.x-1.x-dev results.

C) I don't know about your view bonus pack problem, but it's just due to a missing or incomplete .info file, not a bug in update_status.

At this point, I think there's really only 1 bug, as such, to help defend this module from weirdly configured sites: the "Check manually" link should do the same clearing of cached info that "Save configuration" does on the modules page. But, we'll see how it looks after you try this and report your results.

Honestly, even though the core admin/build/modules page was telling you you were running content version 5.x-1.5, I bet it was actually still using the stale copy you used to have. That's really a bug in the way Drupal core tries to locate and use module code on your site...

To test this hypothesis, before you save your modules page again, try going into the 5.x-1.5 version of content on your site (sites/all/modules/cck), open up content.module in a text editor, and put some invalid php junk in there to try to trigger a parse error. Then, visit any page as an authenticated user. I'm guessing your site will not in fact blow up, since I doubt core is actually using sites/all/modules/cck/content.module on your site, so long as a) the stale copy still lived at sites/all/modules/auto_nodetitle/cck (or wherever it was) and your {system} table entry for content.module still pointed there...

Well, actually, now that you removed the stale copy, I don't know if the above test would even work. But, you could try recreating it on a test site if you were curious.

Thanks,
-Derek

TallDavid’s picture

TallDavid commented

Derek,
I hit the "Save configuration" button on admin/build/modules, but, the problem remained. Next, I wiped out the cck directory on the web server and ftp'd a new copy of cck (freshly downloaded from Drupal.org). Available updates for cck is now displaying correctly!

I had previously performed a file compare between content.info on my local machine and content.info on the web server and both showed to be identical. (This is the content.info file that I have previously uploaded as part of this issue.) My understanding is that the update_status module reads the .info file to determine the installed version. Is this not correct? Are there any additional files in the module directory that update_status reads to obtain the version information?

Digging further, I did a directory compare between a backup of the cck directory (with the problem) and the new cck directory (with the problem resolved). Except for three files all directories/files are identical. There are 3 files (date.info, date.install & date.module) which are present in the problematic installation which are not present in the new (correct) installation. The date.info file contains the following:

; $Id: date.info,v 1.2 2006/10/16 12:55:46 karens Exp $
name = Date
description = Defines a date/time field type.
version = 1.0
dependencies = content
package = CCK

; version added by drupal.org packaging script on 2006-11-20
version = "5.x-1.0-beta"

Is it possible that update_status was reading the version info from this date.info file instead of the content.info file?

My current hypothesis is that these 3 "date" files remained on the web server when the new cck module files were ftp'd from my local installation. How they caused the erroneous version data to be displayed, I do not yet understand. Ideas?

We've solved my immediate problem, and we're getting closer to a full understanding, but, I'm not sure we found the "root cause" of the issue...

David

dww’s picture

dww
we/he/they
commented
Category: bug » support

Here's the thing. update_status deals with projects not individual modules. CCK is a good example -- there are a bunch of different modules included in the cck-5.x-1.5.tar.gz file. The packaging script now adds another attribute to all the .info files it touches, "project = foo", to make sure that all the .info files for modules included in the "cck" project's tarballs are marked as such. This is how update_status normally groups your modules together with the project they came from (that "Includes: foo, bar, baz" stuff on the update report).

However, this change to the packaging script only happened maybe 3 or 4 months ago, so older release tarballs from before that time did not include this "project = foo" stuff. When update_status finds old installations like this, all it can do is try to guess the package based on the directory the module is installed in. The assumption we have to make is that people install modules like the instructions say, and put each one in its own directory, instead of putting them all in 1 giant directory...

In your case, you a) had very old tarballs of cck and date, and b) installed all of them in the same directory. :( There's really *nothing* update_status can do in this case to defend itself, and it has no choice but to print out the wrong thing based on the data available to it.

At this point, I'm really not seeing a bug in update_status. It's well known (to me, at least *grin*), that it can't recover from hostile setups with old releases and/or non-standard directory layouts. Perhaps we should just put this in the FAQ on the project page.

Life will be better in D6, since every tarball ever created for a 6.x-* release of anything includes all the right metadata that update_status needs, so there's no guessing involved anymore. And, as people update to newer versions of D5 releases, things will be more and more sane...

TallDavid’s picture

TallDavid commented

Derek,
the scenario is not exactly as you've described. Apparently, the 3 files (date.info, date.install & date.module) were included in the CCK 5.x-1.0-beta module tarball (Note the "package = CCK" in the date.info file) and have since been removed from the CCK module distribution.. Although I have learned that this is a good practice, the CCK module installation instructions did not specify that the old cck directory needed to be totally removed prior to an update of the module. I'm now one step higher on the learning curve. {grin}

Although this may become mute in version 6, wouldn't it be smart for the update_status module to verify that the version is identical for all *.info files with the same package ID? In my case, it simply reported the oldest version -- which is not optimum, but, was certainly valuable in identifying that there was a problem!

Anyway, my problem has been resolved with the help of your great questions and feedback. Thanks for the effort you have put into the module and for the help you've provided.

Best,
David

dww’s picture

dww
we/he/they
commented
Status: Active » Fixed

package = CCK is about how things are grouped together on the admin/build/modules page. update_status doesn't care about that at all.

project = cck is what update_status is looking for, and if it can't find it, it tries to guess based on the directory.

weird that date used to be included directly inside cck. i didn't know that, but i just confirmed it's true.

i agree it could be nice when update_status is gathering info, if it finds another .info file it's going to group with an existing project it knows about, it should check the versions. if they don't match, it should complain somehow. let's move discussion of this feature over to a new issue, http://drupal.org/node/166333.

other than that, i think this support request is done, so i'm marking it fixed. thanks for all the detailed information, it really helped track this down quickly.

cheers,
-derek

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)