Problem/Motivation
Some contributed modules have a HEAD release (as well as the expected releases using the standard version numbering, such as 7.x-1.0). As a hangover from the days of CVS, these do not have a version_major key set for them. If, in addition, the HEAD release is tagged with a Drupal major version (for example, the release is tagged as "7.x"), it causes errors in the dblog every time the update module checks for updates.
Notice: Undefined index: version_major in update_calculate_project_update_status() (line 567 of /modules/update/update.compare.inc)
This is because the update module finds the HEAD release, sees that it is tagged with 7.x, and so checks its version. However, with version_major unset, it fails when doing so.
For example, a module might have a released 7.x-1.0, a 7.x-1.x-dev release, 7.x-2.0-alpha2, and 7.x-2.x-dev. If someone is running 7.x-1.0, all the releases tagged with 7.x would be checked to see if they are possible releases that the site could / should use. That would include the 4 just mentioned, but also others like 7.x-2.0-alpha1. If there were a HEAD release tagged 7.x, it would also get checked to see if the Update Status page should link to it. However, whilst all the 7.x-1.x-foo and 7.x-2.x-bar releases would have version_major available to compare, HEAD would not. Instead of being checked and then found to be not a release to mention, the check would generate the above error.
Proposed resolution
Use isset on a release to check version_major before performing the comparison. Any official Drupal releases from git will have version_major set. If it's not set, we can safely ignore the release.
Remaining tasks
A patch has been produced against Drupal 7 and Drupal 8. Because there are no official D8-compatible releases of contributed modules, all testing will have to be done against Drupal 7. To date, three people have found the Drupal 7 patch resolves this particular error. The remaining task is for Core maintainers to review this patch, either committing it or indicating what further work is required.
User interface changes
None
API changes
None
Issue History
This issue originally also addressed an issue arising from the git_deploy module. That was a separate issue, because it only concerned the use-case of that module deploying projects directly from git. The matter of HEAD releases having a major Drupal version tag is a separate. The other issue has been handled as an issue in the git_deploy queue: #1341464: For git submodules .git will be a file: check file_exists(), not is_dir()
Original Report by eMPee584
The IMCE module has releases such as 7.x-1.5, 7.x-1.0-alpha3, 7.x-1.x-dev which are all fine. But then it has a master release - and that has not set a version_major. Which brings us a
Warning message
Notice: Undefined index: version_major in update_calculate_project_update_status() (line 556 of /var/www/localhost/htdocs/d7.git/modules/update/update.compare.inc).
that is simply dealt with by a isset().
The other thing is, git_deploy generates module version strings by appending a number to the last tagged release, then '-dev':
Calendar 7.x-3.0-alpha1.30-dev (2011-Nov-08)
Recommended version: 7.x-3.0-alpha1 (2011-Aug-01)
CAPTCHA 7.x-1.0-alpha3.3-dev (2011-Nov-02)
Recommended version: 7.x-1.0-alpha3 (2011-Apr-27)
Chaos tool suite (ctools) 7.x-1.0-rc1.40-dev (2011-Nov-04)
Recommended version: 7.x-1.0-rc1 (2011-Jul-29)
Now update_calculate_project_update_status() compares the timestamp for dev-releases, which are automatically generated on dp.o cron runs - and ALWAYS have a later timestamp than the latest git commit, so always reporting available updates when in reality we are on the very latest tree.
So what about dropping in a strnatcasecmp() between the latest tagged release and our git-version tag? Of course, this falls short of checking if we actually are on the dev-branch tip, but at least the result is more useful than comparing those timestamps..
Comment | File | Size | Author |
---|---|---|---|
#32 | Update_Check_With_HEAD-1343768-32-D7.patch | 935 bytes | JamesOakley |
#30 | Update_Check_With_HEAD-1343768-30.patch | 952 bytes | JamesOakley |
#19 | Update_Check_With_HEAD-1343768-19-D7.patch | 743 bytes | JamesOakley |
#18 | Update_Check_With_HEAD-1343768-18.patch | 760 bytes | JamesOakley |
core-make-update_calculate_project_update_status-work-nicely.patch | 1.63 KB | eMPee584 | |
Comments
Comment #1
eMPee584 CreditAttribution: eMPee584 commentedComment #2
dgastudio CreditAttribution: dgastudio commentedsame problem. solved by patch.thanks
Comment #3
VM CreditAttribution: VM commentedThis likely need to be bumped to the 8.x-dev version where it can get some more eyes on it.
Comment #4
mefisto75 CreditAttribution: mefisto75 commentedStarted to get this error too. Weird because IMCE didn't cause this errors before.
Comment #5
oriol_e9gStart in D8 first.
Comment #6
sixelats CreditAttribution: sixelats commentedApplied the patch in 7.12, checked manually for updates, no error when the unpatched update.compare.inc gave me the error twice.
But Entity API and Rules have newer dev versions (at least by date) and they are shown as "up to date" (I am using older dev versions for both of them).
Not sure if this is the intended patch behaviour cause I don't really get the stuff about git but thought it worth mentioning it.
Comment #7
VM CreditAttribution: VM commentedalso reported here: http://drupal.org/node/1440078
Comment #8
sergiu.savva CreditAttribution: sergiu.savva commentedcore-make-update_calculate_project_update_status-work-nicely.patch queued for re-testing.
Comment #10
melissa81 CreditAttribution: melissa81 commentedcore-make-update_calculate_project_update_status-work-nicely.patch queued for re-testing.
Comment #12
dimitriseng CreditAttribution: dimitriseng commentedI started getting these notices while on D7.12, but not sure which module is causing this, it might be taxonomy_menu but cannot confirm this. I applied the patch manually and tested and it successfully removed the notices. However, this causes the problem mentioned in #6. If we can resolve that then it would be great to get this commited as these notices are very annoying... Thank you.
Comment #13
dimitriseng CreditAttribution: dimitriseng commentedHi, any thoughts on this? Please see my comments in #12, thank you.
Comment #14
maximilianuhl CreditAttribution: maximilianuhl commentedI just had this error with the taxonomy_menu module. I am working with version 7.x-1.x-dev of this module, but in the file taxonomy_menu.info the line added by the drupal.org packaging script says version = "7.x-1.2+28-dev". Changing this line to version = "7.x-1.x-dev" makes the error disappear. So maybe its an error of the packaging script and not of the update module.
Comment #15
astro87 CreditAttribution: astro87 commentedIt worked, the error dissapeard
Notice: Undefined index: version_major in update_calculate_project_update_status() (line 556 of /home/astro/.www/drupal7.14/modules/update/update.compare.inc).
but I have other errors, I think related:
Drupal 7.14,
modules - taxonomy_menu, internationalization, view as taxonomy/term/%
Notice: Undefined index: href in menu_local_tasks() (line 2048 of /myaccount/drupal7.14/includes/menu.inc).
Drupal 7.12
modules - taxonomy_menu, internationalization, view as taxonomy/term/%
Notice: Trying to get property of non-object in _node_types_build() (line 671 of /myaccount/drupal-7.12/modules/node/node.module).
Notice: Undefined index: href in menu_local_tasks() (line 2049 of /myaccount/drupal-7.12/includes/menu.inc).
When using Views taxonomy/term/% pages I have the "Page not found".
Comment #16
BerdirComment #17
Anonymous (not verified) CreditAttribution: Anonymous commentedManually applied the above patch to D7.14. It helps against the PHP notice and removed the (wrong) update hint for a module.
I guess - like sixelats (#6) - the fix just removes the error, but doesn't provide proper update hints for the dev version, does it? It would be helpful to be informed about subsequent dev versions as well as subsequent production quality releases.
Comment #18
JamesOakley@Shnapoo -no problem there. The -dev version will still be checked. It stops HEAD releases from causing the update status check to fail. HEAD releases shouldn't be being updated any more - all new versions will come out either as -dev releases or as numbered (7.x-1.2, etc.) releases.
This patch incorporates the isset check for the version_major key.
I don't understand the need for the strnatcasecmp call. Could someone explain how that relates to this issue?
Comment #19
JamesOakleyThis could be difficult to test against D8, because the issue is specifically with contributed modules that have HEAD releases tagged against the relevant version of core. I'm not sure any of the modules that affect this in Drupal 7 have Drupal 8 versions yet. It's also unlikely that the HEAD releases of those modules will be tagged with 8.x.
So I've rerolled the patch at #18 into a Drupal 7 version, in the hope that it will help with testing.
{I've removed the reference to git in the issue title; it seems that is what the strnatcasecmp call was all about, but making update checking play nicely with git downloads is a separate issue and needs to be treated this way. Perhaps the OP wishes to open a new issue for that aspect?}
Comment #20
JamesOakleyOK: Both the D7 and D8 patches passed the testbot. Marking this back as 8.x until it's been reviewed by others.
Comment #21
eMPee584 CreditAttribution: eMPee584 commentedmy initial thought is
"well hell no i do not feel like opening another issue, i have filed dozens and dozens of patches against core and contrib of which oh-so-many just bitrot there waiting for the end of all things... and the git version compare aside, what the frigging heck is dubious about this patch, any mediocre coder will understand what it does, that a simple IS THAT VARIABLE SET check can not possibly cause any issues in this case.. why the fsck does noone have the b*lls to just go ahead and commit simple one line fixes like this? Was it not for the disappointment, It would be highly ridiculous."but as that would surely be modded down quickly, my response is:
Yes sure I will. Thanks for testing and rerolling James, hope this gets in sometime this decade^^
Comment #22
JamesOakleyThanks for your patience, eMPee584. It's only that with one issue per issue, we're more likely to get these fixes committed.
I'm not sure your review would be enough, on its own, to move this to RTBC, seeing as it's a re-roll of your patch ;-), but if you could confirm that the rerolled edition fixes the HEAD issue that would be a reassuring start.
I'd love someone to test this soon - enough people complained about this in the TaxonomyMenus queue, so if one of them could test this we could get this to RTBC and then committed.
Comment #23
tarausa CreditAttribution: tarausa commentedNotice: Undefined index: version_major in update_calculate_project_update_status()
Same error here.
Had some updates just before this error occurred.
Started with IMCE Module since others were indicating this was the root of the problem. Indeed this was my problem. I went to IMCE Module and reinstalled older version refreshed browser and what do you know NO error. Hope this helps someone else.
Comment #24
Melissamcewen CreditAttribution: Melissamcewen commentedUsing patch #19 now and it is working well on my site.
Comment #25
JamesOakleyGood to hear, Melissamcewen.
Could you be more precise, and say which contributed module was causing the "Undefined index" error before the patch, such that the patch solved the issue for you?
Comment #26
Melissamcewen CreditAttribution: Melissamcewen commentedI'm pretty sure my problems were
- IMCE Wysiwyg API bridge
- jQuery Update (7.x-2.1+9-dev)
- Linkit Views
Comment #27
JamesOakleyIn that case, I wrote the patch (or at least re-rolled it) and found it helped with this problem in connection with Taxonomy Menu. You've tried it, and found it helped with other contributed modules that caused the same problem in the update component.
I think that means this can move to RTBC.
Comment #28
sunCan we update the comment above the condition to make it state why we're excluding projects, for which no major version was found, and ideally also, in which ("known") case we don't expect to find a major version?
All of that is not really clear to me, neither from the issue summary, nor from comments, nor from the patch.
I'd also like to know whether there is a follow-up issue for the second issue being reported in the OP? The enforced addition of the "-dev" suffix by git_deploy actually smells like the actual root cause for this bug to me.
Comment #29
Alauddin CreditAttribution: Alauddin commentedApplied the patch from #19 and it solved my issue
on D7.14
Taxonomy Menu - 7.x-1.2+31-dev was causing the error.
Thanks
Comment #30
JamesOakleyIn #28, sun asked for explanation in this issue queue as to why this change is necessary. He also asked for a comment to be incorporated in the patch. This issue now has a properly formatted summary at the beginning. The patch now modifies the comments at this point in the code, explaining what the isset call is there for.
In passing, it's in the issue summary, but the git_deploy side of the issue has been handled (and committed) at #1341464: For git submodules .git will be a file: check file_exists(), not is_dir().
Comment #31
JamesOakleyOops - changing the issue status to allow the test bot to check the patch.
That patch is for D8. Drupal 7 version to follow once this one has finished testing.
Comment #32
JamesOakleyThis version is for patching against Drupal 7.
Comment #32.0
JamesOakleyJamesOakley - created an issue summary to help maintainers
Comment #33
JamesOakleyOK @sun. The above two patches (D7 and D8 versions) did not fail the testbot.
Those two patches only differ from the previous ones in that they have just been rerolled to make sure they are current, and in that I have altered the PHP comments at the point where the change is made. I'm therefore marking this back to RTBC, because these are the same patches tested by myself, by Melissamcewen (#26) and Alauddin (#29).
To help maintainers review the patches, I have added a properly laid-out issue summary at the top of this issue.
The version is set to 8.x-dev, because patches are applied to Drupal 8 first, but please note the comment in the issue summary as to why I believe the change needs making to D8 and to D7, but testing is unlikely to be possible with Drupal 8 at this time.
Comment #34
catchOK since this is just adding an isset() and it's also a d.o-specific issue I'm fine committing the bug fix without test changes. Committed/pushed to 8.x, moving to 7.x for backport. Thanks!
Comment #35
oriol_e9gPatch for D7 in #32
Comment #36
webchickCommitted and pushed to 7.x. Thanks!
Comment #38
wusel CreditAttribution: wusel commentedlike http://drupal.org/node/1754430#comment-6699150 : This error remains!
This error is in D7.16 (not dev) not fixed. I have this issue too.
Please help (=> D7.17 !)..
Wusel
Comment #39
JamesOakley@wusel
The fix for this was committed to Drupal 7 on August 18 this year.
Drupal 7.16 came out after that, but only included security fixes, not bug fixes.
The release before that was 7.15, which was released on August 1st - before this patch was committed.
Because Drupal 7.16 did not contain any bug fixes, this patch has still not found its way into a core release. So you are right - 7.16 will still contain the bug. However 7.17 is being released later today, and so this issue will be fixed in 7.17. In your shoes, I'd just wait. If you can't, you could update to the 7.x-dev release of Drupal or manually apply the patch in comment #32 of this thread.
Comment #40
wusel CreditAttribution: wusel commented@JamesOakley
Thank you very much.
Wusel
Comment #41
nancygill CreditAttribution: nancygill commentedI have this error in 7.17 tonight and it's making all my nodes unavailable. How does one fix it?
Comment #41.0
nancygill CreditAttribution: nancygill commentedWorked example to clarify.
Comment #42
Jean Gionet CreditAttribution: Jean Gionet commentedI just upgraded to 7.24 and now I'm getting this error. How exactly is this fixed? All my modules appear to be up to date.
Notice: Undefined index: version_major in update_calculate_project_update_status() (line 628 of /home/user12323/xxxxxx.xxx/modules/update/update.compare.inc).
Comment #43
JamesOakleyJean
Could you have a look at the code in your version of update.compare.inc around line 628?
The patch that was committed, that fixed this, was https://drupal.org/files/Update_Check_With_HEAD-1343768-32-D7.patch
It replaced
if ($release['version_major'] > $target_major)
with
if (isset($release['version_major']) && $release['version_major'] > $target_major)
This means that the version_major array key isn't used unless it exists.
What does your copy of this file have in this regard?
Comment #44
rezboom CreditAttribution: rezboom commentedI have the same problem as Jean in #42.
I checked update.compare.inc and the patch mentioned in #43 by James is applied. (Line 598)
This are the errors I get:
Notice: Undefined index: version_major in update_calculate_project_update_status() (Zeile 621 von /var/www/modules/update/update.compare.inc).
Notice: Undefined index: version_major in update_calculate_project_update_status() (Zeile 628 von /var/www/modules/update/update.compare.inc).
Notice: Undefined index: version_major in update_calculate_project_update_status() (Zeile 638 von /var/www/modules/update/update.compare.inc).
these are repeated twice more... maybe 3 modules are throwing the error?
Comment #45
JamesOakleyOK - I can see those lines in http://drupalcode.org/project/drupal.git/blob/refs/heads/7.x:/modules/up...
What's more confusing is that they are not new - the file has not been changed since the patch being discussed in this issue was committed.
It is a similar issue - checking for
$release['version_major']
without runningisset
on it first.I haven't got time at the moment to look at the logic of the method this is in, and work out whether another
if(isset...)
call is the best / correct solution. It depends when the lines we're talking about are reached - since it's clearly not all the time.I may have time later, but this is equally something somebody else could do.
Comment #46
Jean Gionet CreditAttribution: Jean Gionet commentedyeah.. these are the lines I have in my update.compare.inc file
The error message is:
Comment #47
maximpodorov CreditAttribution: maximpodorov commentedNew problems appeared after updating to 7.24:
[#2142133]
Comment #48
dwwThis is a separate problem, caused by bugs in the XML release history feeds.
Let's please leave this issue closed for the original problem it was fixing (so-called "HEAD" releases).
Comment #49
JamesOakleyWhat's more, this is definitely not an issue relating to 7.24, as the relevant file has not been changed since the patch was committed in #36 of this thread.
@dww has worked out where the problem lies (which was more than I had been able to do) - the input data coming in has changed that triggers the bugs people are experiencing.
Comment #50
maximpodorov CreditAttribution: maximpodorov commentedThank you for the explanation. Excuse me for this confusion.
Comment #51
Kebz CreditAttribution: Kebz commentedI keep getting a message to "update" my "Commerce CiviCRM" dev to the Beta2 version
I had that version before, but it had errors & warnings.... and the patch is for the Dev version... so that's why I installed the dev instead.
How can I make it stop telling me to update it?
I believe this "notice" below is because of this module asking for the update based on the discussion
Comment #52
Kebz CreditAttribution: Kebz commentedUPDATE:
I disabled, uninstalled "Commerce CiviCRM" and I am STILL getting the same notice below. I'm going to rule it out since it no longer applies to that module... however, I am still getting it and I have no modules being listed to get updated. Any thoughts on what's triggering this? I cleared my cache ... but still getting the notice. My "status" report page is giving me a "green" clean site =)
Notice: Undefined index: version_major in update_calculate_project_update_status() (line 629 modules/update/update.compare.inc)
Comment #53
JamesOakley@Kebz - given this exact issue has been fixed since Drupal 7.17, are you sure it is this issue you're experiencing.
Specifically, this exact issue is only triggered for old Drupal projects that were created, and given at least one tagged release, before Drupal moved over from CVS to git for its source control. Commerce CiviCRM is not in that category.
[#2142133] is related, and is still active and not fixed, so have a read over there and see if that might be the issue you need to start following.
You need to work out which module is triggering the message you're seeing - probably by inserting some debug code around that line.
What version of Drupal core are you using?
Comment #54
Kebz CreditAttribution: Kebz commented@JamesOakley
Thanks for your response =)
btw... My Drupal core version is 7.34
Yes, I'm still getting the notice several times in the day... and I've already removed the module and I have nothing in the "update" section and I'm using thee most current version of Drupal as well.
Thanks for the link... I'll have a look inside there.