1

For my contributed module I've previously published several releases without any issue.

Most recent releases were successively 7.x-2.0rc2 then 7.x-2.0 and 7.x-2.1.

As of 7.x-2.1 the following happens:

  • for all Drupal sites having this module installed with an older release, the admin/reports/updates list doesn't mention the newest release (even after refreshing):
    • for a site currently in 7.x-2.0rc2 it proposes 7x-2.0
    • for a site currently in 7.x-2.0 it tells it's up to date
  • (may be not related but) simultaneously I noticed that the git repository summary doesn't show the labels for the tags corresponding to the 2 new releases, in its Age list

However at the same time:

  • the project page shows the right last release in Recommended releases (and downloading it gives the right content too)
  • the git repository summary shows the involved releases in its Tag list

BTW I noticed that some other older releases are also shown in Tag list while missing in Age list, so the git behaviour might not be relevant for this issue

Anynay keep wondering why the recommended release of my module is not proposed in Drupal updates?

2

Immediately after posting my question, I'd pushed a new 7.x-2.2 release, and it didn't change anything: all involved sites keeped reporting 7.x-2.0 as the most recent release.

But today I noticed that it suddenly changed (without any intervention in git nor in my module's page): now the sites correctly report 7.x-2.2 as the most recent release.

So I tend to think that the response to my question is merely: there is some variable latency in the way Drupal.org makes the information available for the admin/reports/updates/check page underlying mechanism to work.

Moreover it worth mention that also the git Age list now shows all release tags, while some of them were previously missing.

1

I just installed/enabled your 7.x-2.1 version of your module in a multilanguage D7 site (3 languages, 'en' is the default), in which I have never installed any earlier version of your module.

After doing so, I received a (red) Drupal error message (actually 2 identical ones) like so:

Notice: Use of undefined constant _MULBASE_PATH - assumed '_MULBASE_PATH' in _multilang_install() (line 22 of .../sites/all/modules/multilang/multilang.data.inc).

And I also get an informational (green) message like so:

NOTE: in order to use the advanced features available with CKEditor, you must install the Widget plugin.

The 'advanced features' in it is a hyperlink, pointing to .../en/_MULBASE_PATH/en/admin/help/multilang#ckeditor. Obviously following that link returns a page not found (because of the _MULBASE_PATH in it.

And within admin/reports/updates there is now (also) the yellow update message shown, from 7.x-2.1 to 7.x-2.0 (similar to your update messages).

Within admin/reports/dblog, there is now also a message like so:

Warning: Invalid argument supplied for foreach() in multilang_exit() (line 240 of .../sites/all/modules/multilang/multilang.module).

So could it be that it is somehow related to that _MULBASE_PATH, which I assume is a variable that has not receive an appropriate value yet?

Haven't done any other debugging or research so far, but I wouldn't be surprised if that could be what is causing your issue ...

PS: in the meantime I have discovered that, in the site where I did my experiment earlier today, my "module list" (at 'admin/modules') isn't working anymore (I'm using 'module filter' module also). When I visit that link, not even 1 module is shown anymore. Not sure yet if it is a memory issue (pretty sure it is not), because I added 1 more module. But since the only thing I did in this site today is my experiment with that 2.1-version of your module, I suspect that to be the culprit ... I can't even simply disable the module again by using the 'admin/modules' link (no modules are shown to enable/disable). So I'm planning to go edit the system table via PhpMyAdmin soon. I'll update my answer after I have more details on that.

  • Oops! What you pointed is a regression bug. I'd not detected it by myself because it ONLY happens at install time or when reading inline help, and I missed testing that again (shame :-). Besides that, nobody else opened an issue to report it, so thanks a lot for having alerted me about it. But I tend to think it's not the cause of my issue: first because this bug already existed in several earlier releases, and also because I can't figure out how the git<-->drupal.org mechanism might be aware of something which only regards the content of the release, no? Anyway, thanks again. – cFreed Jun 14 '15 at 16:31
  • I'm sorry if I were the cause of your problem! I agree it could be related with the presence of my module, since it happened to me months ago. I never could understand what had happened (happened only on one site, while other ones worked fine with the same release), but got rid out of it merely suppressing the whole multilang folder (there is no database nor variables involved with this module). So you may consider using the same simple method. Also I just published 7.x-2.2 which fixes the bug you pointed. – cFreed Jun 14 '15 at 17:01
  • Oops (again!). Didn't pay attention to your 2nd comment, because I was immediately focused on the 3rd one. Yes, indeed, I agree that your answer is useful, so I just upvoted your answer, gladly. Please let me know if and how you could get rid of the "modules blank page". – cFreed Jun 14 '15 at 18:06
  • FYI, several points: 1: I use to be closely concerned about any problem a user may experience related with my work. It's why I quickly began examining the successive issues you pointed out, so forgetting upvote BTW. 2: I only just noticed that your answer also stated a third problemn (the PHP warning). 3: for all that, may I propose you create an issue (or may be several ones), where we can exchange more comfortably than in those comments? TIA. – cFreed Jun 14 '15 at 18:24
  • "merci" for upvote! No problem about the various items you mentioned in your recent comments. I'm also a module maintainer (and know how it is like), check my profile for a 1st impression about "my" modules. Yes I'll create appropriate issue(s) on D.O for your module (soon). Right now I'm working on (temporary) "disable" of your 2.1 module in a Drupal-compliant way (without deleting the entire module dir). So give me some time to get back to you on this ... ça va? – Pierre.Vriens Jun 14 '15 at 18:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.