Hierarchical albums shown as flat structure
bwynants - December 18, 2007 - 12:59
| Project: | Image Publishing |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Description
Using Aperture and the ApertureToGallery plugin all albums as one big list and it does not reflect the taxonomy hierarchy. This is due to an error in the code at the moment the parent name is looked up.
With the enclosed patch the albums are browsable by hierarchy ....
Verified with 'Gallery Remote' as well
| Attachment | Size |
|---|---|
| patch.patch | 722 bytes |
#1
I've just taken over maintaining this module. It looks as though this patch has been applied in the 5.x tree, though I can't see from the CVS messages when this happend.
Could you confirm that the problem has been fixed?
#2
Can't see it in yet? I checked version image_pub.module,v 1.11.2.6 2008/09/24
#3
You're right: the patch has not been applied. I don't know what I was thinking.
However, I'm not convinced that it's correct for two reasons.
Firstly, when using GalleryRemote 1.5.1b41, without applying the patch, I find that I am able to
1. Create an album
2. Create a subalbum of that album
3. Create a subalbum of the subalbum
4. Close Gallery Remote
5. Reopen Gallery Remote and login to my site
6. See the hierarchical structure I created in steps 1-3.
So I'm not able to reproduce the bug with the (almost) latest version of GR.
Secondly, the according to the Gallery remote protocol http://codex.gallery2.org/Gallery_Remote:Protocol#fetch-albums-prune, part of the response to fetch-albums-prune is:
album.parent.ref-num=parent-ref-numwhere
In the code "pname" is currently set to pterm->id, giving an numeric id. The patch would return the album-url-name, which is not what the documentation says *should* happen (though it is what some clients do expect).
So it looks as though as though the present code is correct according to the protocol, but that the patch you proposed is also correct for fixing problems with older versions of gallery remote... since the new version of GR I've tried seems to work without the patch being applied. That said, I've not been able to find out for sure whether GR now conforms to the documentation for the GR protocol.
Hmmm.... I'd be minded to keep the code to the published protocol as possible, and say that any client app that doesn't obey the protocol needs to be fixed - but perhaps I'm missing something?
#4
agreed with what the spec says, but there is something wrong in case $refnum is set in that function (fetch-albums call).....
in that case $pname is used as lookup in $aidref which is being populated just above with calls to _image_pub_gr_get_albumname hence for lookup you should call _image_pub_gr_get_albumname also....
in the other case $refnum not set (Gallery Remote) the pname created on the patch line is not used and another call to _image_pub_gr_get_albumname is done in the else case
anyway I have updated the patch to reflect this...
please investigate how Gallery Remote calls you (with or without $refnum set) and check the output created....
here is my output when the patch is not applied, notice parent being empty
[02-Oct-2008 21:02:40] album.name.89=Album34[02-Oct-2008 21:02:40] album.title.89=Tessel Cup 2003
[02-Oct-2008 21:02:40] album.summary.89=
[02-Oct-2008 21:02:40] album.parent.89=
[02-Oct-2008 21:02:40] album.resize_size.89=550
[02-Oct-2008 21:02:40] album.max_size.89=0
here is my output when the patch is applied, notice parent being filled in
[02-Oct-2008 21:02:15] album.name.89=Album34[02-Oct-2008 21:02:15] album.title.89=Tessel Cup 2003
[02-Oct-2008 21:02:15] album.summary.89=
[02-Oct-2008 21:02:15] album.parent.89=62
[02-Oct-2008 21:02:15] album.resize_size.89=550
[02-Oct-2008 21:02:15] album.max_size.89=0
As stated above I use ApertureToGallery plugin...
#5
In short, thanks for the new patch bwynants; I've applied it now.
The long version: I have looked at the output from GalleryRemote. It seems that it was always using fetch-albums-prune for me, and therefore receiving the album_name from drupal. GalleryRemote still does not seem to be obeying the protocol strictly when fetch-albums-prune is used, and the problem did not therefore occur for me. However, I can see that if a client had asked to fetch-albums, then the problem would have arisen.
Although I don't know how all other clients interpret the protocol, I don't think we should change the code to obey the protocol strictly yet (see comment #3). I tried setting numref TRUE for fetch-albums-prune with GalleryRemote and it didn't work.
#6
Automatically closed -- issue fixed for two weeks with no activity.