Hello Dave,

Project specification is looking very promising and Drupal does need replacement to its core block module. But I just wants to know how this module is different from boxes (http://drupal.org/project/boxes). As both are having similar kind of features. Boxes already provide exportable blocks so why not to develop "The ability to re-use the same block (multiple instances in the same theme, but with different visibility configuration)" for boxes ?



davexoxide’s picture


bangpound’s picture

Speak of the devil: I've developed Boxes plugins that let me use Ctools content types. This means I can use the "block" ctools content type as a way to clone existing blocks. Nodes and site-wide contact forms too. http://github.com/bangpound/ctoolscontentboxes

butler360’s picture


deverman’s picture

would like to know the difference too subscribing.

Dave Reid’s picture

All this is intended to be is just like the other core drop-in modules like where it will be experiment with new ideas and features to see what we can do to improve the existing module to improve it in D8.

There obviously hasn't been one 'golden' block management solution yet, so I'm intent on continuing experimentation here.

From my initial boxes test, this is also intended to help manage no just custom blocks, but blocks defined by other modules as well. Boxes is a reimplementation. Blocks 2.0 is intended to be core block module + awesome sauce + hacks.

Dave Reid’s picture

Title:Difference between boxes and block 2.0» Difference between block 2.0 and other block solutions (boxes, context, etc)
freighthouse’s picture

When will Block 2.0 become available?

barinder’s picture

In Drupal 8. See #5 Dave's reply.

freighthouse’s picture


bleen18’s picture

worth looking at multiblock as part of this discussion too ...

rickvug’s picture

Another new entry: Entity Block (http://drupal.org/sandbox/fabsor/1158058). Fieldable, exportable and "block type" bundles.

BenK’s picture

Interesting... subscribing

klonos’s picture

@Dave: ...since you intent to experiment on new features, here's an idea to keep in mind:

Provide custom block machine names (a-la content types' machine names)! Right now, the way core stores/handles this is only by providing an id (bid) and a title (used for display AFAIK). The reason behind this suggestion is to stop the "id=block-block-bid" theming madness. If this feature came to be we could have "id=block-block_machine_name" instead ;)

There is currently an effort to work around this issue in the Block class contrib module (which btw I vote to be in core) by allowing people to also define ids besides classes: #863554: Add ability to set a block's CSS ID

Thanx for considering this.

klonos’s picture

...a generally cool thing would be to merge Block class's features in Block 2.0 (and even cooler to then have it in core for D8)

klonos’s picture

...it turns out there's a core issue for my proposal too (...since 2008): #334759: Add machine names for custom blocks

sun’s picture

@Dave Reid: errrr, are you aware of http://drupal.org/project/block_api ?

wjaspers’s picture


lpalgarvio’s picture

Panels (Minipanels and Panels Everywhere), Context and Multiblock can do a lot of stuff... but i recon, i rather have a single module.

IMO it would be great if Panels would enter core in drupal 8.x or 9.x.

wjaspers’s picture

+1 on that.

The WSCCI (whiskey) initiative is pushing to get the Context module and some other functionality in core. (See: http://groups.drupal.org/wscci over at g.d.o).

Personally, I'd prefer Ctools' Contexts. Don't get me wrong, Context is a great module, but doesn't expose half the conditions Ctools provides.

zilverdistel’s picture

Interesting discussion ... I personally like the combination blocks + context module.

mrfelton’s picture

Also see the Bean module as well as several discussions that I've started, trying to get everyone one the same page and combining efforts in to one awesome bean/boxes/block_api/block 2.0/entity_block block solution!

#1186800: Similar module - differences from Bean module?
#1186802: Similar module - differences from Block API module?
#1190644: Duplicate / similar module - Bean vs Block Entity vs Block API

indytechcook’s picture

Adding some back reference about bean from #1186800: Similar module - differences from Bean module?

Our goals are really inline. We both want to provide a way to create block types, then create instances of the block types. You approached it from a modifying the current state while I approached it from a clean slate. My idea was to make the API first, then make the UI an implementation of the API. The plugins are how you create new block types. I chose making the blocks as content (hence entities) because of that's what they are becoming. This also gives us fields built in (but not needed for the blocks).

I turned the block into content. It has a separate home on the UI /block/add, it has separate permissions then the block types. Blocks types are bundles on blocks and are completely in code (except for the UI implementation which will be exportable). Not a huge array in code like features, but really in code. I chose the boxes plugin methodology of OO based plugins that will be replaced with the Plugin system that Larry is working on.

My goal was to make the block system how I would want it from a coding/framework perspective. After looking over you code, I see many places I need to add to my code (thanks!) to make it more inline with the current block system.

Dave Reid’s picture

Status:Active» Closed (won't fix)

Shutting down module development and closing issues.