Taxonomy association - broken

I tryed diferent configurations for several hours, and the error:

• warning: Illegal offset type in isset or empty in /usr/share/drupal-5.1/modules/taxonomy/taxonomy.module on line 1150.
• warning: Illegal offset type in /usr/share/drupal-5.1/modules/taxonomy/taxonomy.module on line 1151.
• warning: Illegal offset type in /usr/share/drupal-5.1/modules/taxonomy/taxonomy.module on line 1154.

keep going.

What I have:
- Drupal 5.1
- Last versions of content-taxonomy, nodeprofile, usernode, nodefamily and all modules.
What I did:
- Have a taxonomy named State, its a two level taxonomy (hirearchical), Country is level one, and States are on level 2, under each Country.
- I created a CCK content type (userprofile) for nodeprofile use. With usernode and nodefamily last versions too. (the error also reproduces when I try with a CCK content type that is a normal content type, not for nodeprofile use).
- I want one field for users, that is "State", and I wanted it from content-taxonomy field type, so you can see the country of the user and click it and see contents (articles) related to that state. So I added the taxonomy field to that content type (userprofile). I mark as requiered field, and tryed "add as cck", "add as tag" and "both", but the same error occurs.
- Then, when I add new content, for content type userprofile, I select the state correctly, but when I make the "submit form" appears the error:

• warning: Illegal offset type in isset or empty in /usr/share/drupal-5.1/modules/taxonomy/taxonomy.module on line 1150.
• warning: Illegal offset type in /usr/share/drupal-5.1/modules/taxonomy/taxonomy.module on line 1151.
• warning: Illegal offset type in /usr/share/drupal-5.1/modules/taxonomy/taxonomy.module on line 1154.

I see lot of issues on autopath module (for drupal 4.7) that looks like the same error, but I dont use and don't have installed autopath (never used it).

What can I do? is something I make wrong or it's a bug?

Thank you very much. As I see for other issues, drupal has a powerful support team! xd

OK.
After lots of test my conclusion is that the "Save Option: save as tag" doens't work, its a bug.
As I understand, you could assign a tag to a content from a categorie that isn't associed with that kind of content type, throught content-taxonomy field (setting the "Save Options: Save as tag"). But it doesn't work, when you create new content on that content type you get:

• warning: Illegal offset type in isset or empty in /usr/share/drupal-5.1/modules/taxonomy/taxonomy.module on line 1150.
• warning: Illegal offset type in /usr/share/drupal-5.1/modules/taxonomy/taxonomy.module on line 1151.
• warning: Illegal offset type in /usr/share/drupal-5.1/modules/taxonomy/taxonomy.module on line 1154.

So by the moment, I'm going to configure like that:
- Associate categorie with that content type.
- Have a content-taxonomy field with the same categorie, but configured like "Save as cck" only.
- In the creation form for that content type I'm going to see twice the same categorie, one because it's an associated categorie (under categorie configuration for that content type), and the other one because the content-taxonomy field.

Please, I'm correct???
In that case... is this a bug that is going to be corrected soon? I need that, by the moment I adopted this solution, but it's not to much pretty.

Thks!

Lluís

Hi!
I tried to reconstruct your problem, but I didn't have the same problem. I looked up the code at line 1150. The problems occure when the module uses the function taxonomy_get_term. I think I'm using this function correct, so at the moment no idea what the error causes. Which version of PHP are you using?
Concerning the saving options of content taxonomy, this might look a bit confusing for the first time. In general, it doesn't make sense to use content_taxonomy and the original taxonomy fields for the same content type, this won't work. Normally you should only save content_taxonomy fields as real tags and switch off the connection between the categorie and the taxonomy module.

Hi again!

I'm turning crazy with this issue, I think it's a bug, I don't know, I'm new to drupal (but a lot of hours!), but thats my exact situation:

As you told, it doesn't make sense to have both content taxonomy field and taxonomy associated with the same content type, ok, I understand.

So, I reinstalled a complete new: drupal installation, new mysql database, downloaded and installed fresh new modules. The versions:

• OS: Linux Fedora 6
• MySQL 5.0.22
• Drupal 5.1
• Drupal Modules:
  • Content 5.x-1.3
  • Content Taxonomy 5.x-1.x-dev
  • Node Family 5.x-1.x-dev
  • Node Profile 5.x-1.x-dev
  • Usernode 5.x-1.x-dev
  • Automatic Nodetitles 5.x-1.x-dev
  • Token 5.x-1.5
  • Views 5.x-1.5

I'm going to explain what exactly I need and what I'm trying.

I need:
A user profile that suits my needs:
- Name
- City
- State
- others (text fields)

