Skip to Navigation

Drupal Module: Introducing Nodequeue Extras

The Nodequeue module is an invaluable tool in the Drupal developer’s toolbox.  It’s often the best and most versatile way to allow site admins to promote featured content.  That said, it is not without its drawbacks.  The initial release of Nodequeue Extras attempts to solve two common shortcomings of Nodequeue.

Contextual links

Out of the box, nodequeue forces users to browse the site to find eligible nodes to add or remove from a queue (or browse the admin section of the site to find the right nodequeue).  This tends to be a usability problem for users who are otherwise accustomed to finding the tools they need to edit content near the content itself.  Nodequeue Extras makes the queue-editing workflow much easier for your users by adding contextual queue-edit links to any views that contain a relationship to a nodequeue.

Optional subqueues

We commonly find ourselves using nodequeue to build automatically-generated lists of content (containing, say, 5 recent news articles) that can be partially overridden by an admin.  In these cases the admin wants to be able to optionally specify some or all of the articles in the list but have the remainder automatically populated with the most recent articles.  This is easy to do with Nodequeue by creating an optional relationship to a queue and configuring your sort criteria carefully.  

We commonly need to do this on taxonomy-term landing pages using subqueues, and therein lies a problem.  Adding a contextual filter that limits results to a specific subqueue means just that: only nodes that have been added to the subqueue will be returned.  There’s no way to do a partially-overridden list as described above when using subqueues.  Nodequeue Extras provides a way around this limitation with a special relationship handler and argument handler.  Here’s how you set it up:

  1. Instead of the regular nodequeue relationship handler, add the relationship entitled “Nodequeue: Queue (Extras).”  Be sure “Require this relationship” is un-checked and be sure to choose at least one queue by which to limit results.
  2. Add an argument of the type “Nodequeue: Subqueue reference (optional).” This argument expects a subqueue reference (for taxonomy smartqueues this is the term tid, for example).  Configure it as desired but make sure to select the relationship you created in the previous step.  Your view is now set up to optionally relate to the desired subqueue.
  3. To get the desired sort order described above we add two sort handlers:
    1. Nodequeue: Position (asc)
    2. Content: Post date (desc)

And that’s it!  Hopefully your nodequeue-wrangling will be a bit easier going forward.