"Installation failed" errors when installing modules from Update Manager w/ Overlay

can you test install other modules or themes.

Updating to correct component.

FWIW, I'm trying to replicate this on HEAD right now and it's just hanging at "Preparing to install".

It works fine for me, but I'm doing it locally, with the webserver user as owner of the Drupal files in the filesystem (in which case you skip the step where you have to type in FTP credentials, etc).

Are people who are experiencing this doing it on a setup where you need to type FTP credentials or the like? If so, I wonder where the problem occurs in relation to that step?

Interesting. So I hit this when I tried to install BUEditor via update manager on my "core" install where I review/commit all my patches:

Text version:

The last line tells me "See the log below for more information." and there is no log. :P~ I'll make a separate bug report for that.

But when I tried it from a fresh installation I didn't have any errors, and things worked as expected.

afaaro: Can you confirm you're not trying this on an old copy of Drupal 7? And if so, can you try it on a fresh copy of an up-to-date version and see if you have the same issue?

I've just had this exact error message (without the log file as described) trying to install the Token module 7.x-1.0-alpha3 in a fresh install of 7.0-beta1 (MySQL 5.1.48, PHP 5.3.3). I was installing by uploading to my server a local copy of the gzipped tarball using the Module Install command. I was trying this because I had a similar message uploading the Views module using the direct download option. Both modules appear to be installed - they show up in the admin queues and I can adjust some of the settings although I haven't used either of them yet. That's why I hadn't posted yet.

I just did a fresh install of 7.0-beta1, standard profile on a MAMP stack. Installed bueditor-7.x-1.0-beta2 from http via update manager, without error. Removed the bueditor directory. Updated files to 7.x-dev (9c8e77e... in git). Ran update.php, then successfully installed bueditor again. In short, I wasn't able to reproduce this.

Something odd is happening, as the error message in @webchick's post only happens if $success = FALSE and since $results['log'] isn't set, this means that function update_authorize_install_batch_finished($success, $results) is being called with $success = FALSE (and probably $results = NULL).

Perhaps somehow _batch_finished is getting called before the batch is processed?

It sounds like there are enough reports above (as well as at a number of issues I just marked duplicate) that this can occur on a fresh installation also, and therefore it should probably be considered a real bug.

The duplicate issues I closed were these:
#951558: Error when adding the module files via UI.
#953708: Error: "Undefined index: log in update_authorize_install_batch_finished" when installing modules on freshly installed D7 beta2
#1000650: installation failed message trying to upload module via URL

It really seems like it's a sporadic error that isn't regularly reproducible - it's not clear yet what the specific trigger is, I guess :(

I just encountered this exact error on a brand new download of D7. It was the first step I took with the new installation... run the installer, copy and paste the views path into the "install from URL" field, get error.

Notice: Undefined index: log in update_authorize_install_batch_finished() (line 236 of /*****/modules/update/update.authorize.inc).
Warning: Invalid argument supplied for foreach() in update_authorize_install_batch_finished() (line 236 of /*****/modules/update/update.authorize.inc).
Notice: Undefined index: log in update_authorize_install_batch_finished() (line 277 of /*****/modules/update/update.authorize.inc).
Notice: Undefined index: tasks in update_authorize_install_batch_finished() (line 278 of /*****/modules/update/update.authorize.inc).
Installation failed! See the log below for more information.

Same problem here. New Drupal 7.x-1.0 install created yesterday on a local WAMP server; the error occurred when I tried to install the Compact Forms 7.x-1.0 module from the Upload field. Error message is exactly the same as above, including "see the log below" but no actual log. The module appears to be installed correctly, as was rosborn's experience.

Other duplicates:
#1032450: install postgresql 9

Has anybody managed to reliably reproduce this? Is there anything in common about the modules which are installed? Is it purely random?

I have exactly the same issue on a very fresh installlation.
I'm using XML Sitemap, Service Links, Views, Chaos Tools, Token, Pathauto, WYSIWYG, CKEditor

I have had this problem too. Both for organic groups and views.
It seems random though. I just tried to install views and got the error. Tried again right after that and it worked. Tried uninstalling views and removing all the files and installing again. Worked just fine.

