Add module to override core block add [#1164056]

Comment #1

he/him

CreditAttribution: quicksketch commented 10 September 2011 at 01:55

+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.

Log in or register to post comments

Comment #2

indytechcook CreditAttribution: indytechcook commented 10 September 2011 at 03:22

I 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.

Log in or register to post comments

Comment #3

quicksketch

he/him

CreditAttribution: quicksketch commented 10 September 2011 at 19:10

My first thought is just having admin/structure/block/add show what /block/add currently does.

I 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).

Log in or register to post comments

Comment #4

indytechcook CreditAttribution: indytechcook commented 11 September 2011 at 18:21

I 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".

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).

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.

Log in or register to post comments

Comment #5

quicksketch

he/him

CreditAttribution: quicksketch commented 12 September 2011 at 02:58

A user shouldn't need access to the admin pages to add a block.

How 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.

Log in or register to post comments

Comment #6

indytechcook CreditAttribution: indytechcook commented 23 September 2011 at 13:41

Block 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?