Taxonomy term pages managed by Panels don't trigger Context's "Taxonomy term" condition.

Bug confirmed using Context 7.x-3.0-beta2 and Panels 7.x-3.0-alpha3.

The problem is that the task handler name is different from the Page Manager than it is when viewing a specific term.
I've thought about writing a context module extension that picks up Page Manager arguments from the URL, but seems like more work than its really worth.

What do you suggest? Would be possible to add an exception on the taxonomy term in order to check this specific case?

Fixing this particular bug should just be a patch, because the feature doesn't do what it describes. Sorry if my prior comment kinda sounded like I wanted to throw the ky-bash on fixing it.

I came across this same issue so I created a patch based on the code found in this issue: #595744: Node page views when using Panels don't trigger Context reaction

Can confirm patch in #5 works for me. Thanks!

#5 Patch works fine for "Taxonomy term" conditions, but does not work for specific "Taxonomy" conditions. I am overriding default taxonomy page with Panels. I am looking for a solution.. any help would be appreciated!

avits

I can confirm that this does what it's supposed to do. Works with taxonomy term. So far no observed side effects.

Has anyone confirmed if the same issue pops up for all of the other page overrides? Maybe, if the problem exists, then a patch should be concieved to handle all page types?

@hazah:
Its not supposed to know what to do on other page overrides. I grappled with this issue myself. Basically, each CORE page has a specific task name associated with it. That task name generally translates into something we can hook() onto using context and fire custom conditions/reactions.

Additional page types, such as /user/%user won't match a taxonomy term, even if a term field is attached to the user account because the task name is different. I tried to run down the course of scanning over each CTools context that was passed into the page and each custom relationship, but proper targeting turned into an absolute nightmare. I think its best to leave this development decision up to each site, rather than anticipate it being part of context's core.

Context and Panels can play "somewhat" side-by-side, but really approach the same problem from two very different vectors. Context attempts to detect X cases and make assumptions about what the user is viewing, carrying content/blocks from the site around with it. Panels tries to use the "context" inherited by the information passed into the page (namely being URL arguments). Panels can't "carry" content around (one definition for instance, would allow it to be displayed for a common condition across multiple pages--you have to define it again, and again... and again.).

In summary:
The /taxonomy/%term page will work as expected, but additional pages, like /user/%user will not.

@wjaspers I understand what you're saying. But I'm not sure we're on the same page. I am not interested in a condition that detects an override (such a feature would surely belong to panels, not context). Quite the opposite. I want the standard conditions that context provides to not be affected, at all, by the fact that a page is overriden. So when we're viewing the taxonomy/term/% "task name", the context fires regardless if it's a system page or a panel override of that page.

A little clarity...

I do use context and panels together but for two different purposes. I utilize panels for the hijacking of the primary content region only (system-main). I don't use panels to populate anything outside of that one region. I use context to decide the secondary content on the page(s) (side bars, headers, footers, anything that spans multiple pages as this type of content often does). In this way I don't have them overlap in function.

The trouble only really comes when I want context to NOT be aware that a page is overriden by a panel. Why should it be?

For instance, if you have a node holding some sort of profile information for a user (that's one specific case here), and you wish to display that information on user/% (or display one term page type differently), a panel override is a simple approach to change the main content region. But I want the rest of the system to not be aware that it's an override. I want the same blocks to appear around the main content as if I had not overriden that page. I believe it makes far more sense (from the perspective of 'least surprize') for the overriden page to be recognized as the same system page it overrides.

Aha, so you approach this the same way we do.

The trouble only really comes when I want context to NOT be aware that a page is overriden by a panel. Why should it be? .... I believe it makes far more sense (from the perspective of 'least surprize') for the overriden page to be recognized as the same system page it overrides.

Oh...I see. The page manager is selectively replacing the hook_menu callback for those pages. You should be able to write something to inspect/conditionally modify this behavior as you see fit. I don't have time to explore it at the moment, but my guess is you can change the "condition_met" values in some manner.

Either way...we're drifting a off topic from this thread...and I believe there's another issue open regarding the ability to "negate" a context as well.

I think the OT can be attributed to the need to explain the use cases and not doing a good job of it. :) my bad.

Currently this issue represents the exact same problem I have. Namely that "Taxonomy term pages managed by Panels don't trigger Context's "Taxonomy term" condition," which, I believe I am alluding to when I say "I want context to NOT be aware that a page is overriden by a panel". If it came across as a different concept, I appologize for the miscommunication, it was not supposed to.

Yes, I am aware of "negating" a context. As I understand it, that would only be relevant if panels creates an additional conditon for context to check for. My position is that a feature of this nature belongs to panels, not context. I hope that clarifies where I was going with that thought.

If replacing hook_menu is what's happening, I'm curious to know how that effects context... I haven't yet been able to navigate it properly so I'm unaware of how context depends on the original behaviour. From the sound of it it may very well be an issue that belongs to Panels. Especially if it turns out that Panels is sending different signals than the system pages. That actually sounds like the case.

Cheers.

I added the patch and it's now detecting context on my taxonomy term template panel page. What isn't working is the ability to pass term tokens. I'm trying to use context to add a description meta tag from the term description, like [node:taxonomy-vocabulary-4:description]. I've even tried to pass simple ones like [current-page:title] or [node:title] and it comes up blank.
Is this not working by design, or am I still doing something wrong?

I tested and this patch is working, I believe this should be committed. I had to re-roll the patch to get it to work for latest version of Context, but otherwise no alterations to the original patch.

Resubmitting renamed patch.

Resubmitting again, fixed module path.

Tests are broken without the latest patch on this ticket applied, so I'm not sure how to proceed. See other recent patch submissions for same results: https://www.drupal.org/node/1421104#comment-10506482, https://www.drupal.org/node/2599644 (7 fail(s), and 12 exception(s)).

These tests need to be fixed else no further patches can be submitted for this module and marked RTBC.

resubmitting now that tests are passing

Would be great to see this committed!

Tweaks:

• Only test once for $page.
• Test for $plugin object before executing it.

Thanks all, applied.