Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

All other Modules /

Discuss all other Modules here.

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Image Gallery issue: Replacing pictures in albums


Go to End
Reply


15 Posts   3034 Views

Avatar
TWoSH

Community Member, 13 Posts

7 August 2009 at 7:23pm

Edited: 07/08/2009 7:23pm

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

Avatar
creatormarius

Community Member, 11 Posts

19 May 2010 at 6:55pm

Edited: 19/05/2010 6:56pm

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

Avatar
TWoSH

Community Member, 13 Posts

19 May 2010 at 10:42pm

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...

Avatar
UncleCheese

Forum Moderator, 4094 Posts

20 May 2010 at 4:38am

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.

Avatar
creatormarius

Community Member, 11 Posts

20 May 2010 at 6:53pm

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.

Avatar
UncleCheese

Forum Moderator, 4094 Posts

21 May 2010 at 1:40am

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.

Avatar
creatormarius

Community Member, 11 Posts

21 May 2010 at 9:21pm

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.

Avatar
creatormarius

Community Member, 11 Posts

23 May 2010 at 5:40pm

Edited: 01/06/2010 6:49pm

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.

Go to Top