Using image.module cvs revision 1.197 and image_pub revision 1.2.2.2 - both the latest for 4.7 - I can upload images to my server, but they are not properly associated with the gallery where I expected them to go.

Steps to repeat:
1. login using gallery remote
2. create a new gallery
3. add images to this gallery
4. upload pictures

Expected result:
Images are loaded and placed into the new gallery

Actual result:
Images are loaded, but are not placed into any gallery

Repeatable: always

Workaround: if I create the gallery and then log out of the site, or close Gallery Remote (after step 2) and then re-log in to the site, and _then_ upload the images it will work fine.

If this is a gallery remote bug then my apologies for lodging it here.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Steve Dondley’s picture

FileSize
8.44 KB

Here's a patch that should fix it. The code was badly out of date and had to be fixed in a few places. Basically, the code's conversion to 4.7 wasn't quite complete.

I tested it a couple of times and it seems to work. I'll post another patch if I find problems or someone reports them.

ph0rse’s picture

After applying this patch the galleries being displayed in Gallery Remote was incorrect and incomplete after a few hours. The tree looked something like this:

-(image)
----My Main Photogallery

This was all it displayed, even though I have many galleries. The above (image) text appeared literally. After replacing the patched module with the stable one, everything returned to normal.

Let me know if I can provide you with any information that you may need.

ph0rse’s picture

I think I have traced the problem of the gallery association errors. It seems to occur when you create a new album using Gallery Remote and attempt to upload images to that newly created album. All pictures from this point will be uploaded with no association to galleries.

A workaround for this is to log out of Gallery Remote once you have created any new albums, before uploading any more images, and then log back in.

greggles’s picture

@steve dondley - when I applied this patch my Gallery Remote would no longer login to the site. I undid the patch and Gallery Remote logs in again.

When I hit "login" I get the message in the status bar: "Fetching albums from example.com/directory/" with the back and forth status indicator. After a little while I get the message "Error: Server contacted, but Gallery not found at this URL (http://example.com/directory/gallery_remote2.php)" Interestingly, the Log In button changes to Log Out after the error message.

If I visit http://example.com/directory/gallery_remote2.php I see the message "For more information about Gallery Remote, see Gallery's website located at http://gallery.sourceforge.net"

Thanks for your help with this and sorry it took me so long to test. I'm still using the stable 1.5 version of Gallery Remote (as opposed to the betas).

@pH0rse - are you sure you applied the patch correctly? The behavior you describe is exactly as I described.

ph0rse’s picture

It doesn't sound like our behaviors are the same as I don't get any error messages and galleries seem to appear in GR for me, albeit incorrect ones. Ultimately the patch is flawed though and will need revision.

Another note to my workaround: When creating nested albums, you will also need to log out and log back in after creating the parent album and before creating child albums.

Caerbannog’s picture

I am having this same issue. What I have noticed is that when you create a galllery with Gallery Remote (I am using 1.5) the gallery title is given as what ever you entered. But after you log out and back in again the gallery name is something like Album* where * is a sequencial number for each album edited. I made the assumption that after the Gallery Remote client makes the gallery it doesn't check to see what the gallery is actually called it assumes it is called what is asked for, but that the drupal gallery is always called Album*. After you log back in that real name is read from the drupal and all is well. I haven't checked this with the more current versions of Gallery Remote as the log in/out fix works ok for me.

vadim.bich’s picture

FileSize
4.54 KB

As per protocol, Gallery may change id, so it is partially Gallery Remote's fault for not checking new ids returned by the protocol. I added a simple patch for keeping old id (used by GR) -> new id (used by image_pub) mapping inside the session. GR's id gets added on new album creation, and gets used everywhere else, if found.

It worked for me, hopefully will help others.

PS. this is patch for 5.x-1.x-dev

vadim.bich’s picture

Version: 4.7.x-1.x-dev » 5.x-1.x-dev
Status: Active » Needs review
enboig’s picture

I would like to know if the patch above works or if it has been corrected.

thanks

Steve Dondley’s picture

It worked for me on Drupal 6. My guess is it will work on d5 as well.

egfrith’s picture

I've just taken over maintaining this module. Please bear with me while I get up to speed on maintaining drupal modules, but I hope to be looking at this patch soon.

egfrith’s picture

This patch fixes the problem for me.

However, I think it would be desirable to rework it to make it a bit neater by having just one occurrence of:

 if (array_key_exists($_SESSION['image_pub_gr_albumname_map'],$albname)){
    $albname=_image_pub_gr_get_albumname($_SESSION['image_pub_gr_albumname_map'][$albname]);
  }

perhaps in _image_pub_gr_request(), or perhaps in a helper function, that would return $albname or $_POST['set_albumName'] if this is not set.

Please let me know if you'd like to do this; otherwise I will get onto it sometime soonish - hopefully this week.

egfrith’s picture

FileSize
790 bytes

I've had another look at this. According to the spec
(http://codex.gallery2.org/Gallery_Remote:Protocol#new-album)
the server should return the "album_name" of the newly-created album. The code was returning "album.name" (with a dot, not an underscore). The attached patch fixes the issue for me with the latest version of the gallery remote program.

Please test this and let me know if it works for you. If I don't hear anything after a few days, I will apply the patch anyway.

egfrith’s picture

Status: Needs review » Fixed

I've not heard anything, so I've applied the most recent patch and marking the issue as fixed. Please let me know if this doesn't fix the issue for you.

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.