Unless I'm missing something, the only way to get to the Bean create page at the moment is to type the URL /block/add into the address bar. No link to this page shows up in the admin_menu bar.

If you go to /admin/content/blocks, you get a list of the blocks, but there is no 'Add block' link (I'm comparing to /admin/content/node where there is an 'Add content' link at the top of the page)

Might be worth looking at the Boxes module, which adds a 'Add box' link into both the menu at /admin/structure/block/box-add/simple as well as injecting a 'Add box' link into the top of the Blocks page at /admin/structure/block, next to the 'Add Block' page.

I saw that you had another ticket about replacing the core blocks with beans - #1164056: Add module to override core block add - perhaps things would make more sense then, since at the moment things just seem to be a little hidden.


indytechcook’s picture

The add block is probably a good idea ad admin/content/blocks.

The block/add should be in the navigation menu.

mrfelton’s picture

Status: Active » Needs review
2.47 KB

Attached patch moves the block creation stuff under /admin/structure/block which seems to make more sense as you can then get to all the Bean stuff in the same place as other Block related stuff. It also adds a local action for 'Add Bean', which gets the 'Add Bean' link into the main blocks admin page. This is very similar to how Boxes and Block API do it.

indytechcook’s picture

Status: Needs review » Closed (works as designed)

I happen to disagree with putting the bean/block add/edit pages with the block types. The beans are content, not configuration. They should live under block/%/edit and not under admin. This also eliminates the need for the end user to require admin level permissions to add the content.

This module is a fundamental shift in how blocks should be thought about. Nodes aren't stored with the content types.

Keep up your good work!

mrfelton’s picture

Status: Closed (works as designed) » Active

Fair enough about moving the URL into the admin area. I see where you're coming from and I'm not overly fussy either way on that point. But, I do think it's an important UI improvement to get an 'Add bean/Block' link onto the list page, which is what this ticket was originally about. I got a little sidetracked! Wether that link goes onto the blocks page at /admin/structure/block or the bean overview page at /admin/content/blocks I'm not sure, but it needs to be somewhere.

I don't use the Navigation menu, and the link to add new blocks doesn't show in the admin menu or in the admin sidebar. The only way I can get to it is by typing in the URL.

indytechcook’s picture

Category: feature » bug

Oh yes, you are right about the link. My bad. That used to be in there before I did the refactor and it needs to be back so I'll change to a bug.

mrfelton’s picture

Status: Active » Needs review
921 bytes

Attached patch adds a local action into the block admin page, providing an 'Add bean' link.

mrfelton’s picture

With the improvements that were made in #1184498: Improvements to the bean administration page I'm not sure that a local action on the main blocks admin page is required any longer. We are treating beans more like content than standard blocks are. We have a dedicated bean management section. Although, since the main purpose of this module is to create blocks, it may still make sense to have a '+ add bean' link on the block admin page.

What do you think?

indytechcook’s picture

I agree, but those changes are a little larger scope I think and not quite vetted. I really want to be able to replace the creation of all blocks @see #1164056: Add module to override core block add. Let's move the discussion over there for the larger discussion.

I really don't want "bean" to be in the UI anywhere. I think it would just be confusing. Possible short term fix would be to change the "Add block" link to go to the block/add page?


mrfelton’s picture

Agreed, 'bean' should not be in the UI anywhere, since users think in terms of blocks, and that is essentially what we are creating. The reason I suggested '+ Add bean' is because '+ Add block' is already taken by the core block module.

'+ Add box' - taken by the boxes module

'+ Add custom block' - taken by the block_api module.

Rerouting core's '+ add block' link could work in conjunction with #1164056: Add module to override core block add so lets consider this in that discussion. If we still want to add a link on the main blocks admin page outside of the scope of replacing the entire core blocks module, then we need to think of a sensible name for the link. I don't think its fair to reroute core's "Add block" link unless we are completely overriding the core blocks module.

indytechcook’s picture

Cross posting #1389452: Add a link 'Add bean block' in 'admin/structure/block' page

I would rather just alter the current menu tab "admin/structure/block/add" to point to block/add. This could be done wither as a permission or we can great a new admin configuration page for beans.

If it's a permission then it would be "allow access to core block add page"

Any thoughts? I am against using the word "bean" in the block UI.

indytechcook’s picture

Status: Needs review » Needs work

changing status

indytechcook’s picture

Comment from other issue:

This would be a greate UX win. Whenever I enable bean, I browse to the normal block admin page, thinking something is wrong when I don't see any new add links.

For this to be a MENU_LOCAL_TASK type link (which is what the block module, and boxes use), the bean add path will need to be moved to admin/structure/block/bean-add/plugin_key or similar.

indytechcook’s picture

Issue tags: +Release blocker

Adding tag

beanluc’s picture

With regard to the points above that "add block", "add custom block", "add foo block" etc aren't available to use for Beans on the blocks admin page, what about

+ Add fieldable block


brantwynn’s picture

Beans as block entities do not extend blocks used in core - are not the same system of blocks at all.

Considering that editing them is taken care of under their own menu I'm unsure if adding a link to 'admin/content/blocks' from inside block admin would be helpful or more confusing. Thoughts?

mrfelton’s picture

@brantwynn - beans do not extend blocks, but they do provide blocks, which can be maned on the /admin/build/blocks page. Unless you are using Panels or Context, this is how you would manage these blocks.

brantwynn’s picture

Yes, as I said "Beans as block entities do not extend blocks used in core" - what I am wondering about is if adding an extra link on the block admin page would confuse users? I am not sure if it woud be more helpful or confusing to add a link there since the bean system is very different than what comes with core block.

mrfelton’s picture

I think the link is important, because 90% of the time, I would image the whole point of creating a Bean is so that you can add it to some region for it to be displayed. Granted, people may be using Panels or Contet to manage their block rather than Core's rather limiting block management system, but we should support Core at least, and possibly consider adding a link to Context UI if that is enabled?

If the link was something like 'Manage blocks' with some title text that said something like 'Use the core blocks system to add blocks to regions' would that still be confusing?

beanluc’s picture

if adding an extra link on the block admin page would confuse users?

Modules which I know about offhand which do this:
Menu Block
Block API

It seems completely sensible to me. If I install a module which is specifically about Blocks, it will be no surprise and actually now expected behavior to find on the blocks management page a link for adding an instance of "modulename block". I mean, *everybody* uses Menu Block, so, I'd say that that convention is very well defined here in 2012.

brantwynn’s picture

Category: bug » feature

I've never used these modules so I wouldn't know. Ultimately though I think we can all agree that this is a sensible feature request.

Adam S’s picture

I'm confused here. I just installed beans and understand what the menu items do. However, that is because I had to click through them a couple of times -- it wasn't self evident.

If beans are not blocks because beans are content and blocks are configuration then beans might as well be called beans and not blocks.

The content menu could be

Add content
Add bean (with a submenu for the Add bean menu item to contain all available beans that can be added.)

This to me would be intuitive and eliminate the confusion about what is bean content and what is block configuration.

beanluc’s picture

Adam S:

Beans *are* blocks. So are the blocks which are provided by all the other modules which don't add an "add new *** type block" to the Blocks page.

I think that if you're using Beans to implement content, you'd be better off just using nodes.

If you want *content in blocks*, there are a lot of ways to get this - Panels, Views, Nodes In Block, etc. But, you *still* want that content *as content*, right?

Beans, in my opinion, best satisfy the use-case of giving a non-admin, content-manager type person a nice field-based UI for updating the contents of specific blocks in the site, when that block's contents must be dynamic, and possibly related to other data in the site, without expecting that content-manager person to have deep Drupal admin or developer knowledge and experience.

Bean lets you implement a block using a fieldable entity, rather than (take your pick) bare, static HTML or a custom module for dynamic block content. Beans gives you a lot of the functionality available in nodes (fields, widgets and validation), but for a totally different use-case.

Here's a specific example: I have a Bean which gives my content-manager person a way to change the image and text in a prominent site block, and change which node that block links to. The person uses a field-based UI ("Edit Bean") to remove the image, replace it with another, update the text, and select a new nodereference for linking. This person would otherwise have to be an admin (dangerous), call an admin (annoying and expensive), or do this with WYSIWYG (unreliable). This person doesn't even need access to Admin -> Structure -> Blocks with this solution. That's good, because, that person isn't someone who should be creating new Blocks and filling the regions with them. That would wreck their site.

If beans are not blocks because beans are content and blocks are configuration then beans might as well be called beans and not blocks.

* If "beans are content" then they're being mis-used (in my opinion), or they're at best un-necessary and at worst un-usable as content (think about Search, promoting to homepage, listing content (nodes) with Views, other content features which depend on nodes). I know that each Bean has a "View" page, but, that's not a content page. Personally, I do my best to bar any access to those "View Bean" pages.
* "blocks are configuration" - They're more than configuration, because they're (at least) visible data and (possibly) dynamic too. I'm speaking of all types of blocks in general, not of static "Add block" type blocks specifically. That they're more than configuration doesn't mean they're content.
* "If beans are not blocks" - but they are. They're a special kind of block, among many, many special kinds of blocks implemented by many, many modules. Not all those other special kinds need an "Add (Views|Mini-Panel|Login|weather|tagcloud|whatever) type block" link on the blocks page, but, we're arguing that *this* type could benefit from such - if only to make site-builders' jobs easier and to help reduce this very confusion.

Adam S’s picture

The beans are content, not configuration.

This is quoting the module maintainer of Bean from comment #3. So... I'm not sure what that means. I think that there might be some grey area discerning what is content and what is configuration.

There is nothing wrong with having 10 instances each of 6 different Bean types for editors to work with in a website, except the blocks UI might get a little cluttered. On the other hand, I really don't like the idea of using nodes for everything that doesn't require comments, revisions, ect.. All this stuff is like an appendix under many use cases -- gets carried everywhere, doesn't do anything and can explode at anytime.

None of this is the issue I'm address. I'm talking about the UI for the administrator. Beans might be blocks but if they are called beans in the Admin Menu, it would be a lot more intuitive for first time users.

steinmb’s picture

Status: Needs work » Active

First time Bean user (RC6). +1 on the current links and path state. It work's just like the file_entity module (and prob more) and that is a good thing. Bean create a lightweight entity and should behave as one. Mixing names and/or links with core blocks and stuff only add confusion. We can continue discussing this, but personally do I not see this as a show stopper for rolling a stable 1.0 voting for removal of relase blocker tag.

indytechcook’s picture

Issue tags: -Release blocker

Yeah, it's not a blocker really. These would be minor changes.