Provide a taxonomy term field type

Duplicate of #412518: Convert taxonomy_node_* related code to use field API + upgrade path?

Great to tee you embrace this, bangpound !

Sticking this on the generic 'integer list' field type seems odd, though. Just like we wouldn't cram 'node reference' field type on the 'list' field type, I don't think we can spare a dedicated 'term reference' field type.

The problem I have with this hunk:

-      'settings' => array('allowed_values_function' => ''),
+      'settings' => array('allowed_values_function' => '', 'vid' => ''),

Is that if Organic Groups module wants to expose "Group selector as a field" (which is entirely possible), they have to provide a patch to list.module in core. Big ol' -1 to that.

I understand the concerns about code duplication, but we ultimately need figure out a way to make whatever works here work for both core and contrib.

I see the arguments about 'term_ref field almost equals list field'. Right now in D6, node_ref and user_ref are maybe like 70% code duplicates, but the differences are not easily mergeable within the current field concepts. An OO model where a field type can subclass another would possibly alleviate some of this, but that's not likely to happen in D7.

More specifically on 'taxo as field':

- The problematic hunk + 'settings' => array('allowed_values_function' => '', 'vid' => ''), is gone, but taxonomy_field_allowed_values() still refers to $field['settings']['vid'].
'vid' becomes an 'unofficial setting'? Works, I guess, but feels odd, and could easily break in the future.
Could possibly be worked around with a generic 'allowed_values_args' setting.

- the point raised in #8 about specific widget needs also applies to formatters : the current approach makes the 'Term: link', 'Term: plain text' formatters available for all 'list' fields, while they don't make sense for 'regular' list fields. This approach thus cannot be extended to other 'almost list field' field types without clobbering the list of display options with irrelevant choices. If the approach doesn't scale to similar use cases, I'm not sure it's a good approach.

- In #111127-207: Cache node_load we defined a generic pattern for 'reference' field types. For 'taxo as field', it translates to:
For performance, actual term data needs to be multiple-loaded at field_attach_load() time and get saved in the field cache, instead of having separate taxonomy_term_load() calls in the formatters (note : it seems to be the role of taxonomy_field_attach_load(), but I'm not sure what the function actually does).
Then when a term definition is changed or a term is deleted (hook_taxonomy_term_[update|delete]), the field cache needs to be cleared, using field_attach_query() : "find all objects that have value $tid on a 'term_ref' field, and clear their field cache"
With the current approach the latter needs to become "find all objects that have value $tid on a 'list' field with 'allowed_values_function' == 'taxonomy_field_allowed_values' ". Ugh.

- Usability: how do you explain to end-users "you want to add this vocab to this node type ? sure, add a 'list' field, and make sure to provide the right allowed_values_function" ?

I'm pretty much convinced this deserves a dedicated field type.

So taxonomy_field_attach_load() currently just pre-loads the terms into memory - then taxonomy_term_load() is pulling them from the static instead of the database individually. But agreed it'd be better to have these in the actual field cache instead. I think yched's making good arguments in favour of a term reference field, there's not a lot of code duplication really between the two patches, and I can see this extending a lot.

Just a side note, I'd like to be able to use autocomplete for non-tagging vocabularies - for both interface and performance reasons with huge vocabularies - so it'd be good to have the autocomplete widget and actual term creation separated (similarly if hierarchical select becomes a field formatter and lets you create terms from select lists).

This is looking really nice though :)

@bangpound:
- No, nothing in core uses list fields yet. 'Node body' is the only core field, right now...
- CCK HEAD is updated to work with D7 Field API (but I guess you know that, you posted a patch over there)

No! Dont let them! Benchmarks! What is this craziness of putting vocabularies in titles when the issue is about terms and not just vocabularies?? That's like trying to make aggregator items nodes when the issue title says make aggregator feeds nodes.

Rather than just unsetting the ID in term_field_load() we should also stuff the term object in there - hook_field_load() is cached - and won't be run each request, so we actually have to do this if we want to pre-load terms at all, I forgot this when talking about it in irc :(. text_field_load() does similar. This probably means iterating over each delta rather than the array_search, but at least all the work will be cached. Not sure where to put the term object though - can this be in 'value'? Or we need a separate array key for the full term object?

I'm a bit concerned about the formatters:

