I'm still wrapping my head around the workflow and functionality of Panels (in general, not just 3.1 ;), but would it be a good idea or not to have a link to manage 'panel nodes' on the Dashboard along with the 'Manage pages' and 'Manage mini-panels'?

Also, in trying to understand the differences between panel pages and panel nodes - is there any difference apart from the context thing? The workflow seems so radically different. Could I ask what the thought behind having 'panel pages' as not being a type of node when I always hear people saying that it's best to move to this paradigm for other modules?

Thanks!

Comments

http://www.google.co.uk/search?q=drupal+%22panel+node%22+%22panel+page%22 - nothing really comes up here to help distinguish the two - is there something anyone could point me towards to help?

Status:Active» Fixed

I'm still wrapping my head around the workflow and functionality of Panels (in general, not just 3.1 ;), but would it be a good idea or not to have a link to manage 'panel nodes' on the Dashboard along with the 'Manage pages' and 'Manage mini-panels'?

It would, but I more or less don't care about panel nodes, so I haven't put any effort into adding additional management for them. You can use the existing content management tools to manage them.

Also, in trying to understand the differences between panel pages and panel nodes - is there any difference apart from the context thing?

Well, I'd think the differences between them would be pretty obvious just by using them. Panel nodes offer almost nothing except for a display that happens to be tied to a node. Since you can't really assign URLs to nodes (you can only assign aliases), you can't have arguments at all, and without arguments most of what you want to do with panel pages can't be done.

Here's a brain teaser for you:

How could I use a panel node to override the layout of existing nodes? Then you have nodes being other nodes. That's just a little bit psychadelic. But you can't do that, anyway, because you don't get any arguments, so it doesn't matter.

Things panel nodes can't do:

Assign URLs, have arguments, have multiple variants, or be exported into code and thus not stored in your database, which is the wrong place to have your site structure, especially if you want a dev -> staging -> live deployment model.

Title:Manage panel nodes via the Dashboard?Manage panel nodes via the Dashboard? plus some notes on Panels basics
Status:Fixed» Closed (won't fix)

a-ha right, i think i'm seeing things more clearly now..

my confusion is from the fact that i was coming from thinking of 'Pages' as being a type of content node. so 'Panel pages' are not actually nodes but something quite distinct (same kind of not-a-node as 'View pages' are), where as 'Panel nodes' are still nodes but with just the layout aspect of Panels.

It would, but I more or less don't care about panel nodes, so I haven't put any effort into adding additional management for them. You can use the existing content management tools to manage them.

fair enough. is there any advantage to using 'Panel nodes' over 'Panel pages' other than the fact that the former can be created in much the same way as other content types thus making it easier for basic users to create basic panels for layout?

Since you can't really assign URLs to nodes (you can only assign aliases), you can't have arguments at all, and without arguments most of what you want to do with panel pages can't be done.

got ya. to be honest, i've not delved into how to use the full functionality of Panels so far, but i'm hoping to correct this :)

(aside; i'd have thought that maybe it would have been possible to pass arguments from URL aliases to something like Panels in a somewhat similar manner to how Sub-path URL Aliases does things, but i'm guessing that method is probably ultimately uglier behind the scenes for general usage given the way Path and the rest of the Core does things, yes?).

for other trying to get their head around Panels;

i just went back and rewatched the Mustardseed Media video for Panels 3 - has a few interesting insights, but the workflow has so changed since then that it's only worth watching for the lulz.

i had a further look around and saw two newer videos relating to Panels 3;

gotdrupal.com - rather good, goes over a lot of the functionality, although somewhat confuses the viewer as to where Panels and [not-the-content-type-kind-of] Pages sit within the 'ontology' of the Drupal suite, i.e., at 13:20; "so it's very confusing when someone says you need to use panels. well panels isn't what you're using, you're using pages and you're editing panels within that page provided by ctools". merlinofchaos - would is this an accurate description of the situation these days now that ctools has been abstracted from views (from what i'm understanding)?

Panels3 demo (drupalmao setup) - a fantastic 5 min video that goes straight to the details of how contexts are used within panels and mini-panels on the drupalmao video site.

Status:Closed (won't fix)» Fixed

There are only 2 advantages to using panel nodes:

You can manage them through the normal node management system. If this works for you, that's a bonus. The other is that nodes show up in searches. Otherwise, I don't actually like them. They exist because there are people who have a need for them, but without that need I vastly prefer people use Page Manager.

And yes, I'd agree that the real thing you're using nowadays is the Page Manager which is the sort of top level management system, and Panels is really just the layout system that lets you add content into a page.

Other benefits to using Panel Nodes:

  • They can be used in node references and node queues, so e.g. you can have a node queue that references a "channel" panel node.
  • You gain access to all of the other node-driven functionality, like SEO tools, CCK fields, etc, etc..

I will agree, though, that not being able to cleanly export panel nodes is a definite limitation, though node_export is a starting point.

Status:Fixed» Closed (fixed)

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