Drupalcon: Earl Miles talks about Nodequeue and Panels

March 3, 2008

Earl Miles is the author of the Panels and Nodequeue modules, and gave an overview of some of the featuers of these modules. There were also a demo site and some slides, which will help make some of these following notes make more sense.

He wanted to create a simple "news" site
It's impossible to keep up with the River of news if you have a high-volume site. It gets too overwhelming too quickly with only one column that's not separated or categorized by context.
You also want to have your content more visible at any given time.

[Now showing front page panel with 8 different sections]
[Now looking at a specific article with more panels subsections on the right]
The blocks on the right know where you're at, and you can do this w/ PHP but it's harder than it should be.
You can show content that's related to it very easily.

Assumption for this demo:
* Can use any content type that you want
* Going to use taxonomy to control sections
* Editorial control is something that we're not worried about for this demo
* Scheduling is also something we're not talking about.

Why these two modules:
PANELS
* Final layout control than blocks
* lets each pane know about data on the page -- so it has more knowledge than an ordinary block
* Overrides basic pages
* Plubable and expandable to handlg more objects

NODEQUEUE:
* Lets the editor control order
* Lets the editor control length
* Automatically pairs with taxonomy

So many people don't understand the concept of a queue. If you're British, you know what a queue is, and you're familiar w/ long queues.
This end on the left is the Tail or back
New items are inserted at the tail of the queue
This end on the right is the head of the queue.

Feature Stores
Queue size of 5: A, B, C, D, E -- and when you add F, then A is no longer in the queue. And it helps keeps items fresh and in the queue since it manages itself.

Nodequeue gives a nice interface for reordering queues.

You can give this to your editors to control which feature is more prominent than the others -- It means that the Last listed item is the most recent one. But this order can be changed. Whether it's forward or backward, it doesn't really matter. Can integrate with Views as well.

What's really important is that nodequeue has a smartqueue, which allows you to relate various different queues via taxonomy. Create a new term, and as soon as it sees the new node, then it creates a new "subqueue" for you.

Have a site where we have news publication, and every week we do a new issue, and we tag it with the issue number, and a different vocubulary for the section -- every node is going to have a term from both. When use nodequeue, and choose a node, then the terms determine which subqueue it becomes a part of. It is like a cartesian. Your views become separate, and don't interfere with each other.

QUESTION: Can you have it pop out of one queue and into another one?

You'd have to control when it's popped out, then you can uses actions to

QUESTION: What's the advantage to using nodequeue over views?

You use them together, and you use the nodequeue for the sort.

If you're using multiple vocabulary, then it doesn't destroy the order.

QUSTION: Can you pull position 1 item from all queues?
You could probably come up with a view to do that.

QUESTION: Can you do back issues?
Yes, if you use tagging with multiple tagging like described above.
But this is not a simple question -- if you create a snapshot with a cron job that runs 20 lines of code to capture the queue positions every day, then yes. But there are all sorts of things you can do with a small bit of code.

Views arguments could also be helpful for doing views of back issues. You just need to tag those nodes with a combination of vocabulary for issue number as well as a separate vocabulary terms for the sections so that you can filter on them.

You have the regions of header, left sidebar, right sidebar and footer, and then you only have the content as the central block. You can use regions, but for most sites, it gets really ugly really quickly.

There is a module for generating regions, but there is no standard interface for generating them. So blocks are really less workable than they ought to be. For example, you can't just make one region go away -- like say just the left sidebar. You have to either have all of the regions or none of the regions.

But with panels, now you can do all sorts of stuff AND still have block-like panel subsections, and you can tell all of the Drupal regions to go away. They're no longer rendered at all. Or you can add the panel view in addition to the regions.

So panels allows you to create all sorts of crazy configurations with whatever you do can do with CSS. All without tables -- except for IE, and use padding tricks. And yes, you can use a mini-panel for recurring sidebars

There is a lot of confusion on panels context, but you can think of Context as an Object -- it's just like the node object, user object, taxonomy terms, forms or any other thing in Drupal that is represented as an object.

You can pull in contexts from node. You can use the nid to pull in the taxonomy term, which can then determine the node author, and then you can figure out the author's profile. It's this chain of context that then becomes available to panels to be able to place anywhere within a created panel subsection.

[Earl shows a graph showing the following relationships]
Node: story XYZ -> Add comment form
Node: story XYZ -> node.tpl.php
Node: story XYZ -> attached files
Node: story XYZ -> node-panel-foo.tpl.php
Node: story XYZ -> CCK Field Group

Complicated node with a lot of fields, subtitle, and a picture.

Most data is related to other data, and panels knows about these relationships. A node is related to a user via the UID field. There's a piece of data in the user node field that tells it which node is that user's profile. The relationships are coded specifically for each relationship, but the code is pretty simple. It goes out and loads the data, and loads it in

There is a UI in panels, and you can load in all of these various different contexts. You decide what to load where via the UI.

The CCK node reference hasn't been written, and the CCK module maintainers want to write it, but they're flooded with the Drupal 6 port. But making CCK fields like node reference available to panels will eventually get done.

You mix and match panes that require contexts -- and they won't even appear if there aren't data available. It just won't be displayed.

QUESTION: What is the relationships between layouts and displays?

Display is a technical term in panels, and if you think about it an analogous way to a computer science object
Object is the definition and the class is the definition realized.
Layout is the definition, and the display is that definition realized.

And style is a pluggable system for your themes

Going to not use Drupal's tab solution because there are some bugs.

QUESTION: What's the performance hit for using panels?

There is a 10-20% performance hit for using the panels.module to run your panels. But what you can do is export the panel into a module, and get a lot better performance, very similar to what's possible with views.

Panels also has an API to cache individual panes and the entire display. Caching is site specific, and so he didn't want to get too far with it.