content_taxonomy removes other category selections

I'm also having similar problem.
Is there any work around for this?
--
Shrique

I discovered the cause.

hook_form_alter() in content_taxonomy.module removes all the taxonomy category form elements:

unset($form['taxonomy']);

If you specify a vocabulary ID, only that element is removed:

unset($form['taxonomy'][20]);

Obviously hacking the module and including a hard-coded ID is not the solution.

Ideally the module needs to remove only those taxonomy fields where a autocomplete counterpart exists. Unfortunately making this association is tricky.

Worst case the field removal should happen at the theming level in templete.php.

It works.
Thanks.
--
Sharique

I'm beginning to think this module creates more problems than it solves.

The 'submit' case in function content_taxonomy_field() unsets the node taxonomy object, which wipes all taxonomy selections (other than those created by content_taxonomy.)

I had to suppressed this line in order to preserve the values of my other taxonomy form elements.

content taxonomy fields and taxonomy fields can clash if you save content taxonomy fields as tags. that's the reason why the module removes any other taxonomy field. If the module doesn't hide the fields, other people write issues about, how they can hide the taxonomy fields.
anyway, you can add the category fields from the taxonomy module as content taxonomy fields.

matthias

I created a patch... I figured I should start doing things the right way. (Or I hope it's the right way!)

I use this module to allow me to effectively move taxonomy form elements from their "fieldset" ghetto into better positions in the node edit form. The part of this module that allow you to save term values solely as CCK fields rather than as tags/terms doesn't interest me at all.

So I've already revised the patch. I found that when a field's domain is a subtree of a vocabulary, I need to be more precise about what I unset on the form's taxonomy element.

I'm a bit torn about what's more practical or correct. If a field is made of taxonomy terms from a whole vocabulary, I can assume that we don't want a conflict between the taxonomy form element and the taxonomy_content form elements. In that case, I can zap the taxonomy elements in the form because all those values will be translated into taxonomy_content field values.

However, if a field is made of terms from a subset of a vocabulary (i.e. the field's tid > 0), that doesn't mean that the taxonomy form control is irrelevant, and I certainly don't want data to be deleted just because the field definition excludes it while the taxonomy definition allows it.

The outcome for me of not zapping all taxonomy element options when a field uses a vocabulary's terms is that I end up with valid but very very odd category options!

Take for example a taxonomy tree like this:

Organization
-- Member
-- Partner
-- Service Provider
Person
-- Staff
-- Board
-- Expert
-- -- Economics
-- -- Housing
-- -- Media

If I create a field with a depth of 1, parent is 'Person', my node edit form will have this category element:

Organization
-- Member
-- Partner
-- Service Provider
Person
-- -- Economics
-- -- Housing
-- -- Media

STAFF, BOARD and EXPERT get moved to a field in the node form, but all their poorly conceived siblings are still available to me.

Nonetheless, here's my patch. I'm running with it.

One more revision to the patch.

Thanks for your efforts regarding the patch. I'm anxious to hear your final conclusions.

After applying the patch, I'm getting an error message now in my content: "warning: Invalid argument supplied for foreach() in /...modules/content_taxonomy/content_taxonomy.module on line 232." What is the deal? Anybody?

<------------------------------->

function content_taxonomy_form_alter($form_id, &$form) {
$content_type = $info['content types'][$form['type']['#value']];
foreach ($content_type['fields'] as $field_name => $field) { <------this is line 232------>
if ($field['type'] == 'content_taxonomy') {
if (($field['tid'] == 0) && (array_key_exists($field['vid'], $form['taxonomy']))) {
unset($form['taxonomy'][$field['vid']]);
}
else {
$tree = taxonomy_get_tree($field['vid'], $field['tid'], -1, $field['depth']);
foreach ($tree as $term) {
$field_tids[] = $term->tid;
}
foreach ($form['taxonomy'][$field['vid']]['#options'] as $key => $element) {
if (is_array($element->option) && key($element->option)) {
$tid = key($element->option);
if (in_array($tid, $field_tids)) {
unset($form['taxonomy'][$field['vid']]['#options'][$key]);
}
}
}
}
}
}
}

Joepril, it looks like you didn't apply the patch to the latest development release perhaps? The function you pasted is not a valid outcome of the patch I created. It's missing a IF statement that should prevent the foreach problems.

subscribing

subscribing

I'm confused. A lot of people are subscribing but nobody has responded to the patch. I'm running with the patch. I'm not declaring it perfect. Can someone please give some feedback?

After applying the patch at #9 I get the following error, also reported at #11, and the patch didn't generate the suggested IF statement, perhaps the patch itself is the wrong version?

warning: Invalid argument supplied for foreach() in /var/www/vhosts/dev.lwa.gov.au/httpdocs/sites/all/modules/content_taxonomy/content_taxonomy.module on line 244.

This is what I have after the patch:

Hmm... I've applied other essential patches from the issue queue to my copy of the module, so I wonder if that causes the offsets to be off.

Are you able to demonstrate what IF statement should be in that piece of code? I applied it manually by checking text against line numbers and copy/pasting, so I don't think the line numbers were that much of an issue. And there is no IF statement in your patch at the point I've indicated.

I'm happy to tackle this issue myself, but Im just not sure what we should be testing for?

Thats great, thanks mate. That works for me (though I still have several other problems)... now to construct an accurate patch!

Incidentally, after staring at this for several days i realised i had the Hierarchical Select module installed and active on the relevent taxonomy i was testing with, and it was borking the Select List option. Just a tip in case others get caught.

Patch for 5 updated with bangpounds extended content_taxonomy_form_alter from #19. Includes my fix for illegal offsets from http://drupal.org/node/234622.

I applied the patch from #21 and received the following error once for each taxonomy field that was called.

warning: array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in /home/qwynk/public_html/ngimat/modules/content_taxonomy/content_taxonomy.module on line 242

In addition, this did not fix my similar but possibly unrelated problem. When editing nodes through non-cck modules my taxonomy fields are erased. The database shows that their values are set to 0 yet the term-node table remains untouched so my node's tags remain! Is this a related problem?

As a last note: editable fields and the workflow MENU_LOCAL_TASK tab were two different forms which when submitted cleared out the CCK field data for that node. All widget types are affected. CCK taxonomy fields in content types table as well CCK taxonomy fields residing in their own table are affected. I apologize if this is completely unrelated however its the closest thread i've found. If its unrelated I will submit a new thread. Thanks

Im looking at your first problem, but while I do that, a couple of questions about the other two:

1. When your taxonomy fields are erased, do you have the CT fields set to Tags, CCK, or both? Im assuming both?
2. Im confused about "editable fields" and "workflow MENU_LOCAL_TASK". What are you referring to here?

UPDATED: I just read your other post regarding this issue. Ignore these questions.

+ subscribe
I have the same warning:

array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in /home/qwynk/public_html/ngimat/modules/content_taxonomy/content_taxonomy.module on line 242

I find out that there is no array $form['taxonomy']. There is only an object $form['#node']->taxonomy

Yep, the patch's working: my taxonomy is saved. But same problem:
warning: array_key_exists() [function.array-key-exists]: The second argument should be either an array or an object in /Shared Items/iDoc/drupal/modules/content_taxonomy/content_taxonomy.module on line 246.

Corresponding snippet is, in "Implementation of form_hook_alter":

(edit: my content taxonomy fields do show up)

Thanks

you can try this solution :
line -->246 if (($field['tid'] == 0) && (array_key_exists($field['vid'], $form)))

you can try this solution :
line -->246
if (($field['tid'] == 0) && (array_key_exists($field['vid'], $form)))

Or

The second part of code in #27 combined with the code in #25 seems to work. I am attaching a patch made against the dev version of July 7, 2008.

Note that any real Categories must be turned into CT fields (you can use Save as Tag is you want to). This is by design with this module - its meant as a total replacement for Taxonomy fields.

A fix for this would be great for the 6.x version too ... not sure where that might be in the queue, but I imagine this will cascade upward ... just wanted to make sure. Thanks!

Note that any real Categories must be turned into CT fields (you can use Save as Tag is you want to). This is by design with this module - its meant as a total replacement for Taxonomy fields.

Wait wait wait. This is the first I've heard of this design principle on this module. Where is this documented?

I read this in one of the issues, I just can't remember where. But it kind of makes sense (at least to me) with the options that CT provides for storing terms.

I read this in one of the issues, I just can't remember where. But it kind of makes sense (at least to me) with the options that CT provides for storing terms.

If this is the case, it should be documented in the module explicitly. The possibility of storing a term selection as a CCK field and/or as a term leaves the door wide open to any use, even ones that are going to be problematic. The patches I've made on this module (and this issue) could have been much simpler if I hadn't tried to keep the node's own taxonomy terms 100% accurate vis-a-vis the content taxonomy field's terms in a particular vocabulary.

I read this in one of the issues, I just can't remember where. But it kind of makes sense (at least to me) with the options that CT provides for storing terms.

Wow, I'm hoping that isn't the case. I definitely like the concept of the retaining taxonomy integrity and selectively overriding and/or augmenting individual vocabs (or parts of vocabs).

Guys, read comment #5 above, from the module maintainer. My understanding of that is why I wrote what I did in #28.