Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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 ?
Thanks
Comments
Comment #1
davidburnssubscribe
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedSpeak 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
Comment #3
butler360 CreditAttribution: butler360 commentedSubscribing.
Comment #4
deverman CreditAttribution: deverman commentedwould like to know the difference too subscribing.
Comment #5
Dave ReidAll 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.
http://drupal.org/project/contact
http://drupal.org/project/filter
http://drupal.org/project/path
http://drupal.org/project/simpletest
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.
Comment #6
Dave ReidComment #7
jmcerda CreditAttribution: jmcerda commentedWhen will Block 2.0 become available?
Comment #8
barinder CreditAttribution: barinder commentedIn Drupal 8. See #5 Dave's reply.
Comment #9
jmcerda CreditAttribution: jmcerda commentednice
Comment #10
bleen CreditAttribution: bleen commentedworth looking at multiblock as part of this discussion too ...
Comment #11
rickvug CreditAttribution: rickvug commentedAnother new entry: Entity Block (http://drupal.org/sandbox/fabsor/1158058). Fieldable, exportable and "block type" bundles.
Comment #12
BenK CreditAttribution: BenK commentedInteresting... subscribing
Comment #13
klonos@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.
Comment #14
klonos...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)
Comment #15
klonos...it turns out there's a core issue for my proposal too (...since 2008): #334759: Add machine names for custom blocks
Comment #16
sun@Dave Reid: errrr, are you aware of http://drupal.org/project/block_api ?
Comment #17
wjaspers CreditAttribution: wjaspers commentedsubscribe
Comment #18
lpalgarvio CreditAttribution: lpalgarvio commentedPanels (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.
Comment #19
wjaspers CreditAttribution: wjaspers commented+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.
Comment #20
zilverdistel CreditAttribution: zilverdistel commentedInteresting discussion ... I personally like the combination blocks + context module.
Comment #21
mrfelton CreditAttribution: mrfelton commentedAlso 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
Comment #22
indytechcook CreditAttribution: indytechcook commentedAdding some back reference about bean from #1186800: Similar module - differences from Bean module?
Comment #23
Dave ReidShutting down module development and closing issues.