Have you ever wished that there was a simpler solution for allowing site adminstrators to create their own dynamically-filtered listings of node content in a block? Of course, you can very quickly create such listings with Views, but the Views approach presents certain tradeoffs that aren't always idea for sites managed by non-developers. In our experience, the tradeoffs of site administers using Views often include the following:
- Views can present a steep learning curve to site administrators.
- Managing small variations in the block displays of a View (such as blocks with different item counts or different block titles) can lead to very large Views definitions.
- Providing a site administrator with Views access can sometimes lead to deep, unintended changes in your site's presentation layer.
- Accounting for all of the possible variations in the Views display layout, particularly with Views that leverage "fields" rather than "view modes", can lead to a lot of extra theming.
- When managing Views definitions in code with Features, dealing with Views that keep getting overridden in the GUI can be a challenge.
What if there was a simple solution for allowing site administrators to create their own dynamically-filtered listings of node content without the tradeoffs of opening up the Views UI?
Enter "Relevant Content Bean"
The Relevant Content Bean module is a plugin for the awesome Bean module. If you've unfamiliar Bean, it basically provides a way to treat blocks as fieldable entities. ("Bean" is an acronym for Block Entities Aren't Nodes.) The Bean module also provides an API for creating new types of blocks, which can have their own properties and fields.
The Relevent Content Bean essentially provides your site administrators with a light-weight query builder (build on top of EntityFieldQuery) for creating blocks that contain dynamically-filtered listings of nodes. Like Views, Relevant Content Bean allows you to select the number of node results to display, apply filters to the list of returned nodes, change the display options for these nodes, and manage the sort order of your results.
How It Works
A screenshot of the default Relevant Content Bean configuration screen is shown below:

View Modes and Fields
First, the Relevant Cotent Bean itself can leverage "view modes."

For developers, this means that you can write your own view modes to create different display options for the overall listing of nodes.
Since Relevent Content Beans themselves are fieldable, you can even extend these Beans to include options, such as custom "Read More" links (using the Link module) or content areas above and below the node listing returned by the Bean itself.
Display Options
Second, you can manage the "display options" for the individual nodes returned by the Bean.

The returned list of nodes can be presented as "teasers" or any other view mode defined for your content types. In addition to selecting among view modes, Relevant Content Bean provides an option for simply displaying a list of "linked node titles."
Sort Options
Here's where Relevant Content Bean gets really interesting… As with Views, you can sort the returned list of nodes by creation date or the date that each node was last updated. Similarly, you can sort on the "sticky" property.

But check this out:

You can actually sort the returned nodes on any date property or field available to each content type. In the example above, we have two content types:
- A "publication" content type with a "publication date" field that accepts a month and year.
- An "event" contenty type with an "event date" field that accepts a month, date, year, and time.
In this example, you can use the Relevant Content Bean to create a listing of publication and events nodes - sorting this single listing of nodes by different date fields.
Filter Options
Relevant Content Bean also allows you to filter your listing of nodes by content type, taxonomy, and/or various date range options. When filtering by content type or taxonomy, you have the option of specifying which content types or taxonomy terms to return.


Or, you can configure your bean to contextually filter nodes based upon the type and terms associated with a full-page node upon which your bean has been placed. (Think "argument handling" with block displays in Views.)

Similar to our sort options, you can also filter the returned listing of nodes based upon a date relative to any date property or field found on each content type.

Other Coolness
The Relevant Content Bean module has quickly become a staple on all of our custom Drupal builds - as we continually find more and more interesting use cases for it. For example:
- We've had clients create placeholder nodes and then drop a Relevant Content Bean into the page to minic full-page Views displays.
- Writing our own custom Bean view modes, we can return a list of nodes as a javascript slideshow.
And because Relevant Content Bean returns nodes using view modes, on sites that also use Views for returning node listings, we can use the same theme styles across node listings - regardless of whether those listings are generated by Relevant Content Beans or Views.
In Conclusion
We'd encourage you to give the Relevant Content Bean module a try. We'd love to get your feedback and talk more about how we can make it even easier on site administrators to customize block content.
And special thanks for ThinkShout developer, Brandon Lee, for writing this great module!

