Attached is an exact copy of http://ftp.drupal.org/files/projects/zen-7.x-3.x-dev.zip that has been extracted and re-zipped up using the built in windows "send to Compressed (zipped) folder" functionality. When it's uploaded to drupal it the theme uploader reports "zen.zip does not contain any .info files." and it is rejected.
If the same files are zipped using winrar, they work fine. Normally I would just use winrar, but this is going to frustrate many theme designers and I'm building a theme generator at http://cooltemplate.com and the library that I'm using to create zips also has the problem.
I suspected that there was a problem with the path separators being different but I changed my code to produce forward slashes instead of backslashes and it didn't fix the problem. Now I suspect that it may have something to do with the various compression methods that are supported by zip files and different zip creation programs will choose between them and one of them is not supported. Although I just checked and the zen.info appears to be using "Deflated" in both the original and the attached broken zip according to windows.
So now I have no idea what is causing it but there is definitely a valid zen.info in the attached zip file and it's not being recognized by the theme uploader.
Comment | File | Size | Author |
---|---|---|---|
#15 | 1019834-15-even_better.patch | 1.6 KB | bfroehle |
#13 | 1019834-12-fix_unable_to_read_project_name_for_some_zip_archivers.patch | 1.79 KB | bfroehle |
#8 | 1019834-8-handle_some_weird_zip_files.patch | 1.14 KB | bfroehle |
#3 | 1019834-3.patch | 599 bytes | bfroehle |
zen.zip | 209.08 KB | Lone Coder |
Comments
Comment #1
Lone Coder CreditAttribution: Lone Coder commentedIn order to help designers, the "zen.zip does not contain any .info files." error message should be more elaborate and specify exactly where the .info files are required. That a subfolder is required in the root of the archive and that each subfolder must have a .info files. I dunno if that's the requirement but it seems like it is and should say so if it is.
Comment #2
bfroehle CreditAttribution: bfroehle commentedThe problem is that in update_manager_install_form_submit, we determine the
$project
by:However for the provided zip file,
$files[0]
iszen/CHANGELOG.txt
, notzen/
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
(I'm not sure how $files[0] is provided in Windows... is the delimiter still '/' ?)
Comment #3
bfroehle CreditAttribution: bfroehle commentedImplemented my idea in #2. Now is this safe to use on Windows since it assumes the path delimiter is '/' ?
Essentially if
$files[0]
isMODULE/aaa/bbb/ccc.file
(or the Windows analog), we want to set$project
toMODULE
.Comment #4
bfroehle CreditAttribution: bfroehle commentedFor safety, maybe we should do:
Can any Windows / path gurus comment?
Edit:
Also, we'll need to apply this same fix later on in update_manager_archive_extract().
Comment #5
carlos8f CreditAttribution: carlos8f commentedApplying correct queue/status. Uploading a theme still works the old fashioned way :)
Comment #6
webchickHm. I thought we had a DIRECTORY_SEPARATOR constant or similar.
Oh, PHP does. :) http://php.net/manual/en/dir.constants.php
Comment #7
bfroehle CreditAttribution: bfroehle commentedThanks 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...
Comment #8
bfroehle CreditAttribution: bfroehle commentedRevised 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).
Comment #9
Lone Coder CreditAttribution: Lone Coder commentedAwesome. Thanks so much for figuring out the problem and getting a patch going! I'm so glad to know what the problem is and know I wasn't wasting my time submitting the bug report.
Now that I understand the problem I might be able to tweak the zips my site is generating so they'll work.
Thanks again.
Comment #10
Lone Coder CreditAttribution: Lone Coder commentedAwesome. Thanks so much for figuring out the problem and getting a patch going! I'm so glad to know what the problem is and know I wasn't wasting my time submitting the bug report.
Now that I understand the problem I might be able to tweak the zips my site is generating so they'll work.
Thanks again.
Comment #11
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedComment #12
Sarenc CreditAttribution: Sarenc commentedInterestingly 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.
Comment #13
bfroehle CreditAttribution: bfroehle commentedI'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.Comment #14
bfroehle CreditAttribution: bfroehle commentedI wonder if it'd be easier to just do
Comment #15
bfroehle CreditAttribution: bfroehle commentedImplemented #14 and tested locally. Much prettier code. :)
Comment #16
Sarenc CreditAttribution: Sarenc commentedJust 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.
Comment #17
bfroehle CreditAttribution: bfroehle commentedSarenc: 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:
will return 6 lines of
module
as one would expect. :)Comment #18
Sarenc CreditAttribution: Sarenc commentedbfroehle, I'm pretty sure.
Given a directory of sites/default/files/temp/mysubtheme
with regular theme files located in mysubtheme then running:
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
Comment #19
bfroehle CreditAttribution: bfroehle commentedWell, 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.
Comment #20
Sarenc CreditAttribution: Sarenc commentedComment #21
webchickCommitted to HEAD, thanks!
Comment #23
Dewsworld CreditAttribution: Dewsworld commentedIn my case, making zip with winrar also giving the same problem for my custom module
Comment #24
Mauro Colella CreditAttribution: Mauro Colella as a volunteer and commentedThe issue is still current on HHVM 3.8, on Ubuntu 15.04, using the nginx web server.