Taxonomy: Term argument selection rules are broken

Why did you close this? It sounds legitimate to me?

Actually I think I stumbled on something useful related to this:

Adding a "Context: Taxonomy Term" WORKS! in the Page Manager for D7.
BUT, you need to press "Update & Save" for each one you want to add, or you'll see "Invalid Context Type" error instead.
The page editor pulls up the CORRECT data and fields surrounding the term, AND properly displays them to the end-user.

Just for the sake of peeking at the output, I've attached the page I tested this under. Hopefully, this can be of use to someone.

@Apfel007 -- I wasn't trying to show that Taxonomy: Term selection rules are working. Rather, I found that adding "Taxonomy: Term" as a context to the Panel is working. AFAIK in CTools, the functionality is related--and thought it may help debug this.

I hacked the Ctools suite for a moment, just to take a peek at what's inside the context that's blowing up.
Here's what I found:

ctools_context Object
(
    [type] => Array
        (
            [0] => entity:taxonomy_term
            [1] => entity
            [2] => taxonomy_term
        )

    [data] => 
    [title] => Unknown context
    [page_title] => 
    [identifier] => Term(s) being viewed
    [argument] => 
    [keyword] => taxonomy_term
    [original_argument] => 
    [restrictions] => Array
        (
            [type] => Array
                (
                    [0] => menu
                )

        )

    [empty] => 1
    [plugin] => entity:taxonomy_term
    [id] => argument_entity_id:taxonomy_term_1
    [placeholder] => Array
        (
            [type] => argument
            [conf] => Array
                (
                    [keyword] => taxonomy_term
                    [identifier] => Term(s) being viewed
                    [id] => 1
                    [name] => entity_id:taxonomy_term
                    [default] => 404
                    [input_form] => tid
                    [breadcrumb] => 1
                )

        )

)

I also noticed the theme layer bugs out when I try to use this selection rule.
I'm not quite sure this is deeply related, but once again, hope that it can help debug this problem.

This is odd--if I turn javascript off, more than one "Selection Rules" item is made available in the "Add Variant" display. Obviously, the page manager tool doesn't work without JS, but again...trying to see if this is somehow distantly related.

EDIT: Probably not. Drupal6 version does the same thing.

After a little more hacking around ctools_term_ctools_access_summary(),
I discovered the $terms array populated on line 144 of "ctools/plugins/access/term.inc" is set, but not filled.
As far as I can find, Drupal core isn't loading the term as expected. Although taxonomy_term_load appears in the access plugin, it never seems to be run.

The taxonomy_term_load() call occurring in the Access summary was intended for Drupal 6. In Drupal 7, loading a vocabulary doesn't pre-populate a list of associated terms. I don't know if its a bug, or an intended design feature, but its definitely holding this back. As I looked into this, Drupal 7 recommends using EntityFieldQuery to load most things from the database, and might prove to be just the solution we need.

Here's what I've started on, although I don't totally understand the EntityFieldQuery design yet.
This will retrieve taxonomy terms by vocabulary id. Why this isn't in the core taxonomy module as a function is beyond me...

$result = $fieldQuery
      ->entityCondition('entity_type','taxonomy_term')
      ->propertyCondition('vid', $vocab->vid, '=')
      ->propertyOrderBy('name','ASC')
      ->execute();

Once I figure out what needs to be pulled and how to write it properly, I'll post more. Would really like to hear more from the Ctools team on whether or not this is the right way to go.

Alright, I at least got it to populate the value--not necessarily with the exact data we want yet--but its on (the right?) track.
The selection rule still doesn't work.

Here's what I've modified thus far. Its probably the wrong place the run this fieldquery, but it at least feels like I'm headed in the right direction.
ctools/plugins/access/term.inc
I replaced contents of ctools_term_ctools_access_summary($conf, $context) with the following:

