Free tagging problems: Container configuration issue
dkruglyak - April 15, 2006 - 02:03
| Project: | Tagadelic |
| Version: | 4.7.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
Jump to:
Description
Sequence that caused problems:
1) Got the latest category module and enabled taxonomy wrapper.
2) Created a container with "free tagging" option checked on
3) Opened container for editing and saw "free tagging" option unchecked (ignoring)
4) Created a node, entered several tags and saved
5) Tags showed up correctly on node view
6) Opened the node for editing and hit 'save'
7) All tags got duplicated, when looking at container TOC
8) Database shows term_node table assign new tagged node to tid=0, only
The problem of tag duplication was not present in a version from a few weeks ago (sorry cannot say which one exactly)...

#1
Sorry, but I can't reproduce this problem. The issues that you're describing did once exist in the category module (and the taxonomy wrapper), but were basically fixed when http://drupal.org/node/43162 was resolved.
Please ensure that you are using the latest version of category (HEAD or 4.7 - they're exactly the same at the moment), and see if you still get these problems.
#2
I moved to RC3 with latest HEAD module and tag duplication problem went away.
However, when I open a container in edit mode, the free-tagging checkbox always loads as "off". If I check it and save, free tagging works fine, but if I accidentially save without doing it category reverts to selection, not free tag form.
This may be a minor problem, but a very annoying one.
#3
Can't reproduce this problem, either with creating new containers, or editing existing ones. The 'free tagging' checkbox is always populated with the right value for me. Please re-open this issue if necessary.
#4
I think I found the cause. The same form variable ('tags') is used to both indicate whether a container should support free tagging AND to store its tags as a node.
When looking at the offending container's "object" tab (provided by devel module) I get these settings (excerpt):
has_relations: 0
has_synonyms: 0
hierarchy: 0
multiple: 1
required: 0
tags: NULL
However when I look at a tagged content node, 'tags' shows the actual tags array. So, unlike taxonomy term, category / container should not use the same var 'tags' to indicate if it supports free-tagging.
I do not however know why you do not get the same problem. Perhaps there is something unpredictable over how 'tags' var is overriden.
#5
I had a look at the object structure for some free-tagging categories, containers, and tagged nodes on my test site, but wasn't able to see the problem that you're getting at. The category module only uses the 'tags' property in a node object for one purpose: as a flag to indicate if free tagging is enabled or disabled for that category / container. The actual categories that are 'tagged' to a node are stored in the 'category' array, the same way as non-free-tagging categories are stored. On the node form, free-tagging categories get passed in through
$node->category['tags'], and NOT through$node->tags.#6
I looked into this and found that the tags entered into $node->category['tags'] also get copied into $node->tags. I am trying to track down where this might be happening.
Did you try this with taxonomy wrapper enabled? That is my setup and I do not see category['tags'] used anywhere in taxonomy.module (wrapper).
Maybe that is where tag variables get mixed up?
#7
OK, I got the problem pinned down as the fault of Tagadelic.
tagadelic_nodeapi loads tags into a wrong place, overwriting container's freetagging flag. Then it proceeds to use 'tags' as an array in tagadelic_tags_lists. There are also suspect uses of 'tags' variable in tagadelic_node_get_terms and tagadelic_block.
Questions:
1) Does tagadelic really need a nodeapi to load tags or can it rely on 4.7 core? Doubt it.
2) Whether or not nodeapi is used, where does tagadelic get the tags from for the functions mentioned above?
3) Is there a special handling required for category module or taxonomy wrapper should do the job?
#8
Yes. Tagadelic wants to load these. For two reasons:
1) untill a few weeks ago, Drupal core did not lead any taxonomy info with a node. So its historical.
2) After that core thing was committed, core "got it all wrong" IMO. I think taxonomy should be loaded PER VOCAB. Core makes no difference!
So either make a patch to make tagadelic work with the cr*p that core poops into the node object, or make a patch to load the stuff into the node object in an even better way (ahum) then tagadelic already does.
#9
I would rather not (yet) get into an argument over the best way to load taxonomy into a node and come up with a quick fix instead.
How about renaming 'tags' var into 'tagadelic'? The question is where do I need to make this change besides nodeapi and tagadelic_tags_lists?
Want to be sure not to break things.
#10
Here is what we should do, imo:
Introduce an API function (tagadelic_node_get_tags($nid)) that gets an array with vocabularies (each voc contains an array of terms) for a node-id. You will want to cache this with a static var.
REmove the nodeapi part
Add the call to that tagadelic_node_get_tags($nid) function everywhere where we now just grab the tags from the $node object.
#11
Throttling down, not critical, apparently (else there would have been a patch by now)
#12
Hello,
I've a couple of sites needing this feature. And I see tagadelic working with free tagging containers as the most important use case.
Is this working for D5 and not being back-ported to 4.7? I've tried in D5 a couple of weeks ago and it wasn't working...
This is a showstopper for me, is there any work-around or patch?
Thanks very much in advance for any information.
#13
Marking this as a feature request.
It is not really a bug if a module does not work with another contributed module. Moved to here: http://www.fevote.com/tagadelic/Add_Categories_support
#14
Closing old feature and support-requests. If they are not answered or picked up by now, they probably are not relevant any longer.