Content panes fit so good into Panels that it is really silly

The quote I borrowed for the title of this post is from Johan Falk, who will be sorely missed by the Drupal community, as the screencast series he produced for Node One on Page Manager is exceptionally informative, and often hilarious. If you haven’t seen the series, check it out.

Ahem, Okay. First, let’s understand what Page Manager actually is; Page Manager is a sort of responder to HTTP requests that overrides Drupal’s natural behavior. Drupal generally establishes a URI structure that dictates where a piece of Drupal content lives. With Page Manager, we can begin overriding Drupal’s behavior, injecting content that is architected with something like Views where Drupal content would normally be. I guess that means that Page Manager is really a content manager, at least in application. If this is a poorly formed assumption, please leave a comment.

Used is conjuction with Panels, which is a layout manager, we suddenly have enormous potential for controlling the typical content that appears at, say, node/ or taxonomy/term/. We can more easily control the content flow. This is just the thing I need to manipulate what typically appears at Drupal’s often used, but pretty lame, term pages.

Here is my use case. I’ve built a navigation using Taxonomy Menu, which is rad, as I have a large dynamic Taxonomy that needs to control the flow of how a user winds up on a node page. By default, each menu item links to the term page used to build it.

At a term page, I want to see any node that have been tagged with the term, and any child terms that the term has, so that I can build a pretty looking catalog. Like this:

Parent term (i want to see a list of all children)
- Child term (i want to see a list of all grandchildren)
-- Grandchild term (this is where I want nodes to appear)

This can be halfway done with Views, or maybe even completely done with Views, but attempting a pure Views approach was like pulling out my own teeth. So, this is where I turned to Page Manager, as I can begin overriding what appears at a term page.

Because of Drupal’s kindness, we have an argument available at a term page that dictates what term appears. This means Page Manager can know that argument, and we can then pass that argument to whatever appears on the page. In our case, thats Views Content Panes. So, enable Page Manager and Panels, and then enable the term page manager that it comes with stock.

Okay. If you’ve watched Johan’s screencast, you should have a sense of what is going on here. We’ve enabled the page override, and now we need to tell it what to do. So, we’ll create a variant that responds to a request for a term with a panel display. Using Page Manager’s selection rules, we can also instruct Page Manager to only respond if the request is for a term that belongs to a particular category. In my case, this is my navigation taxonomy.

Now, we can use the Panels layout interface to determine what kind of panels system we want. I’/m not looking for anything fancy, so I used a single column layout.

Now, lets hop over to Views, where we’ll build some content to feed to Page Manager. In my case, I want two distinct views; One that returns nodes, and one that returns child terms. With page manager, we can get these to co-exist on a single page if the Views display is a Views Content Pane. This is a new display option that one has after enabling Page Manager.

It’s worth noting that, by default, Page Manager can display child terms of a term, but this is better done with a view so that we can include fields attached to the terms, just like with any view.

Now for the tricky part. For each of these views, we essentially want to contextually filter them with an argument that is being passed to the view by Page Manager. Johan Falk suggests using “context” as the argument input for each view, but I couldn’t get this working. Instead, I’ve used Panel arguments.

So, build and configure the master display for each view as normal. This means creating a contextual filter based on a term id.

For the node view, we get this via a relationship called “Content: Taxonomy terms on node”, and a contextual filter of “(term) Taxonomy term: Term ID”.

For the term view, we’ll add a relationship called “Taxonomy term: Parent term”, so that we can use the parent term’s tid to filter. Again, we’ll add a contextual filter called “(Parent) Taxonomy term: Term ID”.

Now, for magic. As we have two views that can be contextually filtered by a term id, we can configure where that contextual filter comes from. To do so, create a new display for each view, selecting “Views Content Pane” as the display type. Once that is done, we can configure where that contextual filter is fetched from, using the “Argument Input” setting.

Configure each view to get it’s contextual filter argument from “Panel Argument 1”.

Now we’ve got some views to plug into Page Manager. Navigate back to Page Manager, and add some content to our term view override. At the content tab, hit the little gear and select “Add Content”. In the list of options under “Views Panes”, we can see both of the content panes we just built. Add both, and arrange them however you like.

Now, on a term page, we’ll see a list of Child terms, and any nodes tagged with that term. The views content panes are responding to the argument that typically exists on the page, which is being passed to the view as a panel argument.