No way to attach the automatically created taxo field

If we remove the automagic field creation step, then the workflow becomes:
1) Create a vocab in admin/structure/taxonomy/add
2) Enable the vocab on some node types by:
a) Go to 'Manage Fields' for node_type_1, create a *new* field of type 'taxo term', give it the same label than your vocab (unless you actually want a different label), and configure it to use terms from your vocab
b) Go to 'Manage Fields' for node_type_1, add the *existing* field you just created
c) Repeat b) for other node types you want the vocab to appear in.

- That's a net loss from the D6 UX :-/.
- I also think the end result in most cases will be many separate fields on different node types - i.e users doing step a) on each node type -, instead of one shared field per vocab.
Thanks to the taxonomy_index table, this will make no difference for taxo/term/%tid listing pages, even possibly not for Views *node* listings.
But code-wise, it means that, if custom code needs to find out if $node has a given term, it needs to check $node->field_foo if node type is node_type_1, $node->field_bar if node type is node_type_2, etc. Sounds like a WTF.

Possible counter proposals:
- Add the 'content types' checkboxes in the 'create new vocab' workflow - this automatically creates a taxo field on the selected types. If no type is selected, no field is automatically created.
- On the creation of a new 'taxo term' field on a vocab for which there is already an existing 'automatically created' field, display a warning message like 'Is this really what you want to do ? You might want to do X instead.'.

I was suggesting the duplicate approach. I'm not saying this is ideal. But this is better than either the current or #2-#3.

re webchick #12:
The issue did not exist in D6 because there were no separate notion of fields and instances. The only way to have a field exist was to actually attach it to a node type. Had nasty WTFs, because when asking for info on one field (as in 'some data bucket'), you always got some instance-specific info along, from "one of" (random - possibly but not officially, the first in time) the node types the field appears in. So in D7 we separated $field and $instance.

The UI 'hides' that $field / $instance distinction, that would be complex for end users: all they see are 'fields on a given bundle' (i.e instances).
This also means that when a user does 'delete field', it's actually 'delete instance'.
UI has no way to delete a $field. When an instance is deleted, Field API takes care of deleting the field if it has no more instances (happens at the end of field_purge_batch()).

So I'm fine with patch #10 (and +1 on using optgroups in the 'add existing field' dropdown, as in #11 shot "-3.png" ).
I agree with webchick and support the "magically created 'term in %vocab' field" and the 'node type checkboxes' on vocab page - because without those, UX is terrible compared to D6, see my #3 above.

But we still have an issue with the following workflow:
- Admin creates vocab -> field taxonomy_$vid is created
- Admin creates instances for a couple bundles (either through the 'node types' checkboxes on the vocab form, or through 'add existing field' in Field UI)
- Admin later removes a couple instances -> when the last one is gone, the field is deleted
At this point, the field cannot be re-added through Field UI, and we're back at 'no default field associated to the vocab' and #3.

Maybe one solution would be a hook on instance deletion to let modules say 'keep the field around even if it's the last instance' ?

Magically creating the field only for UI created vocabs sounds valid to me.

I'm fine with removing the 'automatic field creation too' if webchick or Dries agrees to it, but I have to ask again: is the workflow described in #3 really what we want ?
It drastically raises the number of admin pages and clicks to enable a vocab on n node types, + raises the chances of misconfigurations (1 field per bundle, where actually one single, shared field was intended)

If the field is auto-created and someone can add it to a content type by using "add existing field", that wouldn't be bad, but I also don't think it's all that much more of a difficulty to create it via "add new field".

It's not more of a difficulty and that's the problem - that's what I point in #3:
"I also think the end result in most cases will be many separate fields on different node types - i.e users doing step a) on each node type -, instead of one shared field per vocab.
Thanks to the taxonomy_index table, this will make no difference for taxo/term/%tid listing pages, even possibly not for Views *node* listings.
But code-wise, it means that, if custom code needs to find out if $node has a given term, it needs to check $node->field_foo if node type is node_type_1, $node->field_bar if node type is node_type_2, etc. Sounds like a WTF."

The current situation, where the field is auto-created but you cant' possibly do anything with it, is obviously crazy

Well, not exactly, it's a bug, and we obviously can't ship as is :-)

This being said, I can understand the argument that taxo fields should be handled like any other field, and that given some time and proper docs, users will educate themselves with the subtleties of "add new field / add existing field".
This distinction has always been one of the toughest things in CCK, though, and is not easily explained without saying the words 'storage location' or 'db table'...

Agreed that it's the best option at this point.

Nitpicks:

+++ modules/forum/forum.install	29 Jan 2010 06:16:49 -0000
@@ -21,14 +21,11 @@ function forum_install() {
+  // Create the forum vocabulary if it does not exist. Assign the vocabulary
+  // a low weight so it will appear first in forum topic create and edit
+  // forms.
+  $vocabulary = taxonomy_vocabulary_load(variable_get('forum_nav_vocabulary', 0));
+  if (!$vocabulary) {
     // Create the forum vocabulary if it does not exist. Assign the vocabulary
     // a low weight so it will appear first in forum topic create and edit
     // forms.

We duplicate the comment ?
Besides, I don't think there's still any correlation between the vocab weight and the position of the input element in the form ?

+++ modules/taxonomy/taxonomy.test	29 Jan 2010 06:16:50 -0000
@@ -323,6 +323,23 @@ class TaxonomyTermTestCase extends Taxon
+      // Set cardinality to unlimited so that select
+      // and autocomplete widgets behave as normal.

'as normal' makes sense in a 'coming from D6' angle, but I don't think core comments should look back. The comment can now go IMO (2 occurrences).
At least, the 80 chars wrapping needs fixing.

Powered by Dreditor.

RTBC. Attached patch just does additional comment fixing, don't credit me.

#35 got fixed in #1003308: Forum module cannot decide if it wants 'taxonomy_forums' hardcoded in it leading to faulty functioning. back to 'closed'