Upload multiple images at once (archive/php_zip support)

Thanks for the contribution. Would be a great, really great feature. Right now I'm still getting the following error:

warning: sort() expects parameter 1 to be array, null given in C:\wamp\www\arw-alpha\modules\imagefield-5.x-1.2-rc1\imagefield\imagefield.module on line 362.
warning: Invalid argument supplied for foreach() in C:\wamp\www\arw-alpha\modules\imagefield-5.x-1.2-rc1\imagefield\imagefield.module on line 226.

Any idea's?

Dimm, you rock! I'll try to get some of this hooked up after I finish the d6 ports...

Dimm: Thanks for the reply. Used a zip file. Tried it on a windows machine. Can try Unix. I'll let you know what comes up...

Dimm: thanks for your work, but i have a trouble. I use a multiple_upload_v02 when i upload zip/tar.gz file - i have a warning message:

# warning: mkdir() [function.mkdir]: No error in Z:\home\likeleto5\www\sites\all\modules\imagefield\imagefield.module on line 291.
# warning: sort() expects parameter 1 to be array, null given in Z:\home\likeleto5\www\sites\all\modules\imagefield\imagefield.module on line 373.

Is it possible to make this patch for Version 5.x-2.1?

to dimm: there is no such directory usr/bin/ (perl.exe, php.exe files), on both systems (windows/unix). My site is hosted on a shared environment (unix). I use a Windows system for development.
Actually havo no clue how to proceed. Ideas?

@dimm: please upload patches instead of zipped modules...

@dimm: Thank you very much for the 5.x-2.1-patch!

Thank you for patch.
I patched it. I have unzip in usr/bin.
But got this errors:

# warning: mkdir(): No such file or directory in /var/www/vhosts/autobin.ru/httpdocs/modules/imagefield/imagefield.module on line 461.
# warning: mkdir(): open_basedir restriction in effect. File(/P1030467.zip_dir) is not within the allowed path(s): (/var/www/vhosts/autobin.ru/httpdocs:/tmp) in /var/www/vhosts/autobin.ru/httpdocs/modules/imagefield/imagefield.module on line 526.
# warning: opendir(): open_basedir restriction in effect. File(/P1030467.zip_dir) is not within the allowed path(s): (/var/www/vhosts/autobin.ru/httpdocs:/tmp) in /var/www/vhosts/autobin.ru/httpdocs/modules/imagefield/imagefield.module on line 535.
# warning: opendir(/P1030467.zip_dir): failed to open dir: Operation not permitted in /var/www/vhosts/autobin.ru/httpdocs/modules/imagefield/imagefield.module on line 535.
# warning: mkdir(): No such file or directory in /var/www/vhosts/autobin.ru/httpdocs/modules/imagefield/imagefield.module on line 461.
# warning: mkdir(/tmp_3lSrv2_dir): Permission denied in /var/www/vhosts/autobin.ru/httpdocs/modules/imagefield/imagefield.module on line 526.
# warning: opendir(/tmp_3lSrv2_dir): failed to open dir: No such file or directory in /var/www/vhosts/autobin.ru/httpdocs/modules/imagefield/imagefield.module on line 535.

Can you help me?
We can do as paid support.

subscribing

After a bit of frustration I got this working... all I have to say is THANK YOU!!!! I had literally thousands of galleries to update to imagefield from a 3rd party gallery program I had been using and you have saved me hundreds of hours of work by coming up with this solution... I'm so happy I could kiss you :)))))

It appears to be running flawlessly for now - I'll post back if I encounter any issues. Many, many, many thanks!!

Subscribed

bumping status. I got one good review so far.

Anyone know of a way so that when a user does upload a Zip file, that the preview could show a Zip icon or something custom?

can it be in core imagefield modul? It would be very usefull.

Can't get this to work. On hosting providers unix system I get error messages too. Seems that the unzipping part is the showstopper for now. Isn't there a PHP extension for unzipping? I'll get into the code when I find the time.

