Invalid argument supplied for foreach() in term.inc

I agree with the above synopsis Panels needs to provide an interface to specify the vocabulary that the term is to come from in the argument form. That interface needs to populate the $conf['vids'] variable in ctools.

The proper way to fix this is probably to split the argument into two separate arguments, since specific config options are unwieldy. We also need more stuff like Views has where you can use taxonomy synonyms as arguments.

Marked #551084: Same term in two taxonomies causes error in term.inc line 50 as a duplicate of this issue. The bug still exists in the 3.0 release of panels and 1.0 release of ctools.

If there is no way to select which taxonomy terms are from, it is unclear what the default behavior should even be. In this case, it might be best to use tid rather than term name.

For reference, in my case I have duplicate terms in two different vocabularies and would like to pull content from both of those terms into a vocabulary page- that functionality works fine, but it does throw the error.

Is there a workaround to make the error invisible to the end users?

More information about this bug: it's turned out to be quite bad on one of my sites, since if a user adds a term to a free tagging taxonomy that is identical to one in another taxonomy (as they are wont to do), it makes error messages appear on *all* pages, even the administration pages.

1. Inserting a call to dsm() in term.inc, it seems that for some reason, once there are identical taxonomy terms, ctools_term_context() is getting called with *that* term as an argument *twice*, on *all pages*. This isn't coming from blocks, since it's happening even on administration pages that use Garland and no blocks. This seems strange.
2. If the taxonomies are hierarchical, this is only a problem if the terms are in the top level (perhaps, at the same level?) -- if in the free tagging taxonomy, I add a top-level (parent) term in the other vocabulary, the error occurs; but if I add a term identical to a child term in the other vocabulary, nothing happens.
3. As a workaround, I've just removed everything inside the if clause (lines 48-58 of terms.inc). I haven't found this being a problem, anywhere. What should this break?

Hope this helps.

@petrelharp: Just change your error reporting settings at admin/settings/error-reporting

Or...in other words...subscribing

@petrelharp a safer workaround is to change the if line to
if (count($terms) > 1) {
That way the original handling of when count($terms) == 1 is still retained.

I'm submitting this as a patch for someone who knows what this function does to review. I too find it disconcerting that this function is being called on every page, even the admin section.

subscribing

patch did not fix any error for me. Still have problem with the fact that $conf['vids'] is unpopulated.

Is there no way to avoid this by selecting a vocabulary for a pane so that it only looks for a term in that vocabulary? Seems logical but I can only figure it out for the view, not the panel.

Still an issue.

      if (count($terms) > 1) {
        foreach ($terms as $potential) {
          foreach ((array)$conf['vids'] as $vid => $active) {

updated (from #9) made it stop throwing warnings. Not sure about the bigger 'by-vocab' feature right now.

subscribing

subscribing

Subscribing

It seems to me that there are two issues here:

• When $conf['vid'] is unpopulated because the context is derived from the panel's path rather than the panel settings form
• When taxonomy_get_term_by_name($arg) returns no matching terms

I don't think it's related to a term being found in multiple taxonomies. (Note: changing the title to reflect that, please change it back if I'm incorrect about this).

I've attached a patch that solves both of these issues, but I'm afraid that I'm treating the symptom and not the cause. The underlying problem is that $conf is not populated if the context is created outside of the pane settings form. Perhaps that's the way it should be? As such, I'm marking this as active until someone with a better understanding of how contexts are passed around can look at this.

Thanks.

- Mike

Spent a little more time working with this and I think I've come up with a better solution: allow the user to select one or more vocabularies to limit the context to when converting a path argument to a context. This ensures that $conf['vids'] is set and maintains the existing functionality if the user makes no changes.

- Mike

Sorry, just realized all this has been going on in the Panels queue. Moving to ctools queue as that's where the fix belongs.

Also reducing the priority -- I hadn't realized that this was originally entered as critical.

grumble, grumble... And changing to the correct component... I think.

This is happening to me when the term in the context has a child term with the same name as another term in a different branch of the same vocabulary. Any ideas how to work around that?

upon testing the patch in #19 I get a different error as a result of the patch

warning: array_filter() [function.array-filter]: The first argument should be an array in [...]/sites/all/modules/ctools/plugins/arguments/term.inc on line 47.

@mikeker - your patch from #19 works well apart from the bug mentioned in #23 if config hasn't been set for that particular pane.

Solution: a trivial change of line 47 to:

  $conf['vids'] = is_array($conf['vids']) ? array_filter($conf['vids']) : NULL;

Patch re-rolled and attached.

@jbrauer another solution would be to actually configure the vocabulary for your page. That might involve recreating the Panels page, as I can't see any way of editing existing contexts here :-/

Committed, thanks! I slightly adjusted the #default_value test.