16

Bean, Boxes and Fieldable Panels Panes all provide similar functionality. I have trouble understanding what exactly the differences between them are.

What are their advantages/disadvantages compared to each other? Are they geared towards different use cases?

I want to use some kind of blocks in Panels to add custom content - content editors also need to be able to add content, in that sense the blocks I need are not pure configuration. But I also use Features...

Edit: I'll add what seem to be the main differences

Boxes

  • Largest userbase (~ 11500)
  • Treats blocks as configuration (i.e. the content ends up in your features)
  • Modules offering integration

Beans

  • Has recently become popular, ~1000 installs
  • Treats blocks as content, but allows exportability of their configuration via machine name (e.g. via Bean Panels)
  • Modules offering integration

Fieldable Panels Panes

  • Smallest userbase (~ 400)
  • From the author of Panels/Views/etc.
  • Panes cannot be used as regular blocks in theme regions like beans or boxes (I assume)
  • I wonder what the advantages over Bean mentioned here are ("offers additional features that makes it easier to empower content admins to lay out certain pages")
Improve this question

3 Answers 3

Reset to default
4

It's perfectly possible to make a D7 site without blocks if you can live without dashboard. Our new - content driven - site is being built on panels with workbench as a suitable (for us) alternative to dashboard. Arjan appears to already understand this.

On to the alternatives. Read Your site should be full of beans. The problem with boxes is the danger regarding overwriting existing content when using features. But read Fabian Franz's comment in the same article. Beans has many options. I'm not comfortable regarding management, scalability and performance. Hardcore developers that are fluent with panels use Fieldable Panels Panes. Fieldable Panels Panes lack documentation and examples. What should get everyones focus and effort for D8 is the wscci-initiative. It allows for REST-calls, including for example DELETE. This could permanently tackle the problem of overwriting site builder configuration on code rollouts.

Improve this answer
1
  • Thanks. Yes, I'd read that blog post, it's a good read, but it doesn't address everything I'd like to know ;). I have a feeling there are people who've tried some or all of these modules extensively and know their cons and pros. I'm now trying Bean with Bean Panels and Panels In-Place Editor. This allows for a quite user-friendly workflow.
    – arjan
    Commented Aug 19, 2012 at 22:41
1

for your purpose may be optimal to use views with some taxonomy: to one content type add terms for the place of panel, for that place make views block with filter this term and content type, then add this views-block on the place in panel, usually I make additional field for weight for this content type and in views I sort by weight, and editors never needed edit the panel to add/edit/remove content on this place - the views block select propper content for the place by term

Improve this answer
1
  • Thanks, that is a reasonable way to do things. In my case the blocks are meant for more 'sidebar-style' messages/content, so I don't want to use nodes (although it is possible the way you describe, of course). All three modules mentioned are ways of avoiding the nodes-as-blocks way of doing things...
    – arjan
    Commented Aug 19, 2012 at 23:07
0

Check out the nodeblock module. Being nodes they don't export via Features, but you might find it does what you need.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.