I started a compression API module some time ago, which could use executables and the PHP module if activated. I'll see if I can extract some code to do the unzipping.

The use of this patch is maybe a security risk for your website. So it is possible to upload any file-type (like html, exe, etc.) within the zip-file. I´m not a security expert, so is there anybody out there who can confirm my concern.

The use of this patch is maybe a security risk for your website. So it is possible to upload any file-type (like html, exe, etc.) within the zip-file. I´m not a security expert, so is there anybody out there who can confirm my concern?

@drupalbraxx,
It is a big security risk if the tmp folder is publicly accessible via http, which is why you should never put your tmp folder in a web accessible location.

@dimm,
It would probably be best if imagefield only extracted imagefiles... You also need to skip over OS X Resource forks when working with archived generated on OS X.

+1 to dopry's suggestion. This somehow needs to extract ONLY image files and discard everything else. Huge security risk here - and if nothing else could be very confusing for users uploading zip files made on their macs, or if anyone accidentally includes another file in their zip.

This patch is working perfectly for me and I look forward to its progression. Thanks for all your work on it dimm.

Thanks Dimm! Are you planning to address the issue of extracting non image files? At the moment, we are only allowing administrators to make use of this feature due to the security risk involved as the module extracts all file types included in the archive.

Thanks Dimm! I'll test and report back this weekend.

Hi all,

I have some trouble with this I patched the 5.x-2.1 version of the imagefield module, and created a content type with a title field and an image upload field. With .zip enabled in the allowed file type I am able to upload the file but i will not recognize the image within. Is there a specific way to set this up or do I need to add something else? Is there something I am missing?

I applied your patch and so far everything seems well! I tried creating an image field, checked multiple value and uploaded a single default image. I had typed in a custom directory to be created within the 'files' folder but it made the default images folder instead.

warning: unlink() [function.unlink]: No such file or directory in /sites/all/modules/imagefield/imagefield.module on line 177.

But above this error it said:

The directory files/imagefield_default_images has been created.
Saved field photos.

I'm not sure if this applies to your patch at all and if not I can make another issue for it.

Okay, now I tried uploading a .zip file and the image preview is just a broken image. Then when I clicked save, I got a blank page and this was in my logs:

[25-Jun-2008 22:22:24] PHP Fatal error: Call to undefined function zip_open() in ../sites/all/modules/imagefield/imagefield.module on line 452

I'm using the 5.x-2.1 version. Do I need to clear my cache or something? >.<

Can this be modified so that it can be used for one-node-per-image galleries? What i'm after is a way for users to populate a Views gallery by uploading/creating multiple image-nodes at once. Will this patch do the trick?

John

I just had a quick look at the patch. I think the first thing I will need to do is count the number of files in the zip, and then create that many nodes of the type 'image'. Then i think i would need to loop through these nodes and apply the imagefield data to each one.

Am i right here? I'm not that good with PHP, but if noone else is willing i might give it a go.

John

My host does not allow the install of PHP_ZIP unless I handle all php installations myself. That is one thing I a not prepared to do, because of security. Is there any other way to this or is there a drupal module that does that?

Thanks.

@dimm

thx for this very useful patch.
maybe you can add case insensitivity for the extension. at the moment only .zip will be accepted and not .ZIP and so on.

regards

Is there a version of this patch if you:

1. can't use php_zip
2. don't want to create tmp directories
3. only want to extract image files?

Thanks

#27, #43, #44:
I just created a project http://drupal.org/project/image_import_zip that extends the core image module so you can upload a zip file and use the regular image import.

Subscribing.

also Site5 does not support PHP_ZIP (falling in the Fatal error: Call to undefined function zip_open() too).

The patch at #16 above works sweet also without it though (thank you dimm for pointing out ;)

subscribing

Thanks for the patch, Dimm. I applied the patch to my site. I now find out the image size remains the original size, there is no scaling to the settings I set in the widget. Do I miss something here?

