These are my slides and example module for my BADCamp presentation tomorrow.

In Panels, Context is lingo for a wrapper around any significant object. By default, Panels supports 'Node', 'Taxonomy term' (and terms as mentioned above), 'Taxonomy vocabulary', and 'User' as contexts.

These contexts can get into a display in more than one way; right now, there are three ways that a panel page can acquire a context:

A quick review of both the #drupal IRC channel and the activity on the dev list is that, despite everything, Drupal’s new release system is a little confusing. And, truth to be told, it is a little confusing. In my [not so] humble opinion, this is not the fault of the implementation or the design of the system, but more the fault that Drupal users and developers have gotten accustomed to a system that sort of worked, but left a lot to be desired.

To start with, the original system worked well for Drupal core itself. This meant that a fair number of people, who primarily deal with core, never really got to get face to face with the problems that manifested on the contrib repository. But that’s a relatively small group of people, and all of them are very smart people. While it took some good arguing, the bulk of them were convinced that the new way is a better way, and thus the improvements actually came to pass.

So you have Views, and you've figured out exposed filters. Which, in short, gives nice handy little widgets to search. Often by keyword or by some taxonomy term.

Now what you want to do is put that functionality in a block. Say you're doing a catalog search or you have something you just want to always be up.

No Problem!

You need 2 snippets. In Drupal 4.7, the first goes in a custom block, and looks thus:

One thing panels does well is to put a bunch of unrelated or at least not directly related content in different areas on your page. One thing it doesn’t do well, by itself, is to stripe content across regions.

But what we can do is get Views to do that kind of thing for us. And because Views is not plugin driven, instead of telling the user “Oh you have to theme it” we can provide a plugin that does exactly that. In fact, I’ve decided to try and do away with the “Oh you have to theme it” answer, and created a new project on Drupal, called the Views Bonus Pack where I (and some other people who do a lot of Views work) can put plugins and default views to give the starting user a place to work from as well as a bunch of cool tricks.

A year ago, I began the long odyssey of creating Assign Blame, a multi-user blog where I had editorial control over published content, but I didn’t intend to be the primary creator of content. This was a great idea, of course, except for the fact that nobody else wanted to be the primary creator of content either and as such, the site has languished since November; nearly six months, now, it’s sat, waiting. I haven’t bothered with it much, lately, because it’s still running under 4.6. Still, despite the site languishing, creating the proper tools to make that site work and contributing them back to Views has, in fact, been one of my driving desires.

One of the things that happened with Angry Donuts here is that while I was fiddling with the logo and stuff, someone popped into the IRC and started asking about how hard it would be to implement DHTML menus based on this script. The person went by Aw0L and I have no idea who that is, otherwise, but I did end up getting the script working, after giving it a pretty serious workover.