Taxonomy as Fields in Drupal 7 Core

The issue: http://drupal.org/node/412518

See also:
http://agaric.com/note/sharing-a-complex-drupal-patch-contributing-core-with-git

Notes

Per bangpound's goal in comment #12 we are removing the term_node table. Since searching for {term_node} is so convenient, Agaric ran the grep on a Drupal 6 install (the new database layer in Drupal 7 gets rid of the brackets.

In core, forum module used the table directly. Taxonomy module also did itself of course.

In some of the essential contrib modules, term_node was in Views, Token, Nodequeue, Pathauto, and Image modules.

In D7 the table is (intelligently renamed) taxonomy_term_node and is used by node module and forum module as well as taxonomy module.

It's interesting. We want taxonomy_term_node to become a cache table, but you cannot use Drupal-style cache tables in a normal query (involving other tables). There's no chance to say "build this table if it doesn't exist. What we're doing here isn't unique, it's the common practice of de-normalizing for performance, but I can't think of another example in Drupal.

"These nodes are connected. We don't know why they are, but they are." How often will that really be used? The forum module needs to know if the vocabulary in that instance is really being used as a forum-- is the field forumized or not?

Should we include the field name in this denormalized taxonomy_term_node table so that all the infomation we could want is easily

What's the story?

Oy vey, Drupal 7 doesn't have a "Story" content type anymore– it has been replaced with "Article". (Note: node.module needs its help text updated, line 69.) The reason I was looking Story up is because taxonomy needs a "story"– a use case in core.

Oh dear. Article is implemented as code that runs in profiles/default/default.profile and modules/field/field.crud.inc. This is wrong. Very wrong, in my opinion.

Article should be implemented with a module that makes use of the Field API so that more than one installation profile can use it and so that there is not specific, custom-ish, ahem, crud, in field module. Most important, it provides a place for people like me working with Drupal code for projects to see "how core does it"– without how core does it being some method available only when developing for core.

[Update: I take half of that back, crud.inc.api uses Article as an example, but there is no article-specific code there. On the other hand, article doesn't use fields at all in Drupal core in its present state of development (and nothing else does, either).

Since I do not have time to ake it step by step (refactor Article code into Article module, get it committed, etc.) I will make an example taxonomy module that creates, say, a "Catalog" content type, and we can use this as the proof in core of attaching a taxonomy to a module (since there is not yet a UI for fields in core anyway, our example must be programmatic).

Paranoia Checks

Do we need to re-implement or do anything else for hook_node_type(), which we removed? (It updated the node type name in table taxonomy_vocabulary_node_type, which we also removed.) No.

Resolution