if you have caps in image filename extensions like *.JPG (often produced by digital cameras)
there maybe some error like "cannot extract zip" because of unrecognized mime type. "Extracting of the images failed: xyz_JPG_caps.zip"

You can do this trick. It worked, but have not been tested much, I do not know if this is the right way or if this is a global or just my issue (winXP test system). Here it is:

change in "php_zip patched" imagefield.module:

// Dimm begin ///////////////////////////////////////////////////////////////////////////
function imagefield_mime_content_type($filename)
{
if ( function_exists ( 'mime_content_type ' ) ){
return mime_content_type ($filename);
}else{
$mime = array(
'.JPG' => 'image/jpg', //new
'.GIF' => 'image/gif', //new
'.JPEG' => 'image/jpeg', //new
'.PNG' => 'image/png', //new
'.jpg' => 'image/jpg',
'.jpeg' => 'image/jpeg',
'.gif' => 'image/gif',
'.png' => 'image/png');
return $mime[strrchr($filename, '.')];
}
}

thanks very much for this patch, very usefull. How much difference for a 6.x patch?

Just one remark: should this php_zip code not go into a seperate upload extension module so that all upload enabled modules can use zip files? I see a lot of modules implementing compressed archive functionality all on their own. To me it starts to smell like a very interesting module!

And maybe having a look at the issues with the uploadprogress module would be welcome too so that users can see the progress of large zipfile upload in %!

Dimm, re comment #37 your last patch. I've been using it since since the day you released it. I utilize it about 25 times a day and it has been working flawlessly. Thanks so much. It's made my job MUCH easier.

Are there plans to commit this?

it'd have to go into the 6.x branch and be backported to ensure that there's always an upgrade path.

How does it handle multiple files (images) with different resolution.
If I upload 4 images with different size, the size of the first picture will be used for all pictures.

Where does the module change the size/resolution of the pictures?

How can I adjust the size of the images? So that when a zip is uploaded, all the images get the size I define.

Works perfectly for zip files, provided that extension is lowercase - fails miserably for .ZIP. Also fails to accept tgz files.

I am an illustrator with thousand images that's why I subscribe. And I use d6. Thanks to all.

any patch for d6 version ?

subscribe

I download multiple_upload_v23.zip from this thread
and replace existing imagefield.module with the one in the zip file

The upload a zip with with jpg files, but it imagefield return xxxx.zip is not support

At line 704:
$file = _imagefield_scale_image($file, $field['widget']['max_resolution']);

I believe it says: I have a file and need to scale it. Scale is set in the image field settings. But in the zip are more files. So I need some kind of loop over this function. Can someone help me with this?

I can read some php but I am not a programmer.

edit: added code tags

Also, in:

// Dimm begin ///////////////////////////////////////////////////////////////////////////
    if (strpos($file['filemime'], 'image/'===0)) {
       $file = _imagefield_scale_image($file, $field['widget']['max_resolution']);
    }
// Dimm end ///////////////////////////////////////////////////////////////////////////

The variable $file['filemime'] in my case is 'application/zip'.
That is never gonna work, does it?

subscribe

Subscribe for D6 version...

++ for a D6 version.

I'm currently working on this feature: http://drupal.org/node/319934. As imagefield somehow depends on filefield, I think this might serve here too...

to confusi0n: I think you want imagefield_import module

Strange. I get an error but it uploads.

I get the following error when I apply the patch #16 on Imagefield 5.x.2-1

* warning: Invalid argument supplied for foreach() in /mysite.com/httpdocs/modules/node/node.module on line 561.
* warning: implode() [function.implode]: Invalid arguments passed in /mysite.com/httpdocs/modules/node/node.module on line 565.
* user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 query: SELECT n.nid, n.vid, n.type, n.status, n.created, n.changed, n.comment, n.promote, n.sticky, r.timestamp AS revision_timestamp, r.title, r.body, r.teaser, r.log, r.format, u.uid, u.name, u.picture, u.data FROM node n INNER JOIN users u ON u.uid = n.uid INNER JOIN node_revisions r ON r.vid = n.vid WHERE in /mysite.com/httpdocs/includes/database.mysql.inc on line 172.

