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.
This module should override the core custom block. Replacing the core custom blocks with a simple plugin with a single text area.
Comments
Comment #1
quicksketch+1. I've love a drop-in replacement to the normal, totally inadequate custom blocks system. Having the ability to still add a "normal" custom block is confusing (though not nearly as confusing as not being able to find how to add a Bean-based blocks, hidden away under block/add). Solving both these problems at once would be fantastic.
Comment #2
indytechcook CreditAttribution: indytechcook commentedI agree that the UX need improvement. Better documentation will help. I actually have a few hours allocated next week to do clean up on a few modules from energy.gov. I"m very open to recommendations.
I have a branch locally that I've been playing with. No real progress.
My first thought is just having admin/structure/block/add show what /block/add currently does.
I do feel that the instances of the block types (beans/blocks) are content and the block types are structure. The separation between structure and content is important to me and isn't evident enough in Drupal currently. That's a different story though.
Comment #3
quicksketchI agree here. I think we can look to Taxonomy Terms for a similar example (though it doesn't have multiple types like Beans). In Taxonomy terms are still added at
admin/content/taxonomy/[vocabulary]/add
even though terms are edited like other entities on a non-admin path (term/[tid]/edit
for terms).In the event there's only one term type, we probably should emulate node types and immediately redirect the user to add the only term type available (which is what node/add does when a user only has permission to one type).
Comment #4
indytechcook CreditAttribution: indytechcook commentedI actually followed the node structure for my URLS. I'm really struggling with how to separate content form structure. I followed the admin/structure/block/types for block types and block/bid and block/add for blocks.
I have a more difficult time associated block types/blocks with taxonomy. I feel a combination of nodes/terms probably will work the best. We will need to keep /admin/structure/blocks/add just for compatibility. But block/add should stil be there. A user shouldn't need access to the admin pages to add a block. This keep the page creation to be 100% "content".
It already does this if you go to block/add with no types. :)
I'm really open to suggestions here, I just want to make sure we think it out.
Comment #5
quicksketchHow are blocks not an admin task if the only way they can actually use that block is to have access to admin/structure/blocks, or some other system like Context (admin/structure/context) or Panels (admin/structure/pages)? I think idealizing blocks as not necessarily being an admin-task may have noble intentions but is actually be an edge case. Right now every system that would use the blocks created with Bean would almost certainly be administrative.
Comment #6
indytechcook CreditAttribution: indytechcook commentedBlock types are admin tasks. The instances of the blocks are content. The Editors that are building layout pages. If they are using panel nodes node/nid/edit or page ctype with the block reference module node/nid/edit it's content. The use case is for landing pages that contain multiple rows of blocks.
Now that I think of it, integration with panels nodes would be more work anyway.
Is there an issue with having to places to add blocks? admin/structure/blocks/add for constancy but block/add (since its' already there) for content? It's just a matter of menu altering the callback right?
Comment #7
indytechcook CreditAttribution: indytechcook commentedCross linking #1216580: Ability to specify block caching level
Comment #8
indytechcook CreditAttribution: indytechcook commentedCross post #1389452: Add a link 'Add bean block' in 'admin/structure/block' page