I keep getting this error every time I try to update any module. I try 2 so far "Google Analytics" and "XML Sitemap".

There is also an error that starts with AJAX... but I only see it for a split second and this error comes up:

* Notice: Undefined index: log in update_authorize_update_batch_finished() (line 174 of /home1/existonl/public_html/modules/update/update.authorize.inc).
* Warning: Invalid argument supplied for foreach() in update_authorize_update_batch_finished() (line 174 of /home1/existonl/public_html/modules/update/update.authorize.inc).
* Notice: Undefined index: log in update_authorize_update_batch_finished() (line 223 of /home1/existonl/public_html/modules/update/update.authorize.inc).
* Update failed! See the log below for more information.

-------------

Today I tried to update Advanced help and got this error:

* The specified file temporary://fileI4ud6f could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
* http://ftp.drupal.org/files/projects/advanced_help-7.x-1.0-beta1.tar.gz could not be saved to temporary://update-cache/advanced_help-7.x-1.0-beta1.tar.gz.
*
Downloading updates failed:
o Failed to download advanced_help from http://ftp.drupal.org/files/projects/advanced_help-7.x-1.0-beta1.tar.gz

I've been doing a bunch of module installs and upgrades on two different Drupal 7 sites over the last two weeks and have not reproduced the error that I experienced in #10. However I transferred the site from my WAMP server to a remote development server so I'm not in the same environment I was then.

At the time I reported the error, I had the following modules installed:
Admin Menu, Backup & Migrate, Views, CTools, Wysiwyg, Environment Indicator, Devel, l10n Update, Pathauto, Typogrify, Token, Translation Management, OG, and I was installing Compact Forms when the error occurred.

I received this error today with Service Links module. Do not recall receiving upon installation but rather when I loaded any node where the service links (social media icons) display.

Fresh Drupal 7 (release version) install.

Got error on first try on og but second try succeeded. Running fully updated D7.

In my case, it is a debilitating error. Had to disable the Services Links module.

I can install other modules, but it doesn't like modules like Rate

What is the status on this? Anyone looking into this? This is breaking modules.

This is the line that the Services Links module, for example, is chocking on:

$service['attributes']['title'] = $service['description'];

I am getting this error on a fresh D7 install with very few contrib modules, which I have tested disabled.

greta_drupal: The current status is that the failures (as described in the original post) seem to happen only sporadically and nobody has posted a reliable way to reproduce them.

Your error in #20 seems unrelated.

One way of finding intermittent bugs is to read the code. In this case look at where the queries come in and how they are handled, in particular look at handling of errors at all possible points. I predict that there is some place that is not handling errors.

Same here:

Notice: Undefined index: log in update_authorize_install_batch_finished() (line 236 of /home/keek/public_html/modules/update/update.authorize.inc).
Warning: Invalid argument supplied for foreach() in update_authorize_install_batch_finished() (line 236 of /home/keek/public_html/modules/update/update.authorize.inc).
Notice: Undefined index: log in update_authorize_install_batch_finished() (line 277 of /home/keek/public_html/modules/update/update.authorize.inc).
Notice: Undefined index: tasks in update_authorize_install_batch_finished() (line 278 of /home/keek/public_html/modules/update/update.authorize.inc).
Installation failed! See the log below for more information.

When trying to install pathauto 7.x-1.0-beta1.
Clean drupal install, except for the WYSIWYG module.

Subscribe.

Same here. Nearly every module installation gives the mentioned warnings.

Notice: Undefined index: log in update_authorize_install_batch_finished() (line 236 of /www/htdocs/w005aa45/schaffa-neu/modules/update/update.authorize.inc).
Warning: Invalid argument supplied for foreach() in update_authorize_install_batch_finished() (line 236 of /www/htdocs/w005aa45/schaffa-neu/modules/update/update.authorize.inc).
Notice: Undefined index: log in update_authorize_install_batch_finished() (line 277 of /www/htdocs/w005aa45/schaffa-neu/modules/update/update.authorize.inc).
Notice: Undefined index: tasks in update_authorize_install_batch_finished() (line 278 of /www/htdocs/w005aa45/schaffa-neu/modules/update/update.authorize.inc).