+  $field = field_info_field($element['#field_name']);
+  if (($allowed_values = term_allowed_values($field)) && isset($allowed_values[$element['#item']['value']])) {

That means running term_allowed_values() for every term shown on every page - since we're removing invalid tids in hook_field_load() that should be enough no? Even if it's not I think the formatters should be dumb and do the minimum amount of work possible - allowed values should validate input, can't be responsible for already saved data if admins change it later.

The cache clearing looks good. If/when #333171: Optimize the field cache goes in we should be able to make that an array of cache IDs to clear instead of one by one deletes.

function term_field_schema is weird with a default only switch. I think we want tests too.

Re catch #15: The additional data loaded in hook_field_load() should be put in additional keys. D6 filefield merges data from the {file} table into a flat array with keys fid (the original, raw field value), filename, filepath, etc...

Didn't think about this earlier: with terms now being fieldable, calling taxonomy_term_load() in term_field_load() triggers field_attach_load() on terms and introduces potential infinite loops. More general issue with any 'foo reference' field if 'foo' entity is fieldable. Think "term with a term field" (odd but not forbidden) or "node references term which references node".
I'm still convinced that loading referenced data in hook_field_load() is the right approach, but I'm not sure of the best way to avoid infinite loops.
Maybe hook_field_load() should only load base properties: hardcoded, predictable set of properties, which are also the only ones needed by most common formatters, so this is good enough for us.
But:
- partial loads should be multi-loadable too
- they can not pollute the static cache for 'regular loads'
- yet having a static cache for partial loads would be handy too :-(

Agreed with catch's remark about invalid values and formatters - this should be changed also in list.module (not in this patch, but would be cool if someone created a separate task for that)

Regarding the infinite loop problem. One way to somehow solve this is build modes IMO. Say you do a field_attach_load on a node which loads the terms with a build mode of "minimal" or "as field" or "no attach" or something, which doesn't even trigger field_attach_load on the terms, while on a term view page, a term is loaded with a build mode of "full", which then triggers field_attach_load. This of course implies that a) the build mode overhaul patch gets in, b) build modes are properly supported not only by nodes but also by other entities and c) build modes are already passed to the _load_multiple functions (which currently call field_attach_load). Especially the latter could be a great improvement by its own (making loading and _load hooks build mode aware).

re Frando #19: build modes are currently of no help here because they're a *display time* property ('build') - and I think it should stay that way: node_load() loads full raw data, there's no variants. Once loaded, you might want to do different things with the object, including displaying it in several variants, but having several levels or flavors of 'load' would add much confusion IMO.

#409750: Overhaul and extend node build modes takes this a step further by removing the $node->build_mode property and extending/renaming the current (bool) $teaser param of node_view() and friends into (string) $build_mode param.

Is there somewhere in field api, after field_attach_load() where we can still have access to $objects - then we could have hook_field_attach_pre_render() or hook_field_attach_after_load() or something - do taxonomy_term_load_multiple() in there (not cached) - and this wouldn't call field_attach_load() on the referenced terms.

@catch: right now we don't.

Well, if I'm not mistaken, this makes it impossible to predict what can be found in $obj->taxo_field[0] : 'tid' ? 'tid' + 'term' ? And thus sprinkles uncertainty on the rest of the field lifetime.
+ I don't think that approach works if you try to separately load objects referencing the same terms in the same request (think : in a test). Static as hysteresis factor.

My proposal to 'Load only base properies' in #17 still stands, IMO.

If we only load base properties, while that's better than doing it in formatters, I can see a lot of formatters still having to do node_load() individually to get missing pieces. Opened #493314: Add multiple hook for formatters to discuss whether it's possible to have our cake and eat it too. Until that's resolved, I agree with yched that just a direct query to get $term->name and similar is the safest bet.

Because term_field_load() is going to be cached in the field cache (and in any fieldable entity which maintains a static cache during the request) I think we can drop the static and query building and just do a straight SELECT * FROM taxonomy_term_data WHERE tids IN (:tids); The 'multiple formatter hook' discussion suggests we'll need to keep that hunk of code even if it's implemented in a different hook eventually, which ought to work out pretty well. Will try to have a look at the tests later - IMO as long as we have roughly equivalent test coverage to the other field modules we're alright - a lot of taxonomy tests will need to be rewritten when converting the nodeapi stuff to fields in that issue - so no point doing the same work twice.

subscribe

+ * TODO access control?: I think this should be removed. access control for terms is not implemented in core. let contrib modules deal with it using form_alter and node_build_alter.

+ * Theme function for 'default' term field formatter. : this text is repeated even for the plain formatter.

Subscribing.

I'll do an in-depth/nit-pick review later, couple of quick (but big) things.

1. Why do we have to change options module? Is there a way we could add an alter hook there or something if it's going to be a general problem?

2. I still think this should be taxonomy.module providing the fields instead of a new module - once field conversion is done on taxonomy_nodeapi, taxonomy.module would be pretty much useless without this for 99% of Drupal sites - so it's just extra stuff to add to the modules page.

OK fields provided by individual modules - I guess the question is - would we add nodereference to node.module, probably we wouldn't. So I can live with a separate module.

I think we probably need a hook_field_widget_info_alter() - but that needs barry or yched to chime in - let's leave it as modifying options module for now.

We indeed need a hook_field_widget_info_alter() - more generally, we need a way to alter field_info, widget_info, formatter_info, and to alter corresponding settings form. 3 use cases in the latest 24 hours. I'll create an issue shortly.
Until then, we're left with changing options.module, but that's clearly not future proof. Contrib field types won't have that option.

I'd like to take a step back on the current approach:
a taxo field picks terms in one (or more ?) vocabularies, and several fields can possibly use the same vocabulary.
This means that the information previously stored in {term_node} is now scattered in several tables - possibly even several tables for a given vocabulary.

Similarly, semantics change from "node A has terms a, b, c" to "node A has term a in taxo field foo and terms a, b in taxo field bar"
Dumb example: vocab 'Rate', with terms 'good', 'average', 'poor'. Node type 'restaurant', with three taxo fields 'Food', 'Service', 'Price' using the same vocab.
The 'rating' flavor this example is intended: it's a semantic shift quite like the one from 'fivestar as a nodeapi module' to 'fivestar as CCK field', with terms instead of notation.

I have no real objection myself, just making sure everyone goes there willingly :-)

This raises a couple questions on taxonomy listing pages though:
- do we list all nodes that are tagged with the term in *any* field ? That's one query per field using the vocab - problem: with the field storage abstraction, sort and merge results have to be done in PHP and I'm not even sure pagination is solvable.
do we list all nodes that are tagged with the term in a given field, specified in the URL ?
- not just nodes can have taxo fields; but then how do we display taxo field values on a user object ? as a link to what ?
Looks like taxonomy/term/[tid] needs to become taxonomy/term/[field_name]/[obj_type]/[tid]

More generally: IMO it would be worth re-reading the discussion in http://groups.drupal.org/node/8793 - speculative 'taxo as field' discussion after the data API design sprint in winter 2008. I don't remember what the conclusion was back then (if any), and large parts of it are possibly stale now, but there might be good ideas or remarks.

@yched I agree with all these questions (not sure on the answers yet) - but I think they're more for #412518: Convert taxonomy_node_* related code to use field API + upgrade path. IMO we should focus on this issue as offering a 'term reference' field type which can be used orthogonally to the current taxonomy_node_*() integration. That lets you use terms with other entity types, and do stuff with views with the field, link the formatters to taxonomy/term/type/tid and stuff like that. Then we need to look at replacing taxonomy_node_*() integration in core to use that reference field, which is where all the really nasty, sticky issues are.

I really like where this patch is going. It demonstrates how powerful the Fields API is and is the direction we should go with how the Taxonomy is used on the node edit form. One concern I have, however, is that its an entirely separate module. I understand the argument that this is a CCK/FieldsAPI addition, but wouldn't it make sense to add it to the Taxonomy module itself since the Fields API is part of core now anyway? Maybe in a taxonomy.field.inc file?

This is a review for the patch at #44. Tests look nice. Just found some doxygen formatting issues. No spelling errors!

1. + * Implement hook_theme().
   

   Doxygen standards say it should be "Implements" -- found throughout patch.

2. Index: modules/taxonomy/term.test
   ===================================================================
   RCS file: modules/taxonomy/term.test
   diff -N modules/taxonomy/term.test
   --- /dev/null	1 Jan 1970 00:00:00 -0000
   +++ modules/taxonomy/term.test	3 Jul 2009 04:23:50 -0000
   @@ -0,0 +1,135 @@
   +<?php
   +// $Id$
   

   Missing Doxygen @file declaration

3. +    field_create_instance($this->instance);
   +    // Test valid and invalid values with field_attach_validate().
   +    $entity = field_test_create_stub_entity(0, 0, FIELD_TEST_BUNDLE);
   

   Readability: perhaps a whitespace line between comment and code?

Like I said, just a quick check of the spelling and code syntax.

Josh

@joshmiller: The current Drupal 7 coding standard for hook docblocks is "Implement hookname()." until we can decide on the best format (another patch out there).
See example http://api.drupal.org/api/search/7/_block

Here's a nitpick pass:

if (count($allowed_values) && !array_key_exists($item['value'], $allowed_values))
Seems like this could just be !isset($allowed_values[$item['value']]); ?

(string)$item['value']
I think the casting should be string $item - with the space, but have a feeling this is inconsistent in core as it currently is anyway.

+ *  TODO deal with excluded tids?
+ *  TODO support scope limiting to a particular subtree of the vocabulary
+ *  TODO support multiple subtrees of the same or different vocabularies in one field
+ *  TODO allow values that aren't in a vocabulary if the field/widget/vocabulary (which?) is for
+ *  tagging.
+ *  TODO the field settings could also enforce some constraints on the user's choosing behavior.
+ *  e.g. force user to choose a term with no children, etc.

While these are all potentially useful - they're not @TODO - this is broken, they're @TODO this might be nice, so I think we can remove them (but good to document in followup issues maybe).

+ * This preloads all taxonomy terms for a given object at once using taxonomy_term_load_multiple
+ * and unsets values for invalid terms which don't exist.

No longer users taxonomy_term_load_multiple() so that just needs removing from the docs.

I think the query should have
$query->addTag('term_access');
added to it - then it'll respect modules like tac lite.

+function _taxonomy_clean_field_cache($term) {

Needs some phpdoc - I defer to yched on field_attach_query() implementation but that looks good.

However

+        foreach ($ids as $id) {
+          cache_clear_all("field:$obj_type:$id", 'cache_field');
+        }

We can now pass an array of cache ids to cache_clear_all, so this could be

foreach ($ids as $id) {
  $cids[] = "field:$obj_type:id";
}
cache_clear_all($cids, 'cache_field');

then cache.inc will do DELETE FROM 'cache_field' WHERE cids IN ($cids); internally rather than a one-by-one delete.

+  // Test fields.

Not needed.

Term $term->tid doesn't
You can use t() for the assertions and therefore put $term->tid into a placeholder. Or you probably don't need to put the actual $term->tid into the assertion text - just "Term does not cause validation error" is usually enough.

Everything else looks great to me.

+function taxonomy_field_schema($field) {
+  switch ($field['type']) {
+    default:

Then we probably don't need a switch ;-)

function taxonomy_allowed_values($field) {

minor : it's related to the 'taxo field' part of the module, so maybe it should be named taxonomy_field_allowed_values() ?

+ * @return
+ *   array with 'term' object at that index
+ */
+function taxonomy_field_load($obj_type, $objects, $field, $instances, &$items, $age) {

Capitalization, trailing dot + the function doesn't return anything, actually ;-)

_taxonomy_clean_field_cache() is fine (once it uses the new 'multiple clear' mentioned by catch), but any other 'reference' field type will need similar code. Would be cool to abstract this into a generic function in field.module, as outlined in #111127-207: Cache node_load. At worst, could go in a followup patch, but we'll need it anyway at some point.
Also, note that there's a discussion pending in #367753: Bulk deletion to refactor field_attach_query() a bit, because currently it has the potential to completely blow PHP memory on large sites. Not something this specific patch should worry about for now, though.

The current code just lacks a check for 'is object type cacheable' before trying to clean the cache. Something like:

foreach ($objects as $obj_type => $ids) {
  $info = field_info_fieldable_types($obj_type);
  if ($info['cacheable']) {
  foreach ($ids as $id) {
    ...
  }

Actually, it might even be better to parse all object types for non-cacheable ones (in most cases there won't be any), then run field_attach_query() with a 'object_type NOT IN (non cacheable types)' condition.
The NOT IN operator in f_a_query() is currently not documented, but actually supported (I just created #511486: field_attach_query also supports 'NOT IN' to document it).

Other than that, as I wrote in #491196: CCK Field UI support for term fields: is it really a good idea to support 'taxo fields' spanning over several vocabs ? On 'object edit form', they will show up as one unique select widget merging terms from different vocabs, I'm not sure about this.

I'd like to be able to have an autocomplete on the node form, which allows assigning terms from combinations of different vocabularies. That way users think they're just tagging, but you get the convenience of multiple vocabularies for everything else (management, views, theming, etc.). However that doesn't need to be dealt with by this patch, at all.

The allowed values stuff seems to be commented out? If bangpound's approach with the extra array for allowed values works that seems like a good compromise to me - default to a field per vocabulary but leave things open for other uses.

+ * and unsets values for invalid terms which don't exist.
+ *

I keep getting told not to use abbreviations in code comments - also extra space here which isn't needed.

(count($tids)) 

!empty is enough there I think.

Multiple vids / parent terms in a field: the consequences are a bit over my head, but the approach looks sound.

_taxonomy_clean_field_cache(): OK, hard to abstract to a generic function because you're using extra logic specific to "taxonomy field allowed values" to avoid querying on fields that won't contain the tid anyway. Which is cool, I guess. We'll see about a generic function in a separate issue (when adressing 'text input format changed, clear text fields cache')

#512236: Design flaws in field_attach_query() got (partially) committed, and you updated the code to use FIELD_QUERY_NO_LIMIT. This won't fly in the long run (PHP memory explosion), but we can keep it until that issue settles.

if (count($cids)) could be just if ($cids), since $cids is initialized as an empty array anyway.

Other case for cache clear: when a vocab gets deleted :-(. We'll want to clear field cache for any object that uses a field referencing that vocab. No need to check for individual tids, it's ok if we delete 'too many' cache entries. But what we want to avoid is 'run _taxonomy_clean_field_cache($tid) on each $tid in the vocabulary' (PHP timeout pretty fast). We'd need to ensure that taxonomy's workflow on vocab deletion doesn't lead to this case.

Also re #55 "where do we document the field settings ?".
This is actually #464548: Document field types specifics (settings, columns...) - in short: there should be a PHPdoc block at the beginning of each field-type module that documents field, widget and formatters settings. I'm not familiar enough with PHPdoc conventions and how they translate to api.drupal.org to know precisely how it should be structured...

@bangpound: I think you can post the doc about the field settings in this patch's PHPdoc for taxonomy_field_info().
At least it will be somewhere where it can be picked up later :-)

This is looking great, minor stuff:

The new docs in taxonomy_field_info() look double indented?

+ *
+ * TODO figure out how to reverse the order of cacheable object type checking
+ * and the loading of the objects see #50

#50 where?

There's phpdoc for formatter tests, but no tests underneath, best to hide that away.

Nice work!

I looked at this and only found pretty minor stuff in my first pass. A few comments not conforming to standards, an extra /** and a missing /** here and there, and had a couple field API-related questions for bangpound and yched. Overall this looks really good. I'd like to play with it a bit to see if there are more substantiative comments, but overall I found the code pretty easy to follow.

I spent 10 minutes skimming this patch while at the airport. In short: I'm cool with it. It could use a more in-depth review, but it sounds like people have scrubbed it quite a bit already. It would be _really_ helpful if we could focus on the CCK UI -- that would make it easier to play around with patche like this. I think we should give that some priority (not in this patch).

Dries: see #516138: Move CCK HEAD in core - I'll be rolling an initial patch asap.

OK I read through this and couldn't find anything else to complain about. Additionally I applied this patch, #516138: Move CCK HEAD in core and c&ped http://github.com/benjamin-agaric/drupal-taxonomy-as-fields/raw/11ebd8b2... into taxonomy.module and was able to attach a term field to a user, which is wonderful.

There's going to be followup work required - this only gives us the 'term reference' field, it doesn't replace taxonomy_node_*() in any way (that's #412518: Convert taxonomy_node_* related code to use field API + upgrade path), but IMO this exactly what we need for the initial patch - any more would be too much to review properly - and it opens up a lot of other things as well (related terms and synonyms as a field? replacing profile autocomplete and keyword listings with a taxonomy field?) which don't rely on 412518.

Assuming #67 fixes everything webchick mentioned in #68, I think we're ready to go.

I actually sat down with CCK module and this patch to dink around with it rather than doing a straight-up code review, which I already did earlier. A couple of things were a little bit funny, but overall this patch is completely awesome!

My first problem was I had a bit of difficulty locating the new field type in the list:

We could chalk this up to me searching for the keyword "Taxonomy" and not finding it, or me expecting "Text" to be the short "T" word at the bottom and thus ignoring it, etc. But it tripped me up, and I figured I'd mention it.

Additionally, although with "Node" we mask everywhere as "Content", we do not (at least so far) do that with "Taxonomy." And while "Taxonomy" is visible in the admin panel, and "Vocabularies" can be visible if there are more than one taxonomy vocabulary attached to a content type, I don't think "Term" is something commonly associated with taxonomy to the average person (more apt would be "Category" which we don't use), and it's a "normal" English word that means something relating to definitions, so I'm not sure the mental model quite meshes.

It's also possible that I'm just really exhausted and this would not trip up anyone else, including me on a day where I had more than 4 hours of sleep. ;)

The second thing to trip me up is that autocomplete was not in the selection of widgets to choose from. This was particularly weird given that core *does* ship with a Tags vocabulary for just this purpose:

I talked to bangpound about this and he informed me that this was next on the list of things to do, but the initial pass was just for normal categories. Fair enough.

The interim settings screen further scrambled my brains on the naming:

And finally, it'd be nice if there were some smarts passed along from the vocabulary chosen to the field settings:

I also discovered you cannot delete fields from CCK Field UI. Whee!

Talking over with bangpound, most of these issues identified here are CCK things. Really the only thing that affects this patch are the names. Posting this review so we can talk about it more.

In talking with bangpound a bit more, it probably makes sense to go ahead with the names/labels as-is for now and see how the follow-up work shakes out and whether it makes sense to rename at that point.

I found a few more minor things reading through (for example testTermfieldWidgets -> testTermFieldWidgets), but I can fix them prior to commit.

I would love to commit this tonight, but my brains are about to leak out all over the floor courtesy of a splitting migraine. So I'll look at this mid-day tomorrow and, assuming no one else has freaked out over anything, do final touch-ups and commit it then. Thanks for your patience. This week is a little rough. :\

On naming, I think this'll be easier to do with CCK UI in core, and in followup patches, but I'd probably go for 'Taxonomy term' as the field name - it's provided by taxonomy module, and it's not a vocabulary - so it gives you a bit of a clue if you managed to find term fields before ever going to admin/build/taxonomy.

Completely agreed with bangpound on vocabulary settings - we want to cut that out of vocabulary creation and storage entirely, so they become just loose containers for terms - and all the help text/tags/multiple etc. is handled via the field UI. But all that happens in the other patch.

Subscribing........ Umm, nevermind, wrong issue.

sub

Just a note that I discussed this issue with Dries over dinner the other night, but he said he wanted another crack at it before committing.

Follow-up issues:

#526122: Autocomplete widget for taxonomy term fields
#526120: Remove related terms from core now that terms can have a term reference field
#412518: Convert taxonomy_node_* related code to use field API + upgrade path
Also this is likely to be useful for the 'list users with this profile field' component of #394720: Migrate profile module data to field API.

My laptop isn't fixed yet, but I had a chance to look into this:

1. Why is field_formatter_taxonomy_term_default called field_formatter_taxonomy_term_default and not field_formatter_taxonomy_term_link?

2. The documentation of taxonomy_field_load mentions there being one object but it actually takes multiple objects.

3. taxonomy_field_load needs some code comments, IMO.

4. I expected taxonomy_field_widget_info_alter to be unnecessary and these things to be adjusted automatically but maybe I'm not 100% speed on that part yet. I'd need to dig a bit deeper into the code, or the documentation could be a bit more explicit/verbose about what is going on.

5. t("Test the creation of term fields.") should use single quotes.

Committed to CVS HEAD.

This needs a CHANGELOG.txt entry, IMO.

I'd also like to see a list of follow-up issues.

Followups:
#526122: Autocomplete widget for taxonomy term fields
#526120: Remove related terms from core now that terms can have a term reference field
#412518: Convert taxonomy_node_* related code to use field API + upgrade path
#538256: Use a text field for taxonomy term synonyms

Committed #90 to HEAD. Thanks!