Panels Keyword substitutions don't work for "Input on pane config" argument on view panes

I'm having the same problem. I can hack around it for now by fixing the arguments, but that makes for annoying maintenance. Tracing through the code a while, I found $context empty in views_content_views_panes_content_type_render(). Reaching the unpack function from import/export, I finally noticed that every views_panes type from {panels_pane} has no context embedded in its configuration. I reason that the problem is with Views, but that bit is handled by CTools, so someone with some authority should probably punt this over there.

The 'required context' values passed to views_content_views_panes_content_type_render(...) are always empty for UI built input arguments. This traces back to ctools_views_get_argument_context(...) ctools_content_select_context() in ctools/includes/views.inc. UI built input arguments seem to always have type `user', but ctools_views_get_argument_context() only works on those of type `context'. I'd submit a patch, but I don't know if type~context is a useful case. Does anyone with some history know if `context' should get replaced with `user' or if another branch is in order? The function filters out panel contexts that don't map to pane contexts, and no other facility exists for propagating other contexts for use as keywords.

I got it narrowed to an insufficiently robust ctools_content_select_context() filter. The function doesn't anticipate arguments, and so in the absence of context configuration data, the render method doesn't get any data to substitute for the keywords. I'm just going to branch the logic inside the function to handle the possible alternative. Maybe the configuration should be augmented with a `context' keyed array mirroring the `argument' (sic?) keyed array earlier in the pipeline, though?

Just got to thinking, the text/keyword argument facility looks older than the context argument facility. As such, I imagine that the older logic from text/keyword has broken somewhere as the system shifted to incorporate context arguments. Rather than shifting the system yet again to handle text/keyword (probably breaking both facilities), I'm going to explore piggybacking the text/keyword functionality on top of the context system. Under my current understanding, this could happen as follows:

1. The UI remains as is.
2. The ctools_content_select_context() function works on both context and argument keyed values of the $conf array to build the contexts fed to the renderer (you can't hardcode context arguments under pane settings, making them less powerful than text/keyword arguments--if you could, I would happily forget about text/keyword arguments).
3. The renderer completely ignores the argument keyed values of the $conf array, and the render's `context' and `user' cases unify to a single case.

My biggest reservation is the handler's get_argument_input() behavior. I looked in there a long time ago, and abandoned understanding it because it looked complicated and seemed to behave properly. It has to provide arguments in the ordering expected by Views, so I don't want to touch it (any fix should respect the boundary between Views and Panels, so why not move that boundary a little further to include get_argument_input(), yeah?).

Combining the two cases, that array_shift() ugliness can be removed from the renderer. If the refactoring materializes cleanly, then maybe the implementation could even be migrated to the handlers corner of the API to provide the text/keyword functionality for free to any context argument implementors. With the boundary between text/keyword and context arguments blurred, the UI for context arguments could be generalized to accept hardcoded arguments.

I experimented with returning arrays only, like the fn's docblock claims, but it breaks anything that is keyword agnostic. This setup breaks my minipanels when my arguments are all keywords (an array_shift is called for a nonarray). I thought this was a flaw in the patch for a while, but I can't find a call from minipanels to the altered code. I have to dig further, but this may be a bug in minipanels. The call to ctool_context_match_required_contexts() crashes when minipanels passes its single context not mapped in an array. I really want a workflow with keyword arguments to minipanel constituents, so I'll be working the kinks out of minipanels also (step one is rolling back and excercising minipanels under the current dev release).

Sorry to the OP, also. I just realized that my previous post doesn't bring much closure to the issue itself. Rather than text in a field to denote an article type, you should probably have a taxonomy term attached (and if there's only one FAQ, then you should attach it as a context to the pane's owner and then pass it to Views as a context argument). Under such a schema, I'm pretty confident that the context system would serve your purposes. I'm torn between normal and minor priority, but the context system is so elegant compared to the keywords, I feel that our usage pattern is more of a hack. If someone had a magic wand (*ahem*), I imagine that the entire keyword system would get junked and replaced with tokens, with keyword use relegated to content areas only. For instance, you could have a contextual filter that keeps only nodes with a field that contained some chunk of text. Sorry about that, I couldn't help myself. Seriously, you should be using a taxonomy. I could maybe see filtering on a phrase as a member of a body field useful beyond what's provided by context arguments, but I'm probably being unimaginitive.

P.S. If I already had 102 pieces of content with the text field, then I'd take a closer look at the Views Bulk Operations module (on a dev site first--never trust an infojunkie).

I can confirm that I have had this problem, but I'm also fairly certain that this has actually worked, though I don't remember exactly when I used it, so it shouldn't be that complicated. The initial patch for this support was only posted this summer.

I'm setting needs review as I hope someone will review the patch and give some hints for what needs to be done. Also moving to Ctools, as that's where I believe it belongs.

I found this issue yesterday while building a taxonomy term driven page and the one line fix is fairly simple, I'll post it tomorrow.

The solution from #16 works for me.

+1 on the patch.

Just figured out, that the change above, breaks some of my views panes.
Reason is that if all contexts is set, the order of the contexts isn't maintained.
Unfortunately views_content_views_panes_content_type_render relies on the order of the given contexts (see line 152).
The attached patch adds a check to the handling of all contexts to see if a specific order is needed and if so it calls ctools_context_select().
Unfortunately I had to adjust ctools_context_select() as well, to make it possible, to merge the ordered and the possible leftover unordered contexts.
ctools_context_select() now returns the array of contexts keyed by their name and not numerical anymore.
This modification could have unpredictable sideeffects - however in my tests everything seems to work as before.
Of course there are other ways to mix the ordered / unordered contexts - but this one was the most elegant I could think of.
Feedback welcome :)

How about this - I've just extracted the "ordering" code of ctools_context_select(), adjusted it a little bit and added it to the all contexts handling in ctools_content_select_context().

@das-peter, do we still need to use the patch from #16?

Understood, sir!

The patch from #16 has caused the panel page that I use for OG to fail. The pane no longer returns either related OG nodes or OG members. If I revert this patch, then all works well.

Is there something besides clearing cache that I must reset or rebuild to make this work?

I had originally opened up issue 1428740 on OG when I updated to Drupal 7.12 along with updating all of my modules. It appeared that Ctools was not compatible with OG. That may not exactly be correct, but I'm not quite sure what to do.

[Edit] Answered my own question. I have applied the patch from #21 and it appears to have solved the problem.

Any thoughts about porting a patch over to 6.x?

The folks over at #981416: Passing %keyword as Argument to Views Panes would likely be grateful (myself included). The issue is "closed (works as designed)", but the comments (#9) indicate that the issue was perhaps falsely labeled and closed.

For what it's worth, I tried applying the code in #16 and #21 to the corresponding files in 6.x.1.8, but they didn't seem to resolve the issue.

My intention was to use the same code as it is used already on three other locations.
I'll happily refactor all of those, but please let us solve the issue first. I'm afraid creating a bigger patch will lead to something like "Why did you change all that working code and not just fixed the bug?" ;)

I agree with das-peter, let's leave the world changing things for later.

Great! Patch in #21 worked for me.

I had upgraded OG, Panels, Pages, Views and ctools to current latest versions and the panels I'd set up to display OG view panes had stopped working as unable to get the OG context. Now works - phew!

I have a completely different fix for this that I committed a few days ago: http://drupalcode.org/project/ctools.git/commit/c5e94816acfe21057e1167a1...

I'll have check 6.x -- I didn't think this bug had been backported to D6.

Just a quick reply to keep this open for merlinofchaos'scheck of D6. #32, #981416: Passing %keyword as Argument to Views Panes, and my own experience seem to indicate that the bug was backported to D6.