Passing Arguments to Mini-Panels

same to me with panels-3, can't find a way how to pass a context from my parent panel to my child mini panel

Same here. I've overridden the node page with a panel page and created a mini panel that takes the node's taxonomy term as an argument and passes that to a view to get related content. The problem is when the mini-panel is in the sidebar, it doesn't pick up the arguments (it does when I add this mini panel inside the panel page).

Are we doing something wrong or is this something panels can't do right now?

When you say "in the sidebar" do you mean as a Drupal block, placed at admin/build/blocks? If so, then it cannot pick up arguments. Blocks in Drupal do not receive them.

If you want contexts to 'pass through' from a Panel into a mini panel, you have to add a 'required context' to the mini panel on the contexts tab. Then a context needs to be associated with the mini panel when it's added to the panel on the mini panel's settings dialog.

Similar question, is it possible to pass arguments to mini panels used in a panel?

Mini panels do not accept arguments, only contexts. See my answer in #4.

I found a workaround
1.Enable PHP Input Filter
2.Add a custom widget
3.Use the code here http://drupal.org/node/643430

That question isn't very meaningful. What kind of panels? What kind of arguments? Why are you resistant to required contexts?

I think it's a feature request.
Currently passing arguments is only possible when adding views directly to panel.
If you use mini panels to combine block of several views and then add the mini panel to your panel.
You can no longer pass arguments to your views.

What's the use case?
It allows making generic views & blocks when designing complex panels. For example you can use a mini panel (which includes several views block) several times on your panel and each time call it with a different taxonomy. It's a bit complicated to explain let me know if you needed more info. I've done it finally using the workaround i posted here

One more thing, why use mini panels inside a panel?
I'm using Mini panels in this case of including another block inside a parent block. something like this :

|----------------------------------|
|                             |---------| |
|                             |           | |
|                             |           | |
|                             |---------| |
|----------------------------------|

You can pass anything as contexts. Passing arguments is actually kind of tricky, as they are hard to identify and are order dependent, whereas contexts are named and the order doesn't matter at all. If you want contexts that aren't really objects, you can use 'string' contexts. Those pass from Panel -> mini panel -> view just fine.

Cool thanks, i'll give it a try

Hi merlinofchaos,

I've been struggling with this same issue for a wee while now, could you possibly suggest a route forward? I've tried introducing context etc. and still get nowhere.

The requirement:

I have two content types:
- Project. A page containing details of a project my team is working on.
- Source. A book page for documentation and links to source etc. (not top level book page, but it does have children)
Source pages have a cck nodereference field to the Project page.

What I'm trying to create is a list of Source pages on the Project node page.

I'm using panels3 minipanels and views.

Views setup (working)

I have a view set up which takes a single argument: the node id of the project page.

This correctly displays the list of source projects with nodereferences to the project in question when I input the project's node id into the arguments box for the preview.

I have found no other way of getting this list without using an argument. Have I missed something?

To prepare for the panel setup I added a Content Pane display, setting Argument Input for the nodereference field_project to be "From Context" with a required context of "Node ID". My understanding is that this will extract the Node ID from a node passed in as context, and pass this as the argument needed for the Project nodereference id.

Minipanel setup (failing)

I tried initially passing "Node" as Required Context. (Identifier = Project Node, keyword = projectnode. No other options available). My understanding is that this would pass the Project node being viewed as the context. Wrong?

Layout is simply a single column.

Content is set to be the ContentPane of the view mentioned earlier, with only one option set: a select menu titled with the nodereference fieldname of the argument in the view, with the only option being Project Node.

Pathauto??

If I set up a view as a page with a path such as node/%node/source and the arguments as listed, then this correctly shows the list of Source pages. I have a pathauto alias for projects which allow me to simply use the project name in the url. This failed when I replace node/%node with the alias. I don't know if that failure is due to pathauto stripping the /source argument or minipanel or views failing for lack of a numeric argument.

Not using Minipanels

Not using minipanels I can create my desired view fine. I just can't load it up in a block like a minipanel :(

Conclusion

I feel like I'm missing something in the connection of minipanel context to views argument. It feels like too much 'magic' - i.e. wrong.

Suggestions greatly appreciated.

If there's any clarification needed on anything, please ask. I'll be here, slaving away on this :(
(sod's law, I'll probably solve the thing in 15 minutes... but not now that I've said that. Sigh).

p.s. I have managers. Rewriting the structure of the site for theoretical or philosophical arguments is extremely unlikely to happen. e.g. I'm not using taxonomy terms for this structuring, and I'm extremely unlikely to have the freedom to do this. Just fyi.

Many thanks
Al

As I mentioned previously, Mini Panels used as blocks cannot receive contexts, because the block system has no notion of context. It has nothing to pass into the mini panel, so the 'required context' does not work there. You therefore cannot used any mini panel with any required context as a block, because blocks simply never have context.

The pathauto problem is a classic one because URL aliasing in Drupal is very strict.

Let's say I have 'node/1' aliased as 'foo/bar'.

Now, I Drupal has a path to edit this node. 'node/1/edit'. However, 'foo/bar/edit' does not work, because url aliasing works only on the complete URL.

'foo/bar' translates directly to 'node/1'. 'foo/bar/edit' will only translate if there is an alias specifically for it.

Ok context not working in mini panel block is understood, but can we then pass url argument to mini panel somhow?
Also views have php filed for argument, would be great if panels have this so we can pass anything to mini panels which usually show some views:-)

It would be helpful if there were a way to "set" contexts dynamically, rather than having to hard-code them when defining the context.

For example, many times, I have wanted to define a node context and assign the context with some PHP. I've only been able to do that assignment in Selection Rules -- which has issues because of ordering -- or in Content Custom Widget -- which has issues because of pane execution order. I actually like the idea of contexts, but I haven't found a good way to assign them dynamically using PHP.

How about a PHP snippet field when defining contexts (strings included)?

The way to assign contexts dynamically through PHP would be to create context plugins. A context plugin can actually create a context for a different plugin, allowing you to use whatever PHP logic you want to find the context and create it.

I see. Seems like a lot of overhead for doing a dynamic selection, especially considering we want to use the same substitutions as are already available (e.g. %node:title and all the other node substitutions available for a node context). PHP snippets are available for selection rules and content within panes. Wouldn't it fit the model to have PHP snippets also available for choosing the appropriate node for a node context? Just asking.

Ahh, maybe, but "arguments" system is isn't set up to be able to handle that right now. Plus, putting PHP in your database is a bad idea anyway; it's always *best* to create plugins (and any of the things that have snippets can be turned into proper plugins) so that your code is in a safer place, and hopefully in some kind of version control system.

Right, was only talking about a one- or two-line snippet (something that would make a function call most likely, and wouldn't need to change). Would be extremely useful to have something like that in the future.

I see your point though. So you'd recommend copying one of the "base" plugins over to create a custom plugin, and rather than having the input box for specifying the context value, rewrite with logic included? I'm sure I could figure that out! :)

Hey there.. I needed a way to get node contexts set dynamically, so I modified ctools\plugins\contexts\node.inc, figuring that views, panels, etc. all rely on the node plugin, and that I couldn't just add another one with the same name.

I'm attaching a patch that has the couple of changes. It basically adds a textarea for entering PHP code which needs to return a nid. The one piece I couldn't figure out is on line 49, where I attempt to do context keyword substitution (it's commented out):

ctools_context_keyword_substitute($code, array(), ctools_get_contexts());

Anyway, it seems to work for simple snippets of PHP, though not fully tested and it needs some sanitization and error detection (particularly around the eval()). I'd love to see this type of thing worked into the codebase for panel contexts, just like you can use PHP snippets for selection rules and content.

You can create an alternative context that can return a 'node' context. You don't have to patch the node context to do this (and a patch like this is not at all suitable for CTools itself).

Cool, so I'd just stick the functions defined here within a module?