No .info files reported on theme upload when zip created with certain programs

The problem is that in update_manager_install_form_submit, we determine the $project by:

  // Unfortunately, we can only use the directory name for this. :(
  $project = drupal_substr($files[0], 0, -1);

However for the provided zip file, $files[0] is zen/CHANGELOG.txt, not zen/ as in the zip provided on drupal.org.

What we'll need to do is find the name of top level directory in $files[0]... perhaps

// Unfortunately, we can only use the directory name for this. :(
$project = explode('/', $files[0], 2);
$project = $project[0];

(I'm not sure how $files[0] is provided in Windows... is the delimiter still '/' ?)

Implemented my idea in #2. Now is this safe to use on Windows since it assumes the path delimiter is '/' ?

Essentially if $files[0] is MODULE/aaa/bbb/ccc.file (or the Windows analog), we want to set $project to MODULE.

For safety, maybe we should do:

$project = explode('/', str_replace('\\', '/', $files[0]), 2);
$project = $project[0];

Can any Windows / path gurus comment?

Edit:
Also, we'll need to apply this same fix later on in update_manager_archive_extract().

Applying correct queue/status. Uploading a theme still works the old fashioned way :)

Hm. I thought we had a DIRECTORY_SEPARATOR constant or similar.

Oh, PHP does. :) http://php.net/manual/en/dir.constants.php

Thanks webchick! Although I still worry that since this file listing is coming from the php zip module, it might differ from more core PHP conventions...

Revised patch taking into account the comments in #4-7. (Manually tested and was able to install the provided zen.zip from both URL and local file upload).

Interestingly when listing files of an archive created by Drupal's own implementation of Archive_Tar the trailing slash doesn't exist. This patch is much appreciated.

I'm uploading a new patch which should be easier to read and has some more descriptive comments.

No substantive code change, except that it assigns a partial result ($path = str_replace('\\', '/', $files[0]);) to a variable which is unused elsewhere in each function.

I wonder if it'd be easier to just do

$project = strtok($files[0], '/\\');

Implemented #14 and tested locally. Much prettier code. :)

Just a note that there are actually three possibilities here in regards to the first file listed by $archive->listContents();.

1) the expected behaviour: module/
2) no directory name by itself: module/readme.txt
3) the directory name with no trailing slash: module

As I noted above the third possibility is how Drupal's own implementation of Archive_Tar produces tar archives.

The latest patch does seem to account for all these possibilities.

Sarenc: Are you sure? If so, it would have be impossible for the Drupal 7.0 code to work with tar formats but I haven't seen any bug reports mentioning that.

Edit: Even so, it doesn't matter. For example:

$files = array('module/', 'module/readme.txt', 'module', '/module', '/module/readme.txt', '/module');
foreach ($files as $file) {
  print strtok($file, '/\\') . "\n";
}

will return 6 lines of module as one would expect. :)

bfroehle, I'm pretty sure.

Given a directory of sites/default/files/temp/mysubtheme

with regular theme files located in mysubtheme then running:

chdir('sites/default/files/temp');
$obj = new Archive_Tar('mysubtheme.tar');
$handle = opendir('./'); 
$obj->create('./mysubtheme');

when running $files = $archive->listContents(); we get 'mysubtheme' for $files[0] not 'mysubtheme/'

maybe the archiving method could be changed but as you say strtok($files[0], '/\\'); works regardless so it doesn't matter in the end :)

Cheers

Well, the patch in #15 seems pretty well tested by now (especially in light of the experimentation with strtok in #17), but I'm not going to mark RTBC since I was the patch author.

Committed to HEAD, thanks!

In my case, making zip with winrar also giving the same problem for my custom module

The issue is still current on HHVM 3.8, on Ubuntu 15.04, using the nginx web server.