Tagging Image Nodes Removes Image From Gallery
Helmut Debes - July 15, 2007 - 11:46
| Project: | Community Tags |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | needs work |
Description
When tagging images belonging to an image gallery, the image then is no longer part of the image gallery anymore. (When tagging other content, things seem to be normal.)
#1
I think this is critical, as it would after a while disintegrate a the web site.
#2
Subscribing. I can confirm this does indeed remove the image gallery tags. Version I tried was:
; $Id: community_tags.info,v 1.1 2007/04/11 12:31:32 unconed Exp $#3
Traced to the bottom of the
community_tags_taxonomy_node_savefunction.The current code assumes PHP treats $array in the same way Perl treats @array (ie, passes all members of the array as separate arguments). Can't say I've seen this before in PHP.
Upshot of this is that this part of the code always thinks that the free tagging vocabulary ID to use is '1'. VID '1' on our system happens to be images... it's pretty standard install so probably is elsewhere too.
Anyhow, the enclosed patch works here, but is hardly elegant. YMMV.
#4
Please correct me, but it seems to me that image galleries do rely on taxonomy to work and community tags has problems playing nice with other vocabularies - see http://drupal.org/node/137421
I think it would be good to have a solution that addresses both problems as they actually seem to be the same problem.
#5
True, the problem I supplied a fix to would not be limited to galleries. It will affect whatever is vocabulary number 1 in your system, which happens to be the galleries for us.
#6
OK, so just to make sure - your patch should fix the problem with all vocabularies, not just image galleries, right? In that case I will happily test the patch on my system, elegant or not! :-)
#7
Yes indeed... it should prevent this problem, no matter which vocabulary your VID 1 happens to be.
Please use a test system of course!
#8
Well, I have installed it on my test system and all worked fine and now it is also running on the live system and still fine - seems you have fixed it. This should really be ported into the module! Can we change this to "ready to be committed" or does it need more testing?
#9
That's not a safe way of working around the problem.
Instead of doing that, you can make use of the "all args in one array" syntax of db_query, like so.
#10
Seems fine for me.
#11
#9 gives:
root@host community_tags]# patch < *.patch(Stripping trailing CRs from patch.)
patching file community_tags.module
Hunk #1 succeeded at 582 (offset 35 lines).
#12
# 3 gives:
[root@host community_tags]# patch < *.patch(Stripping trailing CRs from patch.)
patching file community_tags.module
Hunk #1 succeeded at 581 with fuzz 1 (offset 40 lines).
#13
patches are not applicable against versions released on February 19, 2008 - 04:02, however the problem persists. and this is so critical that it prevents using this module, since it makes impossible using other taxonomies.
#14
I'm sorry... but I found this bug over a year ago so it doesn't surprise me the patch is now out of date.
However, the cause is outlined here so a newer fix should be incredibly simple to implement.
Who is maintaining this code now? Do you want a patch rolled against CVS or something?
#15
subscribe
#16
i had to install earlier versions of the module to apply the patch and now am using it with no problem. so i will not be updating the working version for a while, but really would want the future releases of the module to have this kind of critical problems already solved. thanks
#17
I've just installed 5.x-1.0-beta1 and this problem persists.
I can see the more secure reasoning behind patch #9 above so have rolled the enclosed against 5.x-1.0-beta1.
Nothing much has changed with the patch aside from the line numbers, can we please have this rolled into CVS?
#18
thanks for the patch! applied is working i see no issues so far, i'll update ticket if i find any
this REALLY needs to be fixed in production this introduced big problems.
#19
subscribing
#20
#21
Why has the status of this gone back to 'patch needs review'?
Can someone please verify the latest patch so we can get this one rolled in?
#22
The patch does rectify the error of removing the other vocab terms. My vocab 1 was called as "NotaCommunityVocab" (FreeTagging) and vocab 2 called "CommunityVocab". Before patch, adding terms to "CommunityVocab" removed the "NotaCommunityVocab" terms. After patch this is not the case. But slightly changing the vocab order .i.e., 1 => CommunityVocab and 2 => NotaCommunityVocab,
Whatever terms that I enter in NotaCommunityVocab get adds to CommunityVocab. Not sure, if this has to be treated as a separate bug or the part of this one. So changing the status to "code needs work". Please do verify my claims and confirm.
Thank you all,
Tosho
#23
I have incorporated this patch (as it currently exists) into the port for Drupal 6 that I created (#236751: Community tags port to 6.x). I'll keep an eye on this thread to see if people think the vocab order change should be a separate bug (or if someone would like to submit a patch for it).
Thanks,
Nathan
#24
@nburles: I think we should continue with this issue in this thread and leave #236751: Community tags port to 6.x for issues related to the porting to 6.x compatibility.
Note that this issue is related with the 5.x branch, which must continue active and maintained.
#25
Re: #23 Sorry to say that this bug persists in the 6.x version (both dev and beta).
Applying the patch I originally posted in #3 fixes this.