As well as i do.. I installed Drupal 7 a few day's ago, and getting this error:

Error message
Notice: Undefined index: log in update_authorize_update_batch_finished() (line 174 of /home/xxxx/public_html/xxxx/administrator/modules/update/update.authorize.inc).
Warning: Invalid argument supplied for foreach() in update_authorize_update_batch_finished() (line 174 of /home/xxxx/public_html/xxxx/administrator/modules/update/update.authorize.inc).
Notice: Undefined index: log in update_authorize_update_batch_finished() (line 223 of /home/xxxx/public_html/xxxx/administrator/modules/update/update.authorize.inc).
Update failed! See the log below for more information. Your site is still in maintenance mode.
Next steps

Your modules have been downloaded and updated.
Run database updates

Could you report how you're installing the modules? Is it via file upload or URL? And what file extension? (.tar.gz vs. .zip?)

We hit some funny things in the last leg of our recent D7 "webchick tour" training, and I suspect it might be isolated to one or the other of those. Curious if there are trends.

I downloaded the .tar.gz, and uploaded via FTP.

I have run into this as well a couple times on my my site (running latest D7). So far it has happened only with modules that are not tagged as Recommended Releases (and are not effortlessly Drush-able so I decided to try the Add Module via URL). This doesn't happen every time--for example, I successfully added CCK Signup and Views using the same method (via tar.gz url) with no problem. The site is local and running on a MAMP setup with Apache/2.0.63 (Unix) PHP/5.2.13 DAV/2, MySQL client version: 5.1.44, PHP extension: mysql

This most recently happened with Services 7.x-3.0-rc1 where I added the module via the tar.gz url.
Here is the error I got:

Notice: Undefined index: log in update_authorize_install_batch_finished() (line 236 of /Users/sarahb/git/mysite/modules/update/update.authorize.inc).
Warning: Invalid argument supplied for foreach() in update_authorize_install_batch_finished() (line 236 of /Users/sarahb/git/mysite/modules/update/update.authorize.inc).
Notice: Undefined index: log in update_authorize_install_batch_finished() (line 277 of /Users/sarahb/git/mysite/modules/update/update.authorize.inc).
Notice: Undefined index: tasks in update_authorize_install_batch_finished() (line 278 of /Users/sarahb/git/mysite/modules/update/update.authorize.inc).
Installation failed! See the log below for more information.

Back in Terminal I see that Services has been added to sites/all/modules and through the admin GUI I see it's been installed.
[Note: It also looks like this issue: #1071908: Intalling Through UI (Update Manager) Get Series of Errors is a duplicate.]

I got around this error!

I found that i would always get this error when using the overlay. Once I've disabled the overlay, i don't get any errors during an upgrade!

It's most likely something to do with the overlay "modal" screen and what type of browser you are using.

If you disable the overlay, then everything works. (At least for me)

the overlay was nice for the first few weeks, but than became a huge nuisance, not to mention how slow it makes response times.

Einewton: Nice sleuthing! That would help to explain why it's intermittent; once you've used it the first time you're kicked out of the overlay, so subsequent modules wouldn't have the same issue.

Can anyone else confirm?

@webchick: I had the problem via installing through the .tar.gz file and activating with overlay. Will try it again without overlay.

This seemed to have corrected my problem (#20). I disabled overlay then re-enabled the Services module and no more error (so far). Re-enabled overlay, since the admin menu covers up the overlay close x-link, and still works fine.

I can also confirm that I was able to install via tar.gz url with no errors with the admin overlay disabled.

steps taken:
1) installed tar.gz module via url with overlay. Result: errors with an Installation Failed! notice (but the module still appeared in sites/all/modules)
2) installed tar.gz module via url with overlay disabled. Result: success

Tested in firefox and chrome, and with a note that installing modules with overlay enabled does not necessarily trigger the error but I have yet to get the error with the overlay disabled.

