Update manager doesn't allow you to install a project if it finds a single "broken" module in it

The uts.module in the tests directory is for testing purposes, not for installing. It is not listed in this module's .info file and is not picked up whenever i view the modules page. What are you trying to do when this message is displayed? Are you specifically trying to install a uts module. If so, how?

I would call this a core bug as it does not occur when:
- using the admin/modules page (after downloading the tar.gz and extracting it)
- using drush dl and drush en

Moving this to the core issue queue. Someone else can determine the priority level.

This bug occurs with the Update Manager user interface, so I'm moving it to that queue.

It looks like these error messages were added as part of #936490: Update module should verify downloaded tarballs and propagate errors correctly. I agree it seems way too restrictive in its current form. One bad "module" in a project download doesn't seem like it should prevent the whole thing from being installed.

I'll leave a comment over on that issue also.

Yeah, there was some concern this was too restrictive in the earlier issues, but we just plowed ahead. However, I agree it's worth changing this (although webchick's going to kill me since it probably means breaking the strings *again*). :(

My concern is the update manager applies a different algorithm than the modules page (admin/modules) to determine the presence of a module. Also, if this page is geared towards non-technical people (who don't have access to better tools for this job), what is the likelihood they will be trying to install something other than a tarball from a project page, which is "guaranteed" to be good and for which the .info file determines the presence of a module?

I think there might be a way to do this that doesn't involve breaking strings (removing some strings, yes - but not adding new ones or breaking existing ones).

How about the attached?

To aid in testing, I made a new version of http://drupal.org/files/projects/update_test_module-7.x-7.1-A.tar.gz. That's got the goodies from http://drupal.org/node/989224 but I manually edited the .info files to remove the core directive from the packaging script and uploaded it to the new filename.

Here's what happens when you try to install that before this patch:

With the patch applied, update manager runs fine (since the root update_test_module.info says it's compatible with D7). After authorize.php when you click on the link to the modules page, here's what you see:

The docs are properly updated to reflect the new reality. No strings are modified in here. We just *remove* some strings that we don't need any longer.

Looking carefully at the code, the only case I'm concerned about now is what happens if you have a tarball without an .info files at all? I don't think it's going to handle that properly. Not sure if we care. ;) Anyway, I'll give it a bit of testing now and report back here, either with a new patch or an RTBC. Stay tuned...

Right, that fails badly. Try installing http://drupal.org/files/projects/update_test_module-7.x-4.1-A.tar.gz and you get this:

Lemme see what I can do...

Okay, here's a version that adds a new error message for the can't find any .info files at all. Patch and screenie attached. We *could* prevent breaking string freeze here inside this case by doing another file_scan_directory(), looking for .module files, and printing those like we always did. However, a) that just makes the error message even more overwhelming and verbose with no additional information, and b) it's wrong in the case of themes that are missing .info files, so we'd *still* need to print something else in that case. :( So, I'm in favor of just adding this one new string and being done with it.

Here's a screenie of the patch in action when you try to install http://drupal.org/files/projects/update_test_module-7.x-4.1-A.tar.gz via URL.

dww asked me about this string breakage, which involves basically:

-      '%archive_file contains %names which is missing an info file.',
-      '%archive_file contains the following modules which are missing info files: %names',
...
+    $errors[] = t('%archive_file does not contain any .info files.', array('%archive_file' => basename($archive_file)));

I pushed back, since it seemed like polish to me and we could make do with one of the original strings. But he pointed out that the string in question does limit this error to just modules, rather than modules and themes, so technically this qualifies as a bug fix.

So I think I am ok with this string breakage too, on the grounds that end users who run into this situation will be able to post error messages we can actually do something about.

Tested manually and will confirm that

1. Installing http://drupal.org/files/projects/update_test_module-7.x-4.1-A.tar.gz fails with:
   update_test_module-7.x-4.1-A.tar.gz does not contain any .info files.
2. Installing http://ftp.drupal.org/files/projects/mollom-7.x-1.x-dev.tar.gz succeeds without any warnings.
3. Installing http://ftp.drupal.org/files/projects/fusion-7.x-1.x-dev.tar.gz succeeds without any warnings.

(All of which are the expected behavior).

I didn't notice any coding style errors.

webchick already noted the string freeze change in the prior comment.

Great, this looks like a really nice code clean-up in addition to a bug fix likely to cause a lot of WTF for people. Thanks for the additional testing, bfroehle!!

Committed to HEAD.