I posted this in the general forums - but didn't get any answers... so this request is a duplicate of http://drupal.org/node/328007

When setting a Panels Context with NodeID you can build different layouts and content (which are sometimes refered to as "displays") for different Node Types (which seem to be synonomus with "Content Types"). This much seems clear and works in Panels5, but apparently is not yet working right in P6.

So working with P5 I am confused by the choices provided when configuring the NodeID context which looks a bit like this

Node Types:
check boxes for each Content Type
You can restrict this argument to use the checked node types. Arguments from non-conforming node types will be ignored, and Panels will behave as if no argument were given. Leave all unchecked to impose no restriction.

Use different default display
check box
If checked, when this argument is present it will use its own display rather than the default. Node types not selected in the "Own display" field will use this one.

Own Display:
check boxes for each Content Type
Each checked node type will get its own special display to layout its content. Only node types set above should be set here. Node types not set here will use the default display.

The first part defines which Content Types can pass their NodeId as an argument (and which will be ignored)

As far as I can see this sets up a "default" display. Selecting "Own Display" then creates additional displays (where you can configure layout and content) for specific Content Types (what I am trying to achieve)

What does the Use different default display actually do?

Can anyone help clarify this for me???

Comments

laken’s picture

I'm working through understanding this and will post back here when I have a good overview.

sdboyer’s picture

Status: Active » Closed (duplicate)

Those options still do the same thing they did on D5. It's just non-obvious (read: useless) because the tabs don't show up on D6. This is due to awkwardness with and changes in the menu system. That awkwardness, among other things, is why we're coming out with a Panels3, that has quite a different (considerably more intuitive, we think/hope) approach than Panels2 does with Panels page. You can still do everything you did before...just 50% less confusing!

I do have some experimental changes being tested right now that ameliorate the tabs problem at least in the short term, though, so people can at least USE this freakin module :)

The tabs-not-displaying is a known and reported issue, though, so marking duplicate.

laken’s picture

Um... this support request was filed against the D5 version, and I can't see where the OP mentions tabs not displaying. So I'm wondering what your response actually means... :-) Seems like this is a legit query about how the module functions under D5.

shiroitatsu’s picture

Status: Fixed » Closed (duplicate)

It means that when you check the use different default display box, panels will create another sub-tab on the content-tab. Layout settings made in that tab will effect all the selected contexts that you haven't selected to create own display for. Was that any clearer?

Example: You have a context for taxonomy terms and you have vocabularies for fruits, vegetables and exotic rocks. For some reason you want to use default display for something else (totally another context maybe) and for exotic rocks you naturally want to have it's own display. You check use different default display and own display for exotic rocks and now you can make specific layout for exotic rocks and fruits and vegetables share the different default display (in this case it would be "taxonomy term 1 default").

Ha! So it could be called context specific display. Capisce?

shiroitatsu’s picture

Status: Closed (duplicate) » Fixed

Can't wait to be able to use contexts in D6. It's the only thing i wish for x-mas.

sdboyer’s picture

Status: Closed (duplicate) » Fixed

Wow. Heh. Show how much sleep I needed this week. I read the bit at the beginning about not working properly on D6, and just blazed right ahead...

shiroitatsu is right, although that's not the way I'd think to explain it. So, the 'inside-out' or 'guts-oriented' explanation:

Whenever Panels (really, panels_page) gets a page request, it goes through the process of determining what the most specific display is that's available for that page request. So, say that path requested is 'node/5', and node 5 happens to be a node of type 'Page'. panels_page loads up the panel_page with the path node/%, and then starts running checks to see if a display specific to that type has been checked on the argument id box. If one has AND some changes have been made to it that make it different from a default, then that one's used. If one hasn't, then Panels falls back to the default.

Falling back to the 'default' is what the checkbox you're asking about is all about. Ordinarily, Panels will fall back to the base Default; by checking that checkbox, though, you get to create an intermediate default that's specific to nodes, in which case that node-specific default will be checked and (if it exists) used; if it doesn't exist, then we fall back again to the base default. Visually, it's the difference between:

Node type-specific display -> default display

and

Node type-specific display -> default node display -> default display

The use case for this is fairly thin; you'd really only need the different per-argument default if you had multiple arguments - say taxo and node - so that they can have different fallbacks in the case that that's necessary.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.