FWIW here is the AJAX error I get when the module upload fails (as noted in #14):

An error has occurred.
Please continue to the error page
An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: http://mysite.dev/authorize.php?batch=1&render=overlay&id=7&op=do StatusText: OK ResponseText: Welcome to mysite.dev | mysite.dev @import url("http://mysite.dev/modules/system/system.base.css?lh4y7u"); @import url("http://mysite.dev/modules/system/system.menus.css?lh4y7u"); @import url("http://mysite.dev/modules/system/system.messages.css?lh4y7u"); @import url("http://mysite.dev/modules/system/system.theme.css?lh4y7u"); @import url("http://mysite.dev/modules/comment/comment.css?lh4y7u"); @import url("http://mysite.dev/modules/field/theme/field.css?lh4y7u"); @import url("http://mysite.dev/modules/node/node.css?lh4y7u"); @import url("http://mysite.dev/modules/search/search.css?lh4y7u"); @import url("http://mysite.dev/modules/user/user.css?lh4y7u"); @import url("http://mysite.dev/sites/all/modules/ctools/css/ctools.css?lh4y7u"); @import url("http://mysite.dev/themes/bartik/css/layout.css?lh4y7u"); @import url("http://mysite.dev/themes/bartik/css/style.css?lh4y7u"); @import url("http://mysite.dev/themes/bartik/css/colors.css?lh4y7u"); @import url("http://mysite.dev/themes/bartik/css/print.css?lh4y7u"); Skip to main content mysite.dev Main menuHome User login Username * Password * Create new account Request new password Welcome to mysite.dev No front page content has been created yet. Powered by Drupal

(edited to add error)

Marked #1090420: Installation failure as a duplicate.

@ draku007 - Re" Post # 14 above.
.
.
The problem..

---------------------------
* The specified file temporary://fileI4ud6f could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions.
---------------------------

.. in addition to other errors, is caused
by the default 'Temporary directory' field-box choice "/tmp"
on webhost installations of Drupal 7
and has nothing to do with whether the 'Overlay" is on or off.

Per my experiences and in my opinion
it is not a problem with Drupal code
but rather a problem with the webhost.

See http://drupal.org/node/1106492 for more details.

In a nut-shell, the first solution I would suggest trying is ..

Go to 'Configuration' > 'Media' > 'File System'
[*root*]/admin/config/media/file-system
and change the 'Temporary directory' from
/tmp
to
/any-name-that-works-by-trial-and-error

@Christopher James Francis Rodgers, thanks for the post but there is no need to spam it everywhere on drupal.org, especially on issues that are unrelated like this one.

So it seems like we've narrowed this down enough to change the title.

Anyone willing to dig in and see what's up? :)

@bfroehle

I personally do not consider attending
to each and every individual's concern
on each and every one of their issue pages
about their error..
"The specified file temporary://file****** could not be copied,
because the destination directory is not properly configured..."
..issue as being spam.

I call it due diligence.

Though I must admit that you are correct
that my posting on this page was a little bit
"out on a limb".

Very simply, I was trying to address
draku007 's posting in #14 above.

I truly intend all the best for all of you.

- Chris.

FYI: Notice of comment #36 Update
relating to error #2 from @ draku007 in Comment # 14;
though likely unrelated to this issue page in general.

Disabling overlay and using a stable release seems to have fixed it for me too.

I have mixed feelings about the overlay mode and have not tried turning it off yet as I would like to like it. But it seems to me that this is a real bug (maybe hard to find) and that if Drupal is serious about using the overlay mode, then they should fix the bug.

Seems clear the problem exists in Overlay and not the update system.

This was a real pain to track down, but I think the attached patch fixes it.

The problem can be traced to the fact that authorize.php doesn't do a full Drupal bootstrap (it's effectively a non-Drupal script, for practical purposes). This means the overlay never gets closed properly after the module install/update form is submitted, and you wind up with a race condition. Specifically:

