Taxonomy handling?

hey highvoltage --

It would be great if you could tell me a little more about what you need to do...

We've had some ideas in the past about how to best do this. My current idea is to have a setting per vocabulary like "Allow this vocabulary to set context", and then provide terms from that vocabulary as options on the context builder form. It would then set that context whenever you were viewing a node with that tag.

Any other needs you're seeing?

Could you tell me more about what will be generating the term-based node listing page (site.com/vocabulary/term)? This would fall outside of the case I've outlined above, but it is definitely possible to write a little bit of custom code to handle this case depending on how you are generating the page.

For example, if this is a View you can add some PHP code to the argument handler to set the context manually:

<?php
context_set('context_ui', 'section', 'mysection'); // where these 3 arguments are the namespace, attribute, value of your context
?>

You could also write a small implementation of hook_views_pre_build() that detects when a view has a taxonomy term argument handler and sets the context if it does.

taxonomy support as described in #1 would be very useful in my case.

Here is a simple module I made that allows vocabularies to be enabled for context.
once enabled, checkboxes for the terms in the selected vocabulary will be available to set contexts within context_ui

it seems to be working for my purposes.
hope you find it useful

Hi everyone

Is it worth me reviewing this patch for DRUPAL-6--1 when new development is happening for the new API in DRUPAL-6--2 ?

I can see for example that the API has changed a lot. Now using conditions and reactions as opposed to setters hooks?

Here's the same module updated for API DRUPAL-6--2. I removed the vocab form setting (i.e. choosing whether a vocab is seen by the context module), because it seems unnecessary... ? Bit confusing when no vocabs appear and you have to go and enable them all one-by-one. Do you have a use case for hiding them?

Anyway, it works nicely. I named it context_taxonomy to avoid clash with content_terms.

But now, here's my use case. I need to set a context to only activate when two or more terms are selected. So I imagine the UI I need would allow me to select a number of terms to be AND-ed together and form one condition.

I imagine this is not possible at the moment. Any ideas for implementing?

Here's what I've got working:

1) Add in another taxonomy condition, called "Taxonomy: AND".
2) This condition has all taxonomy terms together as it's checkboxes.
3) You then check the ones you want to be ANDed together and form a condition.
4) In nodeapi() we load the condition map and check that the node has all the required terms before setting the context.

Quite simple like this.

re #8
I originally did not have the feature to enable the vocab or Context UI.
The reason that I added it per vocab was:

1. sites may have several vocabs, some that shouldn't define a context and I didn't want all the tabs in the UI
2. if a vocab (that dosen't need to define context) has thousands of terms the list in that little, scrolling div is really long and hard to manage. I also found that with really large vocabs, jquery was freezing the browser on the UI screen, at times. (but that my have just been my drupal installation)

I've been using the mod posted in #6 for a few months now with no problems for my limited purpose.
your ANDing condition sounds useful, I'll give it a spin when i have some time in the near future.

- loze

Ok sure thing, understand the reasoning. Can we make it ON by default? That way you can switch off the ones that slow down your site, but then most people don't have to enable them one by one.

I have done this in the new version attached. And I've added the new Multiple Terms condition which triggers the context only if the node is tagged with ALL the terms that are selected.

I've also cleaned up the code and added comments.

Still working with version 2 here.

Looking forward to comments, etc!

I actually needed to accomplish what yhahn proposed in #1 on a limited basis. Below is the code I put in a random module.

/**
 *  Implementation of hook_init();
 */
function [module]_init() {
  // Setting context based on one of four term ids for every page
  // In this case, I have one vocab that has a limited number
  // of terms. That vocab can only have one term
  // selected at a time. In other circumstances it would be
  // possible to determine which $tid is weighted higher and set
  // context based on that. Or you might just set context based
  // on available vocabulary ids.
  if (module_exists('context')) {

    // Find the correct term id
    $currentnode = menu_get_object(); // pull node without using the expensive node_load()
    $tid = NULL;
    if (!empty($currentnode->taxonomy)) { // confirm taxonomy exists
      foreach ($currentnode->taxonomy as $term) {
        if ($term->vid == 1) { // separate by vocab id
          $tid = $term->tid; 
          break; // avoid processing high volume of  tags if I found what I needed
        }
      }
    }

    // Set context based on current tid
    switch ($tid) {
      case 1: // Economic Development
        context_set('glc', 'section', 'economic');
        break;
      case 2: // Downtown
        context_set('glc', 'section', 'downtown');
        break;
      case 3: // Chamber of Commerce
        context_set('glc', 'section', 'chamber');
        break;
      default:
        context_set('glc', 'section', 'home');
        break;
    }
  } // End Context Setting by $tid
}

EDIT: I fixed some of the code that wasn't working.

SECOND EDIT: After a day of trying to make this work, I came to the conclusion that what I'm trying to accomplish HAS to be a module for the context_set() function to be called early enough to make a difference. I can confirm this code DOES work.

To keep everyone updated -- I took a look at this tonight and it looks good! However, I am a little hesitant to commit right away given that:

• This is by far the most complex condition
• I would like to make the term handling ("ALL" vs "one of") a setting or so
• The added complexity of condition settings really begs for a more complex condition/reaction architecture (think ctools/views handlers... but that has always seemed like overkill to me)

Given that I think everyone would like a stable release of context soon, what are your thoughts? Could this be a separate project/module for the time being?

See the blog post at computer minds http://www.computerminds.co.uk/extending-drupal-context-module-allow-con...

Did they do all of the heavy lifting for you yhahn?

Attached is Computer Minds' code.

Josh

Thanks for cross posting this Josh - my origional plan was to add this code as a patch to the context_devel module, but I think it may well end up turning into a module in it's own right as I would like to add support for the taxonomy/term/XX pages - as well as any views that utilise a taxonomy term argument ... just need to find a bit of free time :)

Closing here -- would love to see this as an add-on contrib module given that taxonomy conditions can often be very different depending on the particular use case.

I have to say, I expected *some* version of this in context_ui ... More complex rulesets could borrow a UI from Rules module?

I agree, since a part of Context module is to set conditions, there's something to share with Conditional Actions and Rules here...

You can also use spaces_taxonomy (which is packed with spaces).

Subscribing

#15 works like a charm, only feedback would be. We have a HUGE taxonomy database, would be nice if before it returned ALL terms, you were able to select a vocab, and just use that one.