Tagging Image Nodes Removes Image From Gallery

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 $

Traced to the bottom of the community_tags_taxonomy_node_save function.

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.

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.

Yes indeed... it should prevent this problem, no matter which vocabulary your VID 1 happens to be.

Please use a test system of course!

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.

Seems fine for me.

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

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

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.

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?

subscribe

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

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?

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.

subscribing

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?

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

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

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

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.

Fixed by entrigan - community_tags.module version 1.37.2.7.