@adrianmak
Allow it in imagefield settings under your content type field settings

@Dimm
Thank you, you made my day!

If somebody is having problem with preview while uploading regular images, this patch http://drupal.org/node/230848#comment-842386 worked for me.
(imagefield 2.1)

Dimm : i got some error, the file is not unzipped, how can i get the unzip.exe ? i get some unzip.exe but doesnt support the -d (is it a big problem?), and where should i put it ? im using xampp, and i put it in \php, is it right ? Or should i configure something before ?

Thank you very much.

Ugh, didn't work, hmm, what should i do ?

I have checked all, and i don't find something that different with others or not configured. Any Ideas ?

What is the requirement and prerequisites for this module ?

Thank you very much.

Okay sir, the v23 works well !!

Thank you very much.

Is there a testable version for D6?

I'd kill for a D6 version of this!

Hello,

Trying to use multiple_upload_v23.zip with the "filefield_paths" module version 5.x-1.0. The filefield paths module is unable to tokenize the paths and filenames for images that are extracted from a zip file.

Individually loaded images will still work fine with tokens and filefield paths.

The basic User and site tokens found in the basic tokens modules work fine for images from a zip.
The tokens found in filefield paths are a little odd in that they use nodal data and are therefore set after the node has been created.

Filefield paths should be a perfect partner for this patch as images can be saved in directories like /files/[type]/[nid] ("Node type"/"Node Id")

Any advice on getting them to work?

@#37: zip? .zip? What is this, zip?

First I tried:

tar -vzxf [filename]

and received an error, and then, thinking maybe one of the newfangled tools would do it:

gunzip [filename]

But no. :P

RE: #43 and others: the general approach of this module is somewhat preferable to imagefield_import, in that it exposes the entire node_ad form and allows the node have settings (domain, nodereference, etc) that imagefield_import cannot easily support. Self-todo: eval whether this mod can (easily) be changed to support multiple node creation instead of upload to multiple fields.

subscribing for D6 too
thanks

Personnally, I don't very like the idea to zip or taf files to create multiple upload.

I prefer swfupload, or javascript, or even java solutions to do it. (I know nobody care about my opinion)

^^

@dimm
could you please provide a patch for imagefield 5.x-2.2?
btw i have discovered that the resizing procedure does not work neither for images in a zip nor for single uploaded images.

regards

can someone post the patched files?

zmove - but none of those work with imagefield (yet)

dimm
so you are saying that the latest version of your patch may work on imagefield 2.2?

dimm,

