Free tagging taxonomy and taxonomy vocabularies as a condition

I think this would be a nice feature, postponing for post-stable.

I needed this functionality and cannot find any not ugly solution so here is some code on the subject.
A condition for selecting node vocabularies.
Two respective conditions for taxonomy term pages.
And i've renamed the 'Node taxonomy' condition to 'Node taxonomy term', so it makes sense as a whole.

First i wanted to implement these 4 conditions to have only 2 (terms and vocabularies), but i was not able to come up with a good form element widget and options form seemed to me as for some other purposes.

I need exactly that, I was surprised that the superpowerfull Context doesn't know how to handle vocabularies. Taxonomy terms are always changing on the live sites, Vocabularies usually stays same.

At least taxonomy vocabulary context is very needed feature!

Works fine for me. RTBC

@wapnik Thanks and greetings from Prague ;-)

patch did not apply cleanly on windows using netbeans "apply dif patch"
(using these instructions http://drupal.org/node/60179)

realized
context_condition_node_taxonomy.inc
is not erased (not really important that it should)

following are not created in plugins folder
context_condition_node_taxonomy_term.inc
context_condition_node_taxonomy_vocabulary.inc
context_condition_page_taxonomy_term_term.inc
context_condition_page_taxonomy_term_vocabulary.inc

context_condition_node_taxonomy_term.inc
is not created at all

here is a patch that tries to create new .inc files in plugins folder

not changing status because patch modification is minor
and logic of previous patch still work as expected

subscribing, a needed feature

@kika
to help this issue get resolved
apply patch and describe if it worked for you

Tested a context that uses the "Taxonomy term page by vocabulary" condition and it works great. Just what I was looking for. +1

This needs review of the patch in comment #4.

First round - node taxonomy conditions, against 7.x + fixed execute on node forms.

Second round - term page conditions added, #1094840: Condition Taxonomy Term only works on terms with description fixed, patch from #9 included.

subscribing: taxonomy-term support would be really nice to have, thanks for working on this :)

I can confirm the patch in #10 works for me. Thanks a bunch!

subscribing

Here is the same patch as #10 with some spacing fix ( 4 trailing spaces and 4 string concatenation spaces ).

I believed this would solve a related issue but it didn't ( http://drupal.org/node/1094840 ). Maybe i did something wrong because adding description to terms doesn't help.

Just a question, since this issue was changed from 6.x to 7.x in #9 above, does that mean that this patch has already been implemented for Drupal 6? Thanks.

#15: it's just that patches are always created against the dev version and then backported if possible

#16: it's just that no maintainer seems to show any interest :)

A few issues with this patch.

#1 It does not address the upgrade path, so anyone with the original context node_taxonomy which is renamed to node_taxonomy_vocabulary will lose their configs, so we need to either not rename that one, or provide a way to rename all of the context configs already in a system. It probably needs to handle exported contexts too by renaming and moving to the DB

#2 I'm not sure it handles the node_taxonomy_term plugin correctly. It is checking for $vocabulary->tags to see if the vocabular is a free tagging vocabulary, but that is no longer how you check for that. The tags flag has gone away. You now (I think) need to check each and every taxonomy term reference field to see if it's cardinality is not 1 for the given vocab. Unless someone knows a better way. But maybe the question is, does it matter if it is a free tag vocab or not?

@febbraro #1 What do you think, what makes more sense here?

I have a D6 project using the original patch in #4. I updated its logic to handle machine names for vocabularies, so that vocabulary-based conditions at least should be exportable in Features. I wouldn't swear this is the best approach, and I don't have time now to apply it to the 7.x-3.x patch under development -- but if anyone else has the inclination to port it over, please have at it. Otherwise I will circle back later and roll a 7.x-3.x patch when I get a chance. This patch is against 6.x-3.x.