In other hand, I have a category named "States" that I use to clasify storys as an optional field as a normal category for that content type (story). This category is 2 level, first level America and Europe, and second level the states for each one (America: USA, Canda, Mexico, etc... and Europe: Portugal, España,...). This works fine.

For the user profiles, I use usernode to externalize user information in to nodes (one usernode node for each user, as the default working method for usernode module), and nodeprofile to extend the user information as I need (I made a cck content type "fichausuario", and configured as a nodeprofile for usernode with the nodefamily). At this point I think I made standar steps as I read in your documentation.

I'm trying:
Now, I want to use the category (vocabulary) "States", as a cck taxonomy field for "fichausuario" nodeprofile, so then I could select the state for a user from the vocabulary, and when the visitors see the user information they can click in the "State" and go to the contents relative to that State.

For this, I only need to "Save options:" as "Save in cck table", as, by the moment, I don't want userprofiles to show when some visitor retrieves for some term in "States" (checked "Show terms as links" to cover that the visitors can click and go to the contents associated with that term).

I don't have, under categories configuration, the category "State" associated with the userprofile ("fichausuario") neither the usernode.

At that point everything looks correct. The first problem I see is that when I edit a node "fichausuario" (nodeprofile) and I click on "Preview", the label for the taxonomy field doesn't appear in the preview area!!. If I post anyway, and then visit that node, the info shows ok, and the link works. But some problem is there, as when I try to make a view, with the taxonomy field as argument (to view users clasified by State), it doesn't work fine (don't show labels as "Canada, USA, Brasil, etc").

So then I tryed again to "Save as: both", then I could view users by State (then the nodeprofiles must have the taxonomy associated). I configure "Save as: both", go to the edit content page for one nodeprofile, select State, and click on Preview... and... the error I explained in the first post comes up again:

• warning: Illegal offset type in isset or empty in /usr/share/drupal-5.1/modules/taxonomy/taxonomy.module on line 1150.
• warning: Illegal offset type in /usr/share/drupal-5.1/modules/taxonomy/taxonomy.module on line 1151.
• warning: Illegal offset type in /usr/share/drupal-5.1/modules/taxonomy/taxonomy.module on line 1154.

Note that if I click directly on Post, no errors appear, but the taxonomy isn't associated with the node, as when I click on the State field in the own userprofile node, it must appear (I think) the userprofile between the rest of posts associated with that term (state), and it shows the rest of posts (storys) but no the userprofile, so I supose the taxonomy is not being associated with the userprofile, and it doesn't appear with the rest of taxonomyies en the "Published by... in taxonomylist".

Explained all that... or I'm doing something really bad... or there is some problem... I don't know, but I'm really frustrated about that.

Help about modules/taxonomies configuration, or another way to get what I need would be appreciated!

Thank you for your patience!!!

Lluís

sorry, Im using PHP 5.1.6

I just want to know if I'm doing something wrong, or if there is a bug.

Thank you vry much!

Hi!
Thanks for your help!
I think I found the bug and fixed it. Now, your problems should disappear. Please download the latest version from today and try again (maybe you'll have to wait some time until the development snapshots are automatically updated)

mm... the warnings don't appear now... but as I tested, I think the "Save as: both" option or "Save as: tag" don't work, the taxonomy_field looks like never (or I can't make it work) applies the selection as a tag applied to the node!! grrr :)

another interesting thing I miss, is that in the views, there could be a Filter option provided by the module, that let's you filter by the content of a taxonomy_field field (then it makes really independent from the taxonomy, you could select by tag associated, or by appointing to tag in some manner).

The module provides a "sort criteria", but I'm trying it on a taxonomy_field as "Save as: cck only", and it makes no effect on sorting output.

thx!

did you remove the "Content Taxonomy Select" option for this module in the last module version???
i'm turning crazy!

yes, I merged the content_taxonomy_select module and the content_taxononmy_options module, because they both do nearly the same. So you can remove content_taxonomy_select.moulde + .info, content_taxonomy_options now supports selects, radios and checkboxes. If you still have problems with the selects and this code update, you have to re-save the selects in the content admin section or clear the drupal cache.

I think the original problem is in 4.7 as well - I can't seem to get it to save anything in the taxonomy tables (but it is saving it in the node data tables so my chosen option is shown again on edit) but it's writing nothing to the taxonomy tables.

I have the same problem as described above -- linking to a category by means of a Content Taxonomy widget does not actually link the item to the taxonomy.

If you select the option "Save as tag" only, the data gets lost. I suspect that this is why the "Show terms as list box" option doesn't stay checked -- there is simply no connection with the taxonomy data, except for the list of terms to choose from in the first place. Hence, this module is officially broken in my view.

Can anyone get this module working? Is there an older version which did/does work??

The tagging seems to work for me. I am able to create CCK content and use the "save as tag" option. The tags seem to be saved correctly because they do appear in the created nodes and clicking brings up the other nodes with the same tag.

But the input form behaves weirdly. I will post separately on that.

I am using content_taxonomy-5.x-1.x-dev.tar.gz downloaded Apr 3 at 19:36 GMT.

The tagging seems to work for me. I am able to create CCK content and use the "save as tag" option. The tags seem to be saved correctly because they do appear in the created nodes and clicking brings up the other nodes with the same tag.

But the input form behaves weirdly.

I am using content_taxonomy-5.x-1.x-dev.tar.gz downloaded Apr 3 at 19:36 GMT.

The tagging seems to work for me. I am able to create CCK content and use the "save as tag" option. The tags seem to be saved correctly because they do appear in the created nodes and clicking brings up the other nodes with the same tag.

But the input form behaves weirdly.

I am using content_taxonomy-5.x-1.x-dev.tar.gz downloaded Apr 3 at 18:36 GMT.

Sorry about the multiple posting. Must have hiccuped when hitting the button.

Correction - it only works for me if I enter the values I want in the Category box at the top of the input form, and NOT in the actual fields. The values entered in the fields themselves are lost. But maybe entering in the category box can be a workaround if entering info manually. I am going to be entering it programmatically, so this could be a big problem for me soon. :-(

Is there any progress on a fix for this as at the moment this module appears to be unusable.

anxiously looking forward for a fix

IMO this module along with cck should be in core

hi! I'm searching for the error now for some days, but I can't find it, because with my drupal installation all worked fine.
It would be great, if you can tell me, which versions of drupal, taxonomy, cck and content taxonomy you are using and how you use the content_taxonomy (saving options, how many content taxonomy fields per content type,...).
So, thanks for any help and I'll hope we get this working again for everbody!

Hope I can shed some light so that you'll manage to replicate this. I have the latest Content_Taxonomy module installed on Drupal 5.1. Among the modules I use are CCK, Views and also Devel to debug this issue.

I have about 8 fields created using this module, but I might be needing even more.

I'm not familiar with Drupal's $key variable, however I do notice it has some skewed values for the fields created using the Content_Taxonomy module.

Re #22:
I am using:
Drupal 5.1
CCK 5.x-1.4
CT 5.x-1.x

I created a content type with 3 CT fields, using the "save as tag" option for all of them.

I did some digging and debugging in the code and I found that the $node->taxonomy appears to be set correctly in the content_taxonomy.module, but the value is getting lost at some point after that. I posted a question about that here but no answer on it yet.

When I create a new node of this content type or edit an existing one, any values I enter in the CT fields themselves are lost. However, if I enter them in the "categories" box at the top (which is regular taxonomy, not CT) then later (after save) they appear in the fields. There are more problems if the field is marked "required".

Are you using content taxonomy fields and taxonomy fields at the same time within one node type? If so, please try it without the node - vocabulary association in the categories settings.
if there are still problems. you can debug the node->taxonomy array in the taxonomy module in taxonomy_nodeapi. would be interessting what get passed to the taxonomy module.
what problem appear if the field is required?

I just updated the module and changed the saving mechanism. Maybe this helps you. Please try when the snapshot from today is available.

Re: #25:

Tried with and without the node - vocabulary association, same problem. Also, as I notice

I did a var_dump of $node->taxonomy. Below "model" is set through classic free-tagging (without a CT field).

array(6) {
 ["tags"]=>  
 array(3) {
   [6]=>
   string(0) "" 
   [8]=>  
   string(5) "model" 
   [5]=>  
   string(0) "" 
 } 
 [3]=>  string(2) "12" 
 [4]=>  string(1) "0" 
 [2]=>  string(1) "0" 
 [9]=>  string(1) "0" 
 [10]=>  string(1) "0" 
}

Will test the update - thanks.

I downloaded from CVS version 1.2.2.7 of content_taxonomy.module, but as far as I can tell the problem remains. Can anyone else confirm?

which version of taxonomy. module are you using? 1.330.2.2?
have you installed any other modules, which do anything with taxonomy or alters the node array?

mh86, you cannot replicate this issue?

I've attached a list of contrib modules that I use, most of them are latest official releases.

CCK 5x-1.5
Views 5x-1.5

taxonomy.module is v 1.330.2.2 that comes with Drupal 5.1

I tried out many different drupal settings and all my content taxonomy fields worked fine. So it's hard for me to find the bug. I think there is a problem with the $node->taxonomy array, content taxonomy puts all terms into this array, but as you reported, the values don't get passed to the taxonomy.module. there is something between which clears the array, maybe it's the taxonomy module itself which clears the $node->taxonomy before it puts it's own terms into it, but if've checked it.
so, if you have any hints, tell me :)
I'm working on this issue!

Take a look at my attached childish sketch. I could be on a wild goose chase, but this doesn't feel right.

As I mentioned before this is how the devel module shows the key values for CT fields, and these values are different from standard node and taxonomy fields which usually have a unique name such as key=comment or value key=2.

Re #25:
I am not intentionally using both regular taxonomy and CT on the same nodes. What do you mean by node-vocabulary association? Do you mean the nodetype-vocabulary association (i.e. the checkboxes in the edit vocab form to indicate what kinds of nodes the vocab is to be applied to)? Even if I disable (uncheck) the associations, I see the same problem.

Downloaded your update, but still seeing the same problem. $node->taxonomy is definitely getting cleared. This is why I posted the question to the cck guys as noted in #24. Have you checked the value of node->taxonomy when it returns to the caller (_content_field_invoke in content.module)?

It has been quite some time since I worked on this, so I don't remember exactly what was happening when the field was marked as "required". I did post another issue about it at that time.

I'm using the same versions as ahoria reports in #30. It is very weird that it works fine for you. There are comments in the forums from more people reporting it is broken.

Just one more piece of data. I tried printing out $node->taxonomy after it returns to _content_invoke_field and here's what I see:
Array ( [2] => Array ( ) [4] => Array ( ) [tags] => Array ( [3] => ) [1] => Array ( ) )
...
Array ( [1] => Array ( [34] => 34 ) )
Array ( [2] => Array ( [8] => 8 ) ) Array ( [2] => Array ( [8] => 8 ) )
Array ( [2] => Array ( [8] => 8 ) ) Array ( [2] => Array ( [8] => 8 ) )
Array ( [2] => Array ( [8] => 8 ) )

Does not look right to me. Is it? 34 and 8 are the 2 taxonomy tids that match the CT field entries I tried to make. It appears that the values get overwritten.

I tested the new version 5.x-1.x-dev (2007-May-10) and got this result:
- The selects are only stored in the cck, but definitly not in the term_node.
- ActiveSelect selects are not stored at all.

+1

I did a fresh install with latest versions of all modules and have the same problem.
Saving in the cck table does work, but I can't get it to write entries into the term_node table.

Did some debugging.
The problem is, that taxonomy_nodeapi() is called before content_taxonomy_field() is called.

Setting the module weight of content_taxonomy to -1 reverses the order, but then the taxonomy terms are overwritten with the state from the database before taxonomy_node_save() is called ...

Only lightly tested, but the attached patch seems to make things work for me.

hi ray007!

thanks for your help.
Normally, the content taxonomy gets called before the taxonomy module. all nodeapi hooks are managed by the cck module and cck calls the implemented functions in the field modules like the content_taxonomy.
I took a look to your suggested patch. It's interessting, that this solves the problem for you. The only thing, which is really different from the original version is, that you moved the appending of terms to the node object ($node->taxonomy[$vid] = $tids;) from the insert to the submit hook.
normally there is no need to implement the hook_nodeapi in the content taxonomy itself, because the hook_nodeapi is managed by the cck. We should use the hook_widget, but the hook_widget is managed by the different widgets modules itself what would mean, we have to implement the saving in every widget module which is quite not very clean.
I'll take a look at this and I hope I find a clean version that works for everybody ;)

I think this is a clean solution because:

- the documentation for cck field- and widget-hooks says the node-object should not be modified
- using the nodeapi-submit hook I ensure to set the data before taxonomy writes it
- using the nodeapi-submit hook I only once set the taxonomy data for all taxonomy fields in the node

I see no reason why it should not work for everybody.
Did I miss something?

+1 on patch submitted by ray007 on May 30, 2007

Have been using Content Taxonomy with no problems but yesterday ran into a problem when installing Taxonomy Access Control Lite. When submitting a CCK content type with Content Taxonomy, I was receiving the following error:

user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') AND th.tid IS NULL' at line 1 query: SELECT DISTINCT td.tid FROM term_data td LEFT JOIN term_hierarchy th on td.tid = th.parent WHERE td.vid IN (5) AND td.tid IN (1,20,) AND th.tid IS NULL in /home/domain.com/includes/database.mysql.inc on line 177.

After some initial testing, this patch appears to solve this problem. Thanks ray007.

Thanks, ray007. All values I enter into content type fields now appear in both node and CCK tables. However when I create a page view for the given content type, there are two problems. First, the values do not appear next to their CCK titles, but only as tags below the entry. Second, I cannot multi-select any fields using the activeselect widget, despite checking the multiple values option on either the vocabulary or the field or both.

Is this an outstanding problem with the module?

Thoughts/Ideas/Solutions would be deeply appreciated.

Thanks to ray007 for the patch. Now the taxonomy terms generally are stored correctly in the term_node table.

But I found the following problems while testing on a complete new drupal installation:

1. When you create a new cck-node (Create content), which contains a content taxonomy field you get the warning:
"warning: htmlspecialchars() expects parameter 1 to be string, array given in C:\apache2triad\htdocs\drupal\includes\bootstrap.inc on line 588."
The same problem occurs, when you are going to reconfigure the content taxonomy field (Administer > Content management > Content types > MyContent Type > Manage Fields > Configure).

2. If you choose "save in cck table" or "both" in the save options, the data is saved in the table of the content type (table: mycontenttype, column: field_myfield_value).
But all other cck-fields save the data in a separate table "content_field_myfield" instead.
This is done by Content Taxonomy as well, but only if the content taxonomy filed is assigned to two or more content types. When adding a second content type the data is shifted from the table of the content type (tabel: mycontenttype, column field_myfield_value) to a seperate table "content_field_myfield".
I think, this is not conform to the other cck-fields and causes problems, if you try to combine Content Taxonomy with the module Taxonomy Fields (http://drupal.org/project/taxonomy_fields): If you create a content taxonomy field using Taxonomy Fields (Administer > Content management > Taxonomy fields > Add new field), you can't enter any value to this field while editing the Node (create content), because the radio-buttons/checkboxes do not show up - perhaps because Taxonomy Fields expects the data in a separate table?

3. If you use the ActiveSelect widget and choose "save in cck tables" or "both" in the save options, the data is not saved.

4. If you use the ActiveSelect widget and choose "save as tags", the data is saved, but if you edit the node again, the third bar remains empty (if you submit then, the value is deleted).

Unfortunately I am not a programmer, but I hope this information is useful for coders to fix the issues.

@smitty:

ad 2) ...

AFAIK _all_ cck fields that are not multiple (be it in node or used in more than 1 contenttype) are stored directly in the table of the content-type

and I have encountered the problem with taxonomy_fields as well, but I haven't yet found out why it happens. I'd appreciate somebody else having a look at it too, since I have a bag full of other problems to solve right now too ...

@ ray007:

Thanks for this hint.
I hope someone else will solve the issues.

@ all:

I found two additional problems, which I think are connected to the issue of storing and picking data:

1. If you want to change the configuration of a Content Taxonomy Field later on, after clicking on "save filed settings" you get the message:

warning: Illegal offset type in C:\apache2triad\htdocs\drupal\sites\all\modules\content_taxonomy\content_taxonomy_options.module on line 145.

2. If you have two Content Taxonomy Fields (Radios) dependant on an other Taxonomy via Taxonomy Fields and you edit a node, the first (lower weight) Content Taxonomy Field does not get the stored value, so that all the radios are empty although the value is available.

Just wanted to confirm that Ray007's patch works for me too!

Is this patch going to be committed soon as this is a critical problem with this module at the moment.

is there something you want changed about the patch?

The attached patch (against current tip of DRUPAL-5 branch) fixes a bug that would occur if two content_taxonomy widgets on a node used the same vocabulary and both want to save to the node taxonomy too.

I'd really appreciate this patch or something functionally similar going in, it's really a major bug that we have in mainline right now.

The attached patch (against current tip of DRUPAL-5 branch) fixes a bug that would occur if two content_taxonomy widgets on a node used the same vocabulary and both want to save to the node taxonomy too.

I'd really appreciate this patch or something functionally similar going in, it's really a major bug that we have in mainline right now.

I’ve tested the new patch and found that the former described warnings have disappeared now.

Only the problem with showing the stored values of several Content Taxonomy Fields dependant on the module "Taxonomy Fields" has remained:

If you have two Content Taxonomy Fields (Radios) dependant on an other Taxonomy via Taxonomy Fields and you edit a node, the first (lower weight) Content Taxonomy Field does not get the stored value, so that all the radios are empty although the value is available.

But I am not sure, if this is an Issue of "Content Taxonomy" or "Taxonomy Fields".

Just an FYI, I was still unable to get "Save as tag" to work with the current 5.x-1.x-dev snapshot. After playing with it, I changed line content_taxonomy.module:129 to be 'submit' instead of 'validate' (this line was set to 'validate' within the patches found in this issue thread); the 'validate' case was never being called for some reason.

That's what this thread is about: without patching saving as tag doesn't work - at least it never did work for me until I made the patch.

I can't patch so I have to make the changes manually and I'm desperate for this to work and puzzled why @ray007's patch isn't being applied.

I'm so desperate for the fix I thought I'd apply it manually but I'd be really really grateful if the module owner could look at committing this into a proper release soonest!

Why can't you patch?
Or just missed the docs at http://drupal.org/patch/apply ?

Hi everybody,

First, thank you mh86 for your module. It's what I need ^^
But, I have the same problem as llribas & cie.

I posted a message on drupal.org but no answer :| (http://drupal.org/node/163706)
For me, two problems :
- No link in the table `term_node`
- Two identical copies of the new term in the table `term_data`

In France, it's too late to work. But, tomorrow, I will test the ray007's patch. I will cross my finders all the night :P

Cheers

Axmodeux

My configuration :

Drupal 5.1
MySQL database 5.0.24a
PHP 5.1.6
Unicode library PHP Mbstring Extension
Web server Apache/2.2.3 (Mandriva Linux/PREFORK-1mdv2007.0)

The modules I use :

CCK

Content 5.x-1.5
Content Taxonomy 5.x-1.x-dev
Content Taxonomy Autocomplete 5.x-1.x-dev
File Field 5.x-1.x-dev
Text 5.x-1.5

Core - optional

Taxonomy 5.1

Other

'me' Aliases 5.x-1.x-dev
Pathauto 5.x-1.1
Taxonomy Access Control 5.x-1.0
Taxonomy context 5.x-1.x-dev

I hope, it will help to fix this problem.

Hi!
I'm sorry, I was a little bit busy the last weeks and didn't had time to clean up the issue queue.
I think this problem is maybe connected to the module weights. The CCK/Content Taxonomy has to be invoked before the taxonomy module on node generation.
The patch from ray007 is some kind of workaround. It uses the validate hook to collect the terms and additional implements the hook_nodeapi with submit for adding the terms to the node->taxonomy array. In my opinion it's not very clean, because first validation should only be for validation and second cck does already handle the hook_nodeapi.

It would be of great help, if you can tell me your module weights of CCK, Content Taxonomy and Taxonomy. You can use the moduleweight module for reading/changing the weights.

Thanks.
Matthias

If possible I'd prefer a solution that doesn't depend on fiddling with module weights. Otherwise it only works until some other module decides it needs to change its weight - wouldn't be the first time a weight change breaks something.

agree. a stable solution would be fine.
I thought about, checking the module weight in hook_insert, e.g. if (content_taxonomy comes before taxonomy) { add to $node->taxonomy} else { insert directly into db (term_data) }...
but before I have to see if there is a way in doing this without a performance lost.
Or I just change the module weight of cck to e.g. -10, but not sure if this can have any side effects....

It would be of great help, if you can tell me your module weights of CCK, Content Taxonomy and Taxonomy. You can use the moduleweight module for reading/changing the weights.

All modules have a weight at 0, except :
- Taxonomy Access Control 5.x-1.0 = 9
- Views 5.x-1.5 = 10

Bye

@Axmodeux
could you disable the Taxonomy Access Control once in module settings and try the saving without it?
would be interesting.

If you install a new cck the fieldgroup module is at 9.
auto_nodetitle is at 5.
Another module to take care of is probably 'token' - that's at weight 0.

if someone has problems when updating a node, there was a small bug in content taxonomy module in the latest dev snapshot, which got fixed (it will take some time that the snapshot on the project page gets updated automatically (12 hours)).
but I don't think that this does solve this issue...

Just one comment if you manage to make the current code work: I think it would be good to rename the global variable $cleared to something indicating it belongs to this module ...

THEN :

By default :
- No reference in the table `term_node` of the relation between the object and the term of my categorie
- The term is systematically add in 2 copies in the table `term_data`

With patch :
- References are present in `term_node` but there are not display when I display my object
- The term is systematically add in 2 copies in the table `term_data`

With patch and without Taxonomy Access Control 5.x-1.0 :
- References are present in `term_node` and there are display when I display my object
- A term is add one time if it's new and re-use if it's wanted for an other object.
- But, without Taxonomy Access Control (which was install before I take the site), a new label with some nasty lists of my attached term is display in the middle of my form.

It seems better in general. But, I don't want those list any more :[
Can I enable 'Taxonomy Access Control' and I play with its weight ?

Bouh .... :[
Before, it was beautyfull but it didn't work.
Now, it's work but it's no so pretty

Thank for your help (I will refer in my web page ^^)

PS : I didn't try without patch and without Taxonomy Access Control 5.x-1.0.
PS : Next week, I will not be available. Then it's not because I stop to disturb you that I give up :P

hi
first thanks for your detailed report. I think we are getting closer to the problems (I hope.. ;) ).
Concerning the two copies in the term_data, this might be a different issue.
Only one request left: can you please try it without the patch and without TAC ?

Hop :

By default :
- No reference in the table `term_node` of the relation between the object and the term of my categorie
- The term is systematically add in 2 copies in the table `term_data`

By default and without Taxonomy Access Control 5.x-1.0 :
- No reference in the table `term_node` of the relation between the object and the term of my categorie
- A term is add one time if it's new and re-use if it's wanted for an other object.

With patch :
- References are present in `term_node` but there are not display when I display my object
- The term is systematically add in 2 copies in the table `term_data`

With patch and without Taxonomy Access Control 5.x-1.0 :
- References are present in `term_node` and there are display when I display my object
- A term is add one time if it's new and re-use if it's wanted for an other object.
- But, without Taxonomy Access Control (which was install before I take the site), a new label with some nasty lists of my attached term is display in the middle of my form.

Without patch : problem of reference
With Taxonomy Access Control : problem of duplication

Bye

PS : if you have a solution (module) to search some objects (content type) with different parameters (term of different catagories), a kind of multi-parameters search (I want all films which are comedies and french ... it's an example, because I deal with biological data). I know that's is not the place to speak about that.
PS : and now vacation ... sorry ^^'

Hi all!
Finally I was able to test the content taxonomy module on a other system, and yes you all were right :). It was a small mistake. I always thought that the cck module gets called before the taxonomy module, even if they have the same weight. But I was wrong, when the module weight is equal, they are not ordered by their name (as I would have expected). Instead they are sorted by the filename, which is modules/taxonomy and sites/all/cck (recommended since drupal-5). I was a bit lazy concerning installing directory and always had cck in modules/cck, so that cck was called before taxonomy and all worked fine.

I added an installation script which increases the taxonomy module weight to 1. Download the latest version from today and run the update #1. This fixes the saving bug.

Thanks
Matthias

You can't change the weight of a module other than your's, and a core module at that. You got no idea what could potentially break when you do that.

Maybe try to use the 'validate' operation in the field-hook to update the node-taxonomy if you don't like my fix?

hi!
maybe it's not the best solution. concerning the weights, I have two possibilities, I can decrease cck or increase taxonomy. Both may have sideeffects.
Anyway, I thought about this issue again. I think the best way would be to use the hook submit in the widgets. Has only one disadvantage: it has to be implemented in every widget..

I removed hook update and insert in content taxonomy, because of weights problems...
Instead, as I mentioned, I'm going to use hook_submit instead. This has to be implemented in every widget (only 3 lines), which call a central function (content_taxonomy_submit_terms) which adds terms to the $node->taxonomy array. When using the submit, we can be sure, that taxonomy's insert is called afterwards (without manipulating module weights).
It's not committed yet, but I attach the patch, how it will approximately look like (some widgets are still missing).
Any comments?

I'm back ^^

Then my comment :

Status report

Database schema Out of date
Some modules have database schema updates to install. You should run the database update script immediately.

I had just apply the new version and I had this message. When I apply the patch, I still have this message.
I will backup my database after lunch and test to use the update script !?.

But is it normal ?

Haven't tested the patch, but it looks good and I think that's the right way to do it.

With the new version and the new patch,

I meet the same problem than before ray007's patch :[
No references in the term_node table and incompatibility with Taxonomy Access Control module.

I put modules I install in $root/sites/all/modules/

Now all modules have a weight at 0, except :
- Taxonomy 5.1 = 1
- Taxonomy Access Control 5.x-1.0 = 9 (disabled)
- Views 5.x-1.5 = 10

PS : in French, "Beta tester" sound like "Stupid tester". I do my job the best I can :P

I'm sorry, this patch isn't completed yet. (the status of this issue was wrong..). If you are using autocompletes, they won't work, because not included in the patch (coming soon). With the patch from todays we can delete changes (weights) from yesterdays.
Anyway, version from yesterdays without this patch should work.

I know, a bit confusing...
thanks for testing and you patience

I've just removed the installation files from yesterday and did solve the problem in a different way.
The solution is pretty simple. Just replaced 'insert' (and 'update') in content_taxonomy_field with 'submit' (wasn't aware that's possible to implement 'submit' in hook_field...).
The documentation at api.drupal.org says:

submit": The node passed validation and will soon be saved. Modules may use this to make changes to the node before it is saved to the database.

I thinks that fits perfectly to our case and now we can be sure that it gets called before taxonomy's insert, independent of any weight settings.

See diff for changes.

Thanks very much for your help and your patience....
If the problem still exists with the latest dev snapshot from today, don't hesitate to reopen it again. (incompatibility with TAC should be a different issue)

It seems to be ok.

(incompatibility with TAC should be a different issue)

With your reactivity, we can't be afraid to post another problem.

Thanks

Thanks, as far as I see, it's now ok.

Only the problem in combination with the module Taxonomy Fields isn't solved yet.
Shall I open a new issue for that?

It appears that the Taxonomy fields that Content Taxonomy manages work just fine now. However, its completely removing all other Taxonomy information on node submit for me!

I've narrowed it down to line content_taxonomy.module:126 :

      global $content_taxonomy_array_cleared;
      if (!is_array($content_taxonomy_array_cleared) || !$content_taxonomy_array_cleared[$node->nid]) {
        unset($node->taxonomy); // <-- THIS HERE
        $content_taxonomy_array_cleared[$node->nid] = true;
      }

As it happens, I've moved Taxonomy to a directory different from /modules, so the ordering might be different as has been discussed earlier in this issue. Could this code instead clear the term information for the vocabularies it should be managing on submit and not for every term associated with the node?

Thanks!

I second this, but I'm not sure if its just taxonomy storage that's broken. In lieu of multiple selection when using Activeselect, I have been trying to use two CT fields filled from the same vocabulary, but with different fieldnames. I have been studying the stored nodes with print_r($node), and although i see things changing, I can't figure out where what is going wrong.

If I store the field as tags, both of my fields display (CCK display) with the value from the last CT field. Taxonomy shows that all the terms have been stored. Browsing the $node structure, I see that the field data has the data for the second field in both fields.

This is the stored taxonomy data from the two fields:

[taxonomy] => Array
        (
            [59] => stdClass Object
                (
                    [tid] => 59
                    [vid] => 5
                    [name] => Indie Nights
                    [description] => 
                    [weight] => 0
                    [language] => 
                    [trid] => 0
                )

            [53] => stdClass Object
                (
                    [tid] => 53
                    [vid] => 5
                    [name] => Music
                    [description] => 
                    [weight] => 0
                    [language] => 
                    [trid] => 0
                )

            [45] => stdClass Object
                (
                    [tid] => 45
                    [vid] => 5
                    [name] => Musician or Band
                    [description] => 
                    [weight] => 0
                    [language] => 
                    [trid] => 0
                )

            [36] => stdClass Object
                (
                    [tid] => 36
                    [vid] => 5
                    [name] => Artists
                    [description] => 
                    [weight] => 1
                    [language] => 
                    [trid] => 0
                )

            [40] => stdClass Object
                (
                    [tid] => 40
                    [vid] => 5
                    [name] => Programme & Curators
                    [description] => 
                    [weight] => 5
                    [language] => 
                    [trid] => 0
                )
        )

Arrays 59, 53 and 40 come from field 1, and 45 and 36 come from field 2.

Here are the cck fields for field 1:

[field_gulesider_hovedkategori] => Array
        (
            [default_tid] => Array
                (
                    [0] => 36
                    [1] => 40
                    [view] => Artists 
                )

            [default_children] => Array
                (
                    [0] => 45
                    [view] => Musician or Band 
                )
        )

And for field 2:

[field_gulesider_bikategori] => Array
        (
            [default_tid] => Array
                (
                    [0] => 36
                    [1] => 40
                    [view] => Artists 
                )

            [default_children] => Array
                (
                    [0] => 45
                    [view] => Musician or Band 
                )
        )

So what must be happening here is that the second field is saved on top of the first.

This is all with CCK 5.x-1.6-1 and Content_taxonomy + Activeselect dev-versions downloaded today. The vocabularies are not associated with the content-type so as not to conflict. If this is somehow caused by activeselect, tell me and I'll go elsewhere.

Just confirmed that this happens without Activeselect as well. Please tell me if I'm barking up an utterly separate issue here..

Also, In a tri-level vocabulary, sans activeselect, the second level is not stored, which probably explains why Triple activeselects always lost the second level, but stored first and third. Natch. This must be a separate issue, will post bug if necessary.

Reply to #79: Since the last version of the module "Taxonomy Fields" both modules work together without any problems.

Reply to #80: seems to be http://drupal.org/node/166873

the issues followed up after the fix are not related to this topic, as smitty reported. so, again I mark this as fixed.

i have really been looking for a solution to this problem.

have you updated the release to include all the patches?

chris

Guys, a real bug here!!!!!

Was read all topics - no solutions still.

The problem is next - when using content taxonomy and taxonomy on one content type - I can save cck taxonomy fields and basic taxonomy is lost (when I am saving cck taxonomies to node terms), or both cck taxonomy fields and basic taxonomy, but cck taxonomy fields are not stored to node terms (when don't save them to node terms).

I want a both data saved to node terms. How to do that?

Please fix guys! The bugs is not yet solved. Bug is very huge and important.

Re-opening. This is definitely still a problem in the latest in the repo.

Just found out after editing 100 nodes and putting in taxonomy terms that they've not been saving. Thrilling.

I was having the same problem with a content taxonomy field preventing the standard taxonomy field info from saving.

I commented out line 126 of content_taxonomy.module (see comment #80, above), and that seems to have fixed the problem.

unset($node->taxonomy);

I don't know what problems this will cause elsewhere, if any, but it does fix my current problem.

Cleanup of old issues. According to maintainer: "active development is only done for the 6.x branch! 5.x is not supported any more".
Reopen issue if problem still exist in 6.x branch.