i am already using your patch (http://drupal.org/node/251096#comment-886663) (btw. many thx for that) but the problem is, that the resizing regarding to the max. resolution does not happen. neither for single uploaded images nor for compressed images in a .zip file. but if i use the original imagefield without your patch then the resizing for single uploaded images is fine. so i ask you to provide a new version in which the resizing will work for both.

thanks and regards

martin

thx dimm but the problem with the resizing still exists with your patched version. with the original 5.x-2.2 imagefield release the files will be resized correctly according to the max resolution i set. am i the only one with this problem?

no not imagecache. in the content type settings you can set the options for the imagefield. and there the max resolution is set to 640x480. and as said before with the original imagefield release the resizing works fine.
if i comment line 700 and 702 (
if (strpos($file['filemime'], 'image/'===0)) {) from your 5.x-2.2 patched version then the single uploaded images will be resized correctly.

yes now the single uploaded files will be resized correctly but images uploaded via a .zip file will not be resized.
thx so far

I get the following error:

The file Bilder.zip is not supported.
Only the following file types are supported:
jpg, jpeg,png,gif,zip

What can i do?

this is an imagefield 5.x-2.2 issue. see http://drupal.org/node/352939

yeah i tried patching 2.2 manually and got the same error. testing their patch now.

I am using the D5 patch, and it's a godsend... Only problem,
I would really like to have bulk upload restricted to user 1.
Could someone please provide directions? (I am not into
programming). Thank you.

hi,
any news about not resizing for .zip uploaded images?

Howdy, pointing out another problem (using #37 above):

mac uploads load on the server also hidden aliases of image files like ._image.jpg, creating same number of broken/non-exhistant images

Also see http://drupal.org/project/jifupload, jUpload for Imagefield. It's 6.x Dev and could use some testing.

unfortunately they are still 6.x only, but thanks for pointing them out ;)

the patch has been tested and reviewed by many, but some work is still needed to make it work well on 5.x. Setting as CNW then.

Ref. #109: "I would really like to have bulk upload restricted to user 1"

That should be "restricted to role(s)".

Then you just make sure the user(s) you want to have this functionality are actually member of a role with this permission.

Will it be committed to imagefield?

Freak!! My host doesn't support php_zip. This is frustrating. Is there a work-around? I can't wait to see this in action.

Okay, I got a little more detail from my host.

php_zip.dll will not work on your plan. .dll files are for windows servers only. Your plan is currently being hosted on a unix platform. If you can find the appropriate unix extensions for that module you should be able to install it directly in your FTP root and then update your php.ini to look for those extensions where ever you installed them.

Now I'm stuck. I have no idea where to find these or how to reference it in my php.ini. I've googled myself blue, but to no avail. HELP!!

reverting title back to the original

Oops, I think that was me. Sorry. ;( Feel like such a moron right now.

howdy, attaching an improved version of the patch based on Imagefield 2.1 (#37 above) that also checks for "._" Mac Os files (see #111), and attaching full module too.

PS: is there any plan to commit this functionality on next releases?

This functionality will not be added to the Drupal 5 version, which is now maintenance only. This patch needs to be revised regardless:

- Follow code standards
- Update to work with FileField (since it would handle this in Drupal 6)
- Remove all the "Dimm start" comments, we know where it starts already when the changes are in patch form
- Make an option to support automatic unzipping when configuring the CCK field (since if this is a FileField, you might not want it to unzip)
- Check that php_zip exists before trying to unzip or providing options relating to zipping

Regardless, this is still a good starting point to adding this functionality in the future, if that need isn't filled entirely by add-on modules like http://drupal.org/project/imagefield_zip, http://drupal.org/project/jifupload, and http://drupal.org/project/image_fupload

I think it would be interesting for filefield, as for other filetypes a compressed upload would be interesting not only to add multiple items at once but primarily in terms of upload duration. Although if you start it, people would probably also want tar.gz, which is for example the compression I always use. Other people might prefer rar. For JPEGs people might want to save the compression time, because it doesn't give any advantage and thus might use only tar. People without the php-zip extension might want it to call exec('unzip') or other executables directly. Many options...

I've got an initial dev release up of a Drupal 5 backport of http://drupal.org/project/jifupload, assuming I didn't screw up cvs... Should be packaged up tonight.

Moving this to the FileField queue, which would need to handle this support in Drupal 6 (ImageField and other modules then get it by association).

Marked #319934: compressed and/or archived file support duplicate.

Dimm, I'm not adding any new features to the Drupal 5 version. It'll have to be a separate module for Drupal 5.

switching back to filefield so this has a chance of getting implemented...

There is a imagefield zip module released.

@Flying Drupalist True, but I was hoping that since #417122: Allow drupal_alter() on Field and Widget Settings has now been committed, we there might be a cleaner way to implement this.

Maybe this issue should be bumped over to that queue though?

This might work better as a widget ontop of FileField. See ImageField Zip for the zip extraction support or Image Fupload for SWFUpload support.

This will not be added. FileField is essentially discontinued since it has been integrated into Drupal core. I'd suggest an add-on module (as already suggested a few times above).