Hi guys & gals

We are having some issues with Uncle Cheeses otherwise excellent image_gallery. We are using the latest builds;
SS 2.3.3 and the recent download of all the modules:
modules-dataobject_manager-r220.tar.gz
modules-swfupload-r216.tar.gz
modules-image_gallery-r210.tar.gz

The issues described below is the same on Linux and Windows platforms.

Initial image uploads work fine. The images are stored in the correct folder (i.e. assets/image-gallery/Gallery/Default-Album/...) The problems appear when I try to replace an image. If I for example choose the file "foo.jpg" and press "Replace Image" and "Save" the file is uploaded to assets/Uploads/foo.jpg and in the database table File the new image's Filename field is set to assets/Uploads/foo.jpg.

Question; why does it upload to assets/upload and not to the current image-gallery/gallery/album folder? Is this on purpose or a bug? Seems a bit illogical to me...

Still, everything is working so far. If I then press "Save and Publish" on the image gallery page the database is updated; the Filename field is set to assets/image-gallery/Gallery/Default-Album/foo.jpg, which is the wrong path since the file is still in assets/Uploads. Now the replaced image is neither shown in the CMS nor on the published site.

The problem can still be "worsened" by switching to the "Files & Images" tab. A replaced image with the following fields in the File table: ID=35, ClassName=ImageGalleryImage, Filename=assets/image-gallery/Gallery/Default-Album/foo.jpg is updated to the following when switching to "Files & Images": ID=36, ClassName=Image, Filename=assets/Uploads/foo.jpg, i.e. the Filename is reverted back to the correct path but the ID and ClassName fields are changed to bad values.

Another smaller problem is that the lightbox images (loading, close, left, right) are not found. This can be fixed by changing the "image lines" in image_gallery/javascript/lightbox/jquery.lightbox-0.5.js; e.g. "/image_gallery/images/lightbox/lightbox-ico-loading.gif" should be "image_gallery/images/lightbox/lightbox-ico-loading.gif" without the leading "/".

Hope UC or someone else could shed some light on these issues!

Best regards,
Tim

Some problem here. Have you had any success patching this?

The good news; yeah, we did solve this.

The bad news; we have no idea anymore what we did... Really sorry - should have posted the solution when we got it working. Bah...

Replacing an image brings the limitations of the ImageField, which doesn't grant you control over where the file is saved. Because DOM uses a different file uploading tool (SWFUpload) you can specify where you want the file saved. Last I checked, you could not provide an upload path to a FileIFrame field.

I'd be happy to ditch ImageField and FileIFrame for SWFUpload if that solves it. How do I do that?
I already have both DOM and SWFUpload modules installed.

SWFUploadIFrameField doesn't work too well. Never has.

As it turns out, the folder name is the fifth argument for a FileField, so it looks like we do have control over it. I'll look into adding that in.

I think I have part of the problem:
You're right we "should" have control over it, but Image::save (which is called on saving/replacing) writes the file with $image->loadUploaded(data) which is a deprecated function and does not provide for specifying the folder name.

File::loadUploaded()
is preceded by the following comment:
"DEPRECATED Please instanciate an Upload-object instead and pass the file via {Upload->loadIntoFile()}."

...and loadIntoFile indeed takes a destination folder as a parameter!

So the solution might be to extend Image and replace the save method with one that passes on the path using the Upload->loadintoFile method.

I need to sort this so if you're game we can work on this together. Obviously you're a bit ahead of me in the SS game, but I'll do my bit with a bit of guidance.

UPDATE:

Turns out that it's not Image that needs extending but the controller... : Image_Uploader.

So... this takes me out of my depth at the moment, but it has been done with swfuploadfile and involved creating new director rule to handle such images, amongst other things...

Alternatively Image_uploader->save can be hacked as follows:
Add after : if( !$imageClass) $imageClass = 'Image';

if ($owner->class == 'ImageGalleryItem') {
$image = new $imageClass();
$album = DataObject::get_by_id("ImageGalleryAlbum", $this->linkedObj->AlbumID);
$folder = DataObject::get_by_id("File", $album->FolderID);
$path = substr(str_replace('assets/','',$folder->Filename), 0, -1) ;
$u = new Upload();
$u->loadIntoFile($data['Upload'],$image,$path);
$owner->$fieldName = $u->file->ID;
// store the owner id with the uploaded image
$member = Member::currentUser();
$image->OwnerID = $member->ID;
$image->write();
} else {
...normal save code..

This is a hack to make image objects within galleryitems to be replaced and placed inside the relevant Album's folder...

I'm still working on this, but thought I'd post it up for anyone else trying to solve this problem to add to the mix.

UC, if you can spare the time, you could probably implement the suggested and better implementation, of extending Image_Uploader, in short time and this would be preferable solution rather than hacking core.