1. The form is submitted and redirects to authorize.php which loads inside the overlay (no full bootstrap, so the overlay PHP code cannot tell it to break out of the overlay before loading).
2. Once authorize.php is loaded in the overlay, the JavaScript code in the parent window recognizes that it's not a standard Drupal admin page, so it needs to close the overlay. It does so, and redirects to authorize.php outside the overlay.
3. The end result is that authorize.php is loaded twice.
4. Normally that wouldn't be so bad, but in the case where you're running Drupal on a not-very-well-secured server (where the webserver owns the Drupal source files), that's where the bug occurs. (Someone can correct me if I'm wrong, but as far as I know this bug only occurs on that type of server setup.) In those cases, authorize.php doesn't stop and prompt you for your FTP credentials, so it simply starts running the module install/update batch process immediately after it's loaded.
5. So now there are two threads trying to run the same batch process at the same time. The second one kind of interrupts the first one (leading to the AJAX error that briefly flashes on your screen and which was mentioned in #14) but this is all running via JavaScript so both can contact the server simultaneously and you wind up with a really ugly race condition. If you're unlucky and the timing is wrong, one thread will finish the batch but when it loads the batch data from the database it gets the (still unfinished) data from the other thread, leading to the error messages.

The attached patch isn't the prettiest fix, but it seems to be effective. Maybe a better fix would be to keep the update manager + authorize.php workflow inside the overlay entirely, but that's a separate issue (#821248: Installing a module or running updates from the overlay makes you leave the overlay but doesn't bring you back.) which is likely a lot more complicated to do.

Needs to go in D8 first, but the same patch applies equally to D7 and D8 so it can be tested/reviewed against either.

Adding the standard tag to indicate this is a D7 issue also...

#45: overlay-update-manager-936686-44.patch queued for re-testing.

Patched 7x, works as expected - thanks!

Should this be RTBC?

Nice detective work, David. The patch looks correct to me, but I'm not confident enough in my review to mark it RTBC. Session variables always make me unhappy.

Hi! Thanks for the great work!

I have an issue on applying the patch:
I go into the drupal root folder and then
> patch -p 1 < overlay-update-manager-936686-44.patch
patching file modules/overlay/overlay.module
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]

I'm not familiar enough with the patch system yet to know what to do ... Could a kind soul advise ?

Thanks a lot

This patch worked for me. I have to look at the code a bit more closely.

Where do I copy this patch to and run it?
I have multiple drupal sites running on the same cpanel account.
1 of my sites installs ok and the other 2 do not.

That $_SESSION stuff is definitely rather ooky. However, it's isolated to the Overlay module, and this is a really terrible bug that breaks demos and causes all manner of duplicate reports. I can't suggest anything better, so let's go with this for now.

Committed and pushed to 8.x and 7.x. Thanks!

same problem when I try to install Organic groups 1.3 (for dev all ok) and zen 7.x-5.x-dev

clear drupal 7.9
first install Entity API
then og 1.3

if install og first and then Entity API, have another bug

Please open a new issue for that bug report and link to it from this one. Since this already had a fix committed, if you having similar problems it's likely the cause is different.

Same problem happening with me. I have installed a fresh copy of d7x.14 . I am not even using overlay and the problem still persists.

I was trying to install views module with web interface. Initially it was showing a problem mentioned in comment #36 but then I corrected it. Then it started to show this first:

An AJAX HTTP request terminated abnormally. Debugging information follows. Path: http://domain-name.com/authorize.php?batch=1&id=12&op=do StatusText: ResponseText: ReadyState: 4

and then :

Notice: Undefined index: log in update_authorize_install_batch_finished() (line 235 of /home/username-here/public_html/modules/update/update.authorize.inc).
Warning: Invalid argument supplied for foreach() in update_authorize_install_batch_finished() (line 235 of /home/username-here/public_html/modules/update/update.authorize.inc).
Notice: Undefined index: log in update_authorize_install_batch_finished() (line 276 of /home/username-here/public_html/modules/update/update.authorize.inc).
Notice: Undefined index: tasks in update_authorize_install_batch_finished() (line 277 of /home/username-here/public_html/modules/update/update.authorize.inc).
Installation failed! See the log below for more information.

It only happens when I try to install through web interface. uploading files through FTP client seems to be working fine for me. I am not having any problem with my local installation. It's working just fine even when installing through web interface.

Please see #58