$vocab = taxonomy_vocabulary_load($conf['vid']);

  if ($vocab->tags) {
    $terms = explode(', ', $conf[$vocab->vid]);
  }
  else {
    $terms = array();
    $fieldQuery = new EntityFieldQuery();
    $result = $fieldQuery
      ->entityCondition('entity_type','taxonomy_term')
      ->propertyCondition('vid', $vocab->vid, '=')
      ->propertyOrderBy('name','ASC')
      ->execute();
      
    $terms = taxonomy_term_load_multiple(array_keys($result['taxonomy_term']));
  }
  $options = array();
  foreach ($terms as $t) {
    $options[] = $t->name;
  }

  return format_plural(count($terms),
    '@term can be the term "@terms"',
    '@term can be one of these terms: @terms',
    array('@terms' => implode(', ', $options),
      '@term' => $context->identifier));

I haven't quite figured out how to determine only the exact term the user selected, but this shouldn't be too far off.
What's really strange is that "tid" can't be selected as part of the entity for "taxonomy_term", or the query breaks. As far as I've learned,

$result = $fieldQuery
      ->entityCondition('entity_type','taxonomy_term')
      ->propertyCondition('tid', $context->argument, '=')
      ->propertyCondition('vid', $vocab->vid, '=')
      ->propertyOrderBy('name','ASC')
      ->execute();

should select the term we're after, but it doesn't work....not to mention the context argument keeps coming through empty.

Ok, it looks like EntityFieldQuery doesn't return anything if you target exactly one result.
Why, I'm not sure. At this point, I'm stumped.

Edit:
Continued to explore how the context is generated.
Looks like the method bodies in ctools/plugins/contexts/term.inc need to be updated -- although I'll admit, I'm not fully familiar with how the Selection Rule context is created in the page manager.

Any help or discussion regarding how to fix this would be greatly appreciated. I'm even considering offering a bounty to get it fixed faster.

Found a workaround.

Instead of using the selection rule "Taxonomy: term", use "Taxonomy: term bundle". It's not as specific, but you can at least gain some control of the taxonomy term pages.

Finally, got somewhere with this. Would like feedback from some of the CTools devs on this.

So far, I replaced some content of Ctools/plugins/access/ folder, open term.inc
Replace:

/**
 * Provide a summary description based upon the checked terms.
 */
function ctools_term_ctools_access_summary($conf, $context) {
  $vocab = taxonomy_vocabulary_load($conf['vid']);
  if ($vocab->tags) {
    $terms = explode(', ', $conf[$vocab->vid]);
  }
  else {
    $terms = array();
    foreach ($conf[$vocab->vid] as $tid) {
      $term = taxonomy_term_load($tid);
      $terms[] = $term->name;
    }
  }

  return format_plural(count($terms),
    '@term can be the term "@terms"',
    '@term can be one of these terms: @terms',
    array('@terms' => implode(', ', $terms),
      '@term' => $context->identifier));
}

With this:

function ctools_term_ctools_access_summary($conf, $context) {
  $vid = (int)$conf['vid'];
  $terms = array();
  foreach ($conf[$vid] as $tid) {
    $term = taxonomy_term_load($tid);
    $terms[] = $term->name;
  }

  return format_plural(count($terms),
    '@term can be the term "@terms"',
    '@term can be one of these terms: @terms',
    array('@terms' => implode(', ', $terms),
      '@term' => $context->identifier));
}

This should populate the summary correctly now, BUT because $conf doesn't contain the right selection information from the access settings, nothing will show up.

Getting closer yet. I now have the access check working. As far as I understand the Ctools library, only ONE term is processed in a check at a time. Again, if I'm wrong, I'd like to get some feedback.

In the same file replace the contents of ctools_term_ctools_access_check($conf, $context)
Replace this:

/**
 * Check for access.
 */
function ctools_term_ctools_access_check($conf, $context) {
  // As far as I know there should always be a context at this point, but this
  // is safe.
  if (empty($context) || empty($context->data) || empty($context->data->vid) || empty($context->data->tid)) {
    return FALSE;
  }

  // Get the $vid.
  if (!isset($conf['vid'])) {
    return FALSE;
  }
  $vid = $conf['vid'];

  // Get the terms.
  if (!isset($conf[$vid])) {
    return FALSE;
  }

  $return = FALSE;
  // Tags get saved as an imploded array of strings.
  if (!is_array($conf[$vid])) {
    $terms = explode(', ', $conf[$vid]);
    // For multi-term with names, we'll only accept the first term because
    // that is the name we have.
    return in_array($context->data->name, $terms);
  }
  else {
    $terms = array_filter($conf[$vid]);
    // For multi-term if any terms coincide, let's call that good enough:
    if (isset($context->tids)) {
      return (bool) array_intersect($terms, $context->tids);
    }
    else {
      return in_array($context->data->tid, $terms);
    }
  }
}

With this:

/**
 * Check for access.
 */
function ctools_term_ctools_access_check($conf, $context) {
  // As far as I know there should always be a context at this point, but this
  // is safe.
  if (empty($context) || empty($context->data) || empty($context->data->vid) || empty($context->data->tid)) {
    return FALSE;
  }

  // Get the $vid.
  if (!isset($conf['vid'])) {
    return FALSE;
  }
  $vid = (int)$conf['vid'];
  // Get the terms.
  if (!isset($conf[$vid])) {
    return FALSE;
  }
  
  // For multi-term if any terms coincide, let's call that good enough:
  if (isset($context->tids)) {
    return (bool) array_intersect($conf[$vid], $context->tids);
  }
  else {
    // Look through the vocabulary and see if the term sent to us is in it.
    foreach ($conf[$vid] as $tid) {
      if ($tid == $context->data->tid) {
        return TRUE;
      }
    }
    // We didn't find the TID in the list of terms
    return FALSE;
  }
}

EDIT: I cleaned this up, so that terms don't need to be loaded from the database. This should dramatically improve access speed.

Found the data that's needed, but I don't know where it needs to be populated. $conf isn't retaining the Term ID selection values as expected.

---
It also looks like something is overwriting or re-writing the term selection field. The #multiple option is set for term selection, but not added/processed into the actual form HTML.

---
Also discovered that, even if a function is defined ctools_term_ctools_access_settings_validate() is never called--although its specified in the Access plugin. Oddly enough, ctools_term_ctools_access_settings_submit() does get called.

$plugin = array(
  'title' => t("Taxonomy: term"),
...
  'settings form' => 'ctools_term_ctools_access_settings',
  'settings form validation' => 'ctools_term_ctools_access_settings_validate',
  'settings form submit' => 'ctools_term_ctools_access_settings_submit',
...
);

Here's my updated Term Access "term.inc" file for CTools.
NOTE: This isn't a patch, as I don't know what's best now that everything is in "git", so this is just the altered file.

It looks like the attribute "#multiple" in Drupal Core (or something in between) isn't generating the multiple attribute for "select" inputs on forms, and I'm using a naming workaround until the "Term selection" select field name is generated correctly.

Look for '#name' => sprintf("settings[$vid][]"), (Should be line 69) in ctools_term_ctools_access_settings.

EDIT:
Oops, line 69 should be '#name' => sprintf("settings[%u][]", $vid),.

And for one last edit:
to make "select multiple" work in Drupal 7, you have to use the "attributes" array for the "select" element. Why, I don't know. (see: http://drupal.org/node/1117526 for more info).
Just add '#attributes' => array('multiple' => 'multiple'), after line 68 '#name' => sprintf("settings[%u][]", $vid), and it'll work like a charm.

Here's a patch file. I don't know if it will play nice on git.

This will handle vocabularies with no hierarchy, like..."tags"...if and when the vocabulary is both Flat, and contains more than 50 terms. I would really like feedback on whether or not this is an appropriate solution.

I tried your modified file for "term.inc" in #21 and it worked great! That fixed the problem with the taxonomy term not being picked out in the selection rules. I stumbled into this problem and got the "Notice error" defined above when I added a variant for the taxonomy page defined in panels. I also added the " '#attributes' => array('multiple' => 'multiple'), " after line 68 and yeah, sure enough I can pick multiple terms now.
Great! is that the fix then?

Glad to hear its working for more than just me!

To answer your question: yes.
Working with selects that accept multiple arguments is solved with the workaround as described above.
I've submitted a patch to fix it, but the review cycle is finnicky (and I'm not fully acclimated to git).

Once that issue is solved and Drupal 7.1 is out, I'll submit a patch to remove my workarounds.

Since you said you encountered a "Notice", would you mind posting its contents here?

Your patch isn't against the latest -dev and doesn't apply.

I've struggled with this one, trying to understand it, and I think I've got a handle on it. The problem here is essentially that we no longer actually can tell if a vocabulary uses tags or not, and we need to make the decision intelligently. I think that makes sense.

1) There's a couple of code style issues in your patch; when you update to latest -dev, please address them. Notably, proper spacing around operators and between function arguments. I'm nitpicky about that.

2) sprintf() seems silly when we can just use "settings[$vid][]" I think. sprintf() is very slow and should be avoided.

3) The #size comment may not be true anymore. Check that out, I suspect removing the #size is ok.

4) Variable names should separate words with underscores. Use $term_count instead of $termcount

The only alternative solution I can think of is attempting to use the formatter. I suspect that will be complicated and failure prone, so we can probably stick with the solution you've got here.

If you can get a reroll while I'm still on a CTools phase that will increase the likelihood of this getting in soon.

1,2,4) No problem. Will fix.

3) A) I put "#size" on the autocomplete because it kept defaulting to 10 characters, which is virtually unusable.
Is 50 terms an acceptable trigger-point to choose between an autocomplete and select field?
EDIT: In retrospect, I could just take out the autocomplete altogether and work on putting it back in later. At this point I think more people would be willing to work without it so long as the access feature is working. Working from the latest Drupal-dev, CTools-dev it looks like the taxonomy autocomplete path is generating HTTP/1.1 500 errors, too.

3) B) If you're referring to the Select field's '#size', I wanted to prevent it from getting extensively long when large vocabularies are present.

I'm a bit limited this evening, but I might be able to get something in either late tonight or late tomorrow afternoon.

This patch takes out the autocomplete until I can figure out how to use it/what needs to be fixed.
I removed the #size setting as well.

I see a mistyped character in the Add file path. Remove the beginning W.

The above monologue is completely over my head, but I'm happy to say that the patch (#22) got rid of the problems I was having while adding rules in panels based on taxonomy terms.

Many thanks.

I was referring to the Notice error I got when trying to add taxonomy terms in my selection rules:
Notice: Undefined property: stdClass::$tags in ctools_term_ctools_access_summary() (line 136 of /var/www/html/cfam/drupal/sites/all/modules/ctools/plugins/access/term.inc).

Applied the changes in #28 and I don't get the Notice error anymore and I can add the taxonomy terms in selection rules.

Have this problem too. Subscribe.

Update:
========
Sadly not working for me.
Successfully applied patch from #28 to term.inc.
Uploaded to server.

But when attempting to edit Selection Rules, keep getting WSOD.

So reverted to original term.inc for now.

Thanks.

WSOD? Please list the exact versions of CTools and Views you're using. Is it hanging indefinitely before going to a WSOD?

Hi,

Chaos Tools 7.x-1.0-alpha4
Views 7.x-3.0-beta3

The only other info I can give is that the URL is different before and after the patch.

Before the patch, the link displayed on the manage Selection Rules page is
http:/mydomain.org/test/#overlay=admin/structure/pages/nojs/operation/node_view/handlers/node_view_panel_context_2/criteria

After the patch, the link displayed during the WSOD is
http:/mydomain.org/test/_ _ _ _ admin/structure/pages/nojs/operation/node_view/handlers/node_view_panel_context_2/criteria

Notice that the string referring to the overlay (marked by several underscores above) is missing. Perhaps this could give a clue as to when the system freezes?

There is little lag time from the clicking of the "edit" link to the actual WSOD... maybe one second or so.

If something else comes to mind, I'll add it soonest.

Thanks

Did you turn the overlay module off? CTools' Page Manager interface has a built-in AJAX modal kit, so /#overlay shouldn't be the case. I added the patch to CTools-dev. It's possible Alpha4 still had a latent bug regarding the Drupal7 Overlay module.

The lag time you're experiencing should be the time needed to process the AJAX request and load taxonomy terms into select fields. I was really looking to find out if it was significantly slow, but it doesn't sound like it.

I didn't modify anything that impacts the CTools AJAX modal or links to it, so -alpha4 ismost likely the culprit. I would try updating CTools to -dev, flush your caches twice, and run update.php.

Okay great: update to -dev branch, flush caches twice, run update. Got it, thanks and cheers!

Patch not applying cleanly to latest dev. After updating the path names from \ to /, I can get hunk #3 to apply.

I tried re-rolling the patch from #28 against the latest -dev. It's attached.
I was able to successfully apply it, but I'm not sure that it's fixing the issue that's outlined above.

To make sure I understand the process to recreate the error:
-Have a content type that is associated with a vocabulary that contains terms
-Create a variant of the "Taxonomy term template"
-Attempt to add a selection rule of Taxonomy: term

When I attempted to do this, I got an error message "An illegal choice has been detected. Please contact the site administrator" and was unable to add the selection rule. I've attached a screenshot of the error.

An Illegal choice error should be a temporary side-effect of correcting the way values are handled. Flush your cache first, update the selection criteria, and save the page. If it comes back, remove the selection criteria and add it back. If it comes back after that, then post any other errors you might catch here.

Thanks for the re-roll.

@wjaspers

I've tried flushing the cache (twice just in case) and tried to add the selection criteria again. Same error. Tried clicking 'update' and 'update and save' on the selection rules before adding taxonomy: term criteria just in case - still get the error.

Note: I've never been able to successfully add the selection criteria, so I can't remove it.

Odd. I don't see ctools_include('dependent') in the re-roll.
My install seems to work ok without it--although I left it in since there was no documentation as to whether or not it was still necessary. Is there a specific reason you removed it?
Duhh, it was in the term.inc to begin with--so it didn't show up in the patches....

I just loaded the latest (APR 28) CTools-dev and copied the patched file over--works just fine for me. I can add/remove selection criteria just fine.

Are you trying to use this against the default "taxonomy/term/%term" page or a customized one? Are you using any other Drupal7 modules that affect Taxonomy?

Sorry - the re-roll was based on #28, and I don't think I see ctools_include('dependent') in that patch.

I can add/remove most selection criteria - just not taxonomy:term

I am using the default /taxonomy/term/%taxonomy_term page

It looks like ctools_include('dependent') was already part of the latest -dev

What are your exact versions of Drupal Core, CTools and Views? I tried replicating this problem with the Overlay module (to get closer to your screenshot) on/off with no effect.

Are you sure when you rolled the patch you didn't wind up with a file: b/term.inc instead of updating the term.inc file in CTools/plugins/access? Dumb question -- but I figure its worth double-checking.

It also looks like I may have accidentally put $form['settings']['vid']['#options'] = $options; on the wrong side of the closing curly brace for the foreach(taxonomy_get_vocabularies(). Try moving it out, flush, and try the selection rules again.

Alrighty - just to make absolutely sure I didn't have a strange interaction going on I completely wiped my test db and started from scratch. Using the following versions:

Drupal core: 7.x-dev from 2011-05-01
Ctools: 7.x-1.x-dev from 2011-04-29 with the patch from above but with the $form['settings']['vid']['#options'] = $options; moved outside of the foreach loop.
Panels: 7.x-3.x-dev from 2011-04-20
Views: 7.x-3.x-dev from 2011-05-02

I didn't install anything until after applying the patch which I then confirmed had modified the term.inc file.
So - there shouldn't be anything to clear in the cache, but I did it twice anyway just in case.

And I am sadly getting the exact same error I had before.

Attaching the updated patch -

It is also worth mentioning that this error only occurs when I try to select a specific term within a vocabulary. If no terms are selected within the 'Terms' listbox, the selection criteria saves without error.

I just whipped up a test instance with the same versions to yours and I still don't get that error. I stand by #28 with the $form['settings']['vid']['#options'] = $options; moved out of the foreach.

Did you do a minimal or standard install?

I did a standard install using the patch I attached in my last comment.

Just to double-check, are you selecting a specific taxonomy term under selection criteria? And what settings are you using in that vocabulary?

I see what's happening. It looks like the latest Drupal Core -dev fixed the '#multiple' issue (not quite in the manner I expected, but it works correctly now) as stated WAYYY back in this thread. For some reason the latest core tarball worked correctly, whereas the latest ZIP was different (see my comments earlier today). Remove my workarounds and everything should be hunky-dory. Give this term.inc a try. Clean and simple.

That completely eliminated the error. Yay! So - I guess the question would be what will you commit? If your previous version works in the current official version of Drupal core, but you know that this last version is going to be needed for the -dev version and future versions?

I would commit #49 (as if patched). Since Drupal Core appears to have fixed our #multiple issue, I would think it best to plan without a workaround. Each time you update CTools until D7.1, you'll need to copy term.inc back on top of ctools/plugins/access.

It's a minor pain to repeatedly replace the file, but honestly, I'd kind of expect that from using -dev code.

This is a new patch against the latest -dev of ctools with the changes from #49. (Running -dev of Drupal core). Retested with tagging and non-tagging vocabularies, multiple and single selections.

I thought one of the purposes here was to protect us from massive tagging vocabularies? The initial patch did a count test, but this one just makes everything a select? I still would rather have an auto complete on large vocabularies because there are sites out there with tens of thousands of terms in tagging vocabularies.

Thinking about this some more, it might be best to use the ctools_dependent() function to let the admin choose if they want a select or an autocomplete to choose terms. Since it's impossible to tell which vocabularies are used which way, it might be best treated as such where it's used.

A) Does ctools_dependent() load sub-values via AJAX or are they just hidden from the display?
B) I never figured out what an acceptable term limit it before switching from a select to an autocomplete. 50 seemed reasonable.... Are there any other suggestions?
C) Core -dev taxonomy AJAX responses were acting crazy when I intially tried adding the autocomplete, so I had removed it for the time being.

They are simply hidden from the display, so dependent wouldn't actually work in this case. We would likely need to use #ajax, which is going to be particularly tricky with this kind of a form. We could use a multi-step form, like how entity_field works -- you select the formatter to use on the first step and then configure the formatter on the second. It's not quite as nice of a UI as #ajax, but as I said, #ajax is very tricky with these complex forms.

Subscribing

@merlinofchaos I finally got around to reading up on the term autocomplete strategy, the outlook isn't quite what I expected.

As it turns out, autocompletes for Taxonomy terms only respond to field'ed entities...at this point I don't see any easy way to include a term Autocomplete in the term plugin. The only way around this I see (so far), is to register our own term autocomplete path and validation call.
Unless anyone's seen code that shows the best way to accomplish this, I think we're at a temporary stalemate. Perhaps we could push for a secondary autocomplete path and validation in the core Taxonomy module?

Just out of curiosity,

To anyone else reading this thread, what's the largest Vocabulary (in number of terms) you have encountered?

P.S. Just for documentation's sake: the multiple issue (http://drupal.org/node/1117526) as I thought was gone in 7x-dev, resurfaced in 7.2.

As of right now, the issue queue tags vocabulary has 12,704 terms in it. I got killes to run a quick count query.

For reference, I opened a Core Issue regarding how the Taxonomy autocomplete works. I think it just needs to be de-coupled from the field implementation to make it modular again. http://drupal.org/node/1169964

joachim has written a patch (http://drupal.org/node/1169964#comment-4699520) which should open this functionality back up.
Until it's officially in D7, we'll have to wait.

Related bug for parent term #1309282: Plugin broken: Typo in term_parent - no parent from relation

Rule is broken too #1274066: Selection rule "Term has parent(s)" gives error if selecting something

$taxonomy->hierarchy could be used to chose autocomplete for plain vocabs
but there's no autocomplete for taxonomy in core so ctools need to implement one.

Also we can improve settings form like #1274066: Selection rule "Term has parent(s)" gives error if selecting something