1) First I tried to install view with the project link. Getting errors ==> screenshot 1...
2) Afterwards I tried to download and to upload it again to my website, giving me errors ==> screenshot 2 (known issue that need to get fixed!)
3) Next try: unpack the archive and rar it: rar is not supprted
4) Last try: unpack the archive and zip it: gives errors ==> screesnhot 3

This is kinda critical, I see this as a mother issue for all those "small" problems.
(please correct the component of this issue)

specs: Win 7 | latest head | chrome

CommentFileSizeAuthor
#30 790224-module-upload-28.patch1.72 KBlotyrin
#28 790224-module-upload-28.patch1.72 KBlotyrin
#26 790224-module-upload-26.patch1.72 KBlotyrin
#25 790224-class-array-25.patch669 byteslotyrin
#23 790224-class-array-22[2].patch679 byteststoeckler
#22 790224-class-array-22.patch666 byteslotyrin
#8 790224-temp-path-7.patch1.07 KBpwolanin
screenshot3.PNG43.36 KBaspilicious
screenshot2.PNG28.8 KBaspilicious
screenshot1.PNG29.38 KBaspilicious
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

juliangb’s picture

juliangb CreditAttribution: juliangb commented

Point 3 - have a look at your screenshots and you will see that there is a list of supported compression methods. rar is not one of them. So yes, it isn't supported. If it doesn't claim to be supported, it isn't a bug that it isn't.

aspilicious’s picture

aspilicious CreditAttribution: aspilicious commented

Yes I know that, I shouldn't report this together with those other ones. I can't edit the original post. So if someone can remove point 3...

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

This is what i get on LAMP:

Warning: mkdir(): No such file or directory in update_manager_file_get() (line 715 of /var/www/checkouts/05april/drupal/modules/update/update.manager.inc).
HTTP error 1 occurred when trying to fetch http://ftp.drupal.org/files/projects/views-7.x-3.x-dev.tar.gz.
Unable to retrieve Drupal project from http://ftp.drupal.org/files/projects/views-7.x-3.x-dev.tar.gz.

Gonna look into it some more! Probably entered something wrong. :)

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

one of the issues is right here: 

  $cache_directory = DRUPAL_ROOT . '/' . file_directory_path('temporary') . '/update-cache/';

  if (!file_exists($cache_directory)) {
    mkdir($cache_directory);
  }

cache_directory variable ends up(on a linux system): "drupal//tmp/update-cache/"

I dont know what function or way Drupal goes to check what the temp directory on the host system is. But on a linux system this is usually /tmp . What is wrong here is probably adding DRUPAL_ROOT because i can see that you wanna use /tmp on a linux system and all other UNIX system i know of including OSX. I dont know how this will react on a windows system.

If someone wanna check what drupal wanna use for temp in windows just put this code somewhere and check the output(i used the block admin gui): 

$cache_directory = file_directory_path('temporary');
var_dump($cache_directory);

This regards the:


Warning: mkdir(): No such file or directory in update_manager_file_get() (line 715 of /var/www/checkouts/05april/drupal/modules/update/update.manager.inc).

Looking into it some more.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

yes, this is clearly a bug:

 $cache_directory = DRUPAL_ROOT . '/' . file_directory_path('temporary') . '/update-cache/';

Since the temp file path is likely to be outside the docroot and may be an absolute path.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Exactly, it creates the directory fine without drupal doc root in there. Im gonna make a patch for this as soon as i have sorted out why i get the other problems.

I thought it had something to do with temporary:// stream wrapper thingy but im not sure.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Made the following changes

The same error was on line 638 as the one previously mentioned. And there was an error at line 711:

$local = 'temporary://update-cache/' . basename($parsed_url['path']);

should be

$local = 'temporary://update-cache/';

basename($parsed_url['path']) is being run in "system_retrieve_file()"

Now i get the following error:

Archivers can only operate on local files: temporary://update-cache/ not supported

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
FileSize
790224-temp-path-7.patch1.07 KB

Here's a start on a patch.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
Status: Active » Needs review
pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

@nenne I was worried about that last error re: archivers. Looks like at some added point we need to use drupal_realpath()

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Archivers can only operate on local files: /tmp/update-cache not supported

and with whole file path:

Archivers can only operate on local files: /tmp/update-cache/views-7.x-3.x-dev.tar.gz not supported

Pretty weird. Does it require a Drupal doc_root based url to consider it "local"?

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented

#8 worked for me on Mac 10.5 to install Views from http://ftp.drupal.org/files/projects/views-7.x-3.x-dev.tar.gz

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Im back at :

HTTP error 1 occurred when trying to fetch http://ftp.drupal.org/files/projects/views-7.x-3.x-dev.tar.gz.
Unable to retrieve Drupal project from http://ftp.drupal.org/files/projects/views-7.x-3.x-dev.tar.gz.

With the patch. trying to figure out why.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

After your patch:

If i remove " . basename($parsed_url['path'])" from line 712 its back at the Archiver local stuff problem.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Ok, after some more research i have come to the following conclusion:

I get the furthest with your patch applied. It creates the temp dirs in /tmp and downloads the file only to go to a blank screen. This seems to be when the extracting should occur. The file is in /tmp/update-cache/... but the /tmp/update-extraction/ is empty.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
Title: Impossible to install contribute module through website interface » Impossible to install contributed modules through website interface

@nenne what type of system? php version? can you check your php error log?

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

I use Ubuntu 10.04 with PHP locked to 5.2 Karmic repos.

If i use the archiver_get_archiver() function on the file and dumps the variable it looks good(i believe): 

object(ArchiverTar)#14 (1) {
  ["tar:protected"]=>
  object(Archive_Tar)#15 (6) {
    ["_tarname"]=>
    string(42) "/tmp/update-cache/views-7.x-3.x-dev.tar.gz"
    ["_compress"]=>
    bool(true)
    ["_compress_type"]=>
    string(2) "gz"
    ["_separator"]=>
    string(1) " "
    ["_file"]=>
    int(0)
    ["_temp_tarname"]=>
    string(0) ""
  }
}

My setup might be considered a bit weird seeing as its a 10.04 with PHP held back. Would be great of more linux people could try this!

aspilicious’s picture

aspilicious CreditAttribution: aspilicious commented

Patch in #8 solves my issue, but it leaves the overlay while installing...

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Windows and Mac verified. I will continue looking into it on Linux. It extracted on my 8.04 vps but left a weird error concerning forms:

Fatal error: [] operator not supported for strings in /var/www/includes/form.inc on line 2657

lotyrin’s picture

lotyrin CreditAttribution: lotyrin commented

Also getting blank screen (/authorize.php) on Ubuntu 10.4, (but with default php version)

It's past the extraction step though, I have extracted modules in /tmp/update-extraction

If I load a normal Drupal page after trying to install the module, I get the following warning:

WARNING: You are not using an encrypted connection, so your password will be sent in plain text. Learn more.

The same happens if I simply attempt to load authorize.php (same blank page, same warning.)

lotyrin’s picture

lotyrin CreditAttribution: lotyrin commented

After some hunting through logs, I believe this is the error message from the blank authorize.php page:

[Thu May 06 20:06:43 2010] [error] [client 127.0.0.1] PHP Fatal error: [] operator not supported for strings in /var/www/drupal/includes/form.inc on line 2657, referer: http://localhost/

So it looks like I'm in the same place as nenne in #19.

line 2657 is in form_process_fieldset():

$element['#attributes']['class'][] = 'form-wrapper';

$element['#attributes']['class'] is supposed to be an array of classes, but it looks like it's set as a single string on a fieldset somewhere in the authorize form.

Going to see if I can find where.

lotyrin’s picture

lotyrin CreditAttribution: lotyrin commented
FileSize
790224-class-array-22.patch666 bytes

Found it.

My first patch. Sorry if I've formatted it incorrectly.

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented
FileSize
790224-class-array-22[2].patch679 bytes

Good catch lotyrin. Rerolled for single quotes per coding standards. Not tested.

Status: Needs review » Needs work

The last submitted patch, 790224-class-array-22[2].patch, failed testing.

lotyrin’s picture

lotyrin CreditAttribution: lotyrin commented
Status: Needs work » Needs review
FileSize
790224-class-array-25.patch669 bytes

Using single quotes now.

#23 won't work (even with proper line-endings), since it's going to have the literal '$name' instead of its value.

lotyrin’s picture

lotyrin CreditAttribution: lotyrin commented
FileSize
790224-module-upload-26.patch1.72 KB

Here is #25 and #8 rolled into a single patch.

Status: Needs review » Needs work

The last submitted patch, 790224-module-upload-26.patch, failed testing.

lotyrin’s picture

lotyrin CreditAttribution: lotyrin commented
FileSize
790224-module-upload-28.patch1.72 KB

After reading through the style guideline, this patch should be correct.

Double-quoted strings are allowed in the case that there's an inline variable.

Not sure why #26 wouldn't apply.

lotyrin’s picture

lotyrin CreditAttribution: lotyrin commented
Status: Needs work » Needs review

Forgot to set status.

lotyrin’s picture

lotyrin CreditAttribution: lotyrin commented
FileSize
790224-module-upload-28.patch1.72 KB

Just read about how the patch queue works.

Sorry. I'm learning.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Great work, i will try it on my VPS later when i get the time.

dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Status: Needs review » Closed (duplicate)

#693084: Regression: file_munge_filename() extension handling broken by move to File Field

lotyrin’s picture

lotyrin CreditAttribution: lotyrin commented
Status: Closed (duplicate) » Needs review

dww: Forgive me if I'm wrong, but It looks like that issue is at play in the original report, but that's not all that was going on here.

This patch fixes temporary file management that fixes an assumption that your temp file directory is in your drupal root (so you get drupal//tmp when you really wanted /tmp) and a fixes a problem in the authorization form.

The issue you linked doesn't include those fixes.

jpmckinney’s picture

jpmckinney CreditAttribution: jpmckinney commented

Having worked on that linked issue, I can confirm that it is not duplicate of this issue.

alanburke’s picture

alanburke CreditAttribution: alanburke commented

Patch works for me, in that it gets rid of the Errors displayed when trying to install a module via the web interface.

pwolanin’s picture

pwolanin CreditAttribution: pwolanin commented
Status: Needs review » Reviewed & tested by the community

seems like this is a verified fix.

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented

Yeah, I concur that this seems like a pretty straight-forward path fix, rather than mucking about with missed Upload => File upgrade path snafus like the referenced issue. dww, if you know something we don't, please feel free to follow-up.

Committed to HEAD. Great job on your first patch, lotyrin! :D And thanks for all the great testing, everyone!

Unfortunately, this sort of obvious oversight means we don't have any test coverage for this. :( But I've spoken to dww about this before, and he said it's not really possible to test this on testbot because of the requirement for FTP, etc. :( So if the folks in this issue could continue checking this from time to time from now until release, it'd be really appreciated!

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
CreditAttribution: webchick commented
Status: Reviewed & tested by the community » Fixed
dww’s picture

dww
we/he/they
CreditAttribution: dww commented
Title: Impossible to install contributed modules through website interface » Impossible to install contributed modules through website interface when the site's temp directory is outside the drupal root

Yeah, sorry about the false duplicate -- it was mostly based on the title of the issue, not the underlying bug this patch was targeting.

It seems there are multiple ways things can go wrong in the update manager depending on all the corner cases for how various pieces are configured. Something that our testing infrastructure is bad about testing in general, and all the more in this specific instance because the worst parts of the update manager can't be tested by our infrastructure at all.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

DocDJ-forum’s picture

DocDJ-forum CreditAttribution: DocDJ-forum commented
Issue summary: View changes

I don't know if this is the proper place to put this problem. I have not seen it in searching the fora.
On my Windows 10 system with Drupal 7.41, when I try to update ANY Drupal modules from inside Drupal OR from "drush pm-update projects drupal-7.42", either method tries to download .tar files instead of the corresponding .zip files. This never happened on Windows 7, but and it is preventing me from doing a CORE update. I can manually update extension modules, by downloading and copying the proper .zip files, but don't know what to do for a core update and WOULD really like to use the built-in interface for normal module updates.

Could the errors reported above be related to my problem? What can I do?