adopt pre-existing tags into ccktssu

The terms are not updated! So it is a bug.
All terms I already had in place are deselected when submitting the node.
Please assist.

Thanks in advance,

Greetings,
Martijn

First off, any existing terms you have for nodes will not work with this module as they are stored in different tables! This is a CCK field module, so its values are stored in the CCK field table that is created when you add this to a content type. It is dynamically created every time you add a CCK field of this kind to another content type. That's just how CCK works and I can't change that.

With that said, there is an option inside this module to allow both CCK behavior and regular tag behavior. However, enabling tag behavior will not import any values formerly associated with the node because it also needs to be associated with the CCK field table.

So bottom line is, that you will have to write your own import script if you want to have old terms associated with this CCK field. That is not a generic thing that would be simple to include in this module, which is why I didn't write one.

As for your comment #1, I assume that you were simply confirming your assertions in your original post and were not making a separate comment. Is that correct? Did I answer your questions?

Hi, yes both remarks should be read as one, but when you are the first in a thread of an issue, I can't alter my issue anymore.

Ok, so the problem is that the term -> to -> tag conversion is only from this module to term_node and not by submitting taking the old terms also in consideration, right?
Is that not possible to alter in this module please?

Than not only the selected terms from cck_taxonomy_ssu are converted to tags, but also the already available tags from this node because of earlier usage in the node_term table.
I think I am not the only one who wants to use this great module, because of freetaggging possibility next to selection the terms from a list! so please consider my option when you select

To also get the already available terms from the node on which you are working.
It would be great to have this working!

Thanks in advance for your reply,

greetings,
Martijn

Well, I'll consider such a feature in the future, but I certainly won't be getting to it any time soon. I have too much on my schedule right now. The only way to get this in sooner is if I were paid to make the modification. Otherwise it could be 3-6 months before I get to something like this. Obviously, such a feature would only work if you used the same vocabulary as before and only if you setup a CCK field using this module before removing the vocab from the node type. This would be a massively resource hungry operation and depending on the size of your site, could time out because it would go through every node in your site!

I assume that you don't know how to program and aren't willing to learn since you made no comment about my suggestion to write your own import script. So if that's the case, you'll have to wait until I can get around to considering this. Sorry, but that's the best I can do. I've got bills to pay and other commitments right now.

Hi,

I know some programming, but it is not the willing. It is the thing that I don't think it is nice to have two tables filled with all my taxonomy terms and the change they will be imbalanced by using two modules which fill their own database. Sorry If my words mislead you. I have programmed in Pascal years ago and will look into a solution.
Thanks a lot for considering this option though, whether it is a couple of months away.
Happy Hollidays and again sorry if I misled you in my words, but I just don't think it is the right solution to have two tables with the same information in it in my database.

Greetings,
Martijn

The problem is this:

When a content type has a vocabulary associated with it, your users are allowed to 'tag' the content that is created. These tags are stored in a certain table.

CCK uses its own tables to store data. This module was created to take advantage of this and for a specific use case where tags were not desired. However, due to user feature requests, the ability to show terms as 'normal' tags was added. Due to CCK constraints, both tables must maintain the same data. This module does that just fine for new terms added to nodes, but there is no mechanism to import existing tags into this module's CCK tables. However, if such an import were done, it would only need doing once and then everything would match up fine using only this module.

The order of operations to get this to work would have to be something like:
-Install this module
-Setup your existing content type to use this module, making sure to activate 'tags'
-Click an 'import tags' button
-Deactivate the vocabulary from the content type since it is now redundant
-Use CCKTSSU as normal

So if I add this feature, that will be what you'll have to do. I will think about this once I take care of existing bugs.

I'm thinking out loud here...

I think that a single button to import existing terms may be too expensive/time out. From a programming point of view, it would be easier to check for existing terms when a node is edited. But from a user point of view, that sucks because an admin would have to wait until all nodes had been edited before disabling the old vocab selector. That, or the admin would have to manually edit every page himself. Not good.

So what about cron? Let the admin set how many nodes to check each cron? The admin would need to know when the terms are all copied over so he could disable the vocab on that content type. And how do we prevent users from adding more terms to nodes we already worked on while we're waiting for all conversions to take place?

Also, how do we identify which nodes need work, and what CCK table the data needs to be copied to? Also, dealing with multiple vocabs and multiple CCKTSSU fields on a single node will be difficult. Should I just try the case where only one vocab is being substituted with a CCKTSSU field?

Too many questions exist right now to get this feature into the next release I think. If anyone has solid ideas, let me know. Perhaps this should be done as a sub-module of this project; something like ccktssu_tag_import.module or something...

Good ideas here, thank you for thinking loud!! So, about #7:

Surely, waiting "until all nodes had been edited [one by one] before disabling the old vocab selector" is just not enough considering big sites (2nd feat.).

Then, considering that the cron (3rd) feature -although quite necessary- leaves the issue of preventing "users from adding more terms to nodes we already worked on while we're waiting for all conversions", the (1st) feature "a single button to import existing terms" maybe very useful sometimes, such as when you cannot really put your site offline.

About the cron feature, I think that:

- the more frequently the cron runs
and
- the less node edit operations there are (depending on the number of editors/the average frequence nodes need to be edited)

=> the smaller is the "waiting for conversion" side-effect (and therefore the most efficient)

But the relation between the cron-run and the node edit operation frequencies might not (and maybe for some reason *cannot*) always be considered from this particular "update ccktssu tables" point of view (which what's more might evolve noticeably in a site's lifetime), and therefore might not always be the most efficient feature.

This is thinking loud as well, so this idea might just be considered as a starting point for documentation, for example, in order to advise admins on how to set their cron efficiently, etc.

Regards, Arsène

PS: I've red the whole thread. I don't intend to hurry things up. Just contributing :), although I can't code unfortunately. :(

For info to the future coder of this feature: A possible issue to appear in #6 steps:

- because of: "redundancy of the vocabulary from the content type"

- when: "Click[ing] an 'import tags' button"
- while previously done: "Setup your existing content type to use this module, making sure to activate 'tags'"

You'll probably get a #235907: "Duplicate entry" error when same vocabulary & ccktssu field are enabled (token related). (Relation to tokens won't apply here.)