Comments
Looks like exactly what we need.
All those right sidebars in my mock-ups look like they'd be cinch to administer with RCB. Can't wait to try it.
Absolutely!
Yes, a site like yours would be a great candidate for this module!
Similar modules
This is a bit similar to the Featured Content module though the FC module doesn't integrate with Bean (which is pretty cool, btw). Maybe these modules could join forces.
Yes!
Nice to hear from you, Kristen. In short, yes, it'd be great to join forces.
I hadn't seen the FC module before we started work on RCB - but we've been pretty hooked on the Bean module for a couple of months, so that's where we started in tackling this problem. One thing that I didn't mention in this post is that we've pretty much stopped using the core Block tools on all new projects. And by that I mean that we train clients to manage block placement with with the Context module - and we use a simple Bean type in place of core's user-created blocks.
I think that we could learn a lot from the UI and filtering/sorting options available in your FC module. I think that the manual "pick list" functionality that's included in FC is awesome too - but we've been thinking of using a separate Bean type for that feature, in part b/c it makes managing large #s of Bean instances a bit easier when they are broken out a bit more by type. (As a side note, I'd love to see a simple "tagging" feature included with the Bean module, so that organizing Bean instances would be easier in the UI.)
Anyway, we'd love to connect with you on this. Let's meet up in the issue queues. Please let us know if you have any ideas for how we can improve upon this module!!
Response :)
Responding by email didn't get it back in the comments, so pasting here :)
> Hi Kristen,
Hey! Thanks for the speedy response :)
> You have received a comment on the post "Views Without Views… Introducing
> "Relevant Content Bean"" from ThinkShout.
>
> ----
> Yes!
> Nice to hear from you, Kristen. In short, yes, it'd be great to join
> forces.
>
> I hadn't seen the FC module before we started work on RCB - but we've been
> pretty hooked on the Bean module for a couple of months, so that's where we
> started in tackling this problem. One thing that I didn't mention in this
> post is that we've pretty much stopped using the core Block tools on all
> new projects. And by that I mean that we train clients to manage block
> placement with with the Context module - and we use a simple Bean type in place of
> core's user-created blocks.
Totally agreed. I just started using Bean and *love* it. I won't go back to regular blocks for client content ;) I imagine blocks will be entities in Drupal 8, but Bean is a great module for 7.
> I think that we could learn a lot from the UI and filtering/sorting options
> available in your FC module. I think that the manual "pick list"
> functionality that's included in FC is awesome too - but we've been
> thinking of using a separate Bean type for that feature, in part b/c it makes
> managing large #s of Bean instances a bit easier when they are broken out a bit more
> by type. (As a side note, I'd love to see a simple "tagging" feature
> included with the Bean module, so that organizing Bean instances would be easier in
> the UI.)
Ya, the number of options in FC has grown over the years and there are some handy ones. One issue that I still need to tackle is performance, though... I don't have any caching implemented so it's currently not good for big sites. Would be interested to know if you've dealt with this (I haven't looked at your module code yet).
> Anyway, we'd love to connect with you on this. Let's meet up in the issue
> queues. Please let us know if you have any ideas for how we can improve
> upon this module!!
Yes, this sounds interesting since I love Beans ;) I'm not sure what the best "next steps" are... perhaps I will try out your module and check the code and see if there is a logical next step.
Definitely going to have to
Definitely going to have to try this out!
Heavy queries?
This sounds awfully like a simple alternative to the "More like this" functionality for ApacheSolr and SearchAPI. Do you find that the queries get heavy when the term filter is used?
We haven't tested it on
We haven't tested it on really large numbers of nodes yet - so I can't speak to the performance. And to Kristen's point, we haven't implemented any caching.
I know that the guys over at Ombu Web are about to release an ApacheSolr Bean module that might address this issue.
Awesome!
This is awesome! I love the way you used EntityFieldQueryRelevant. Brillant! I'm so proud. This is a great model for others to use for making powerful bean types.