Install bean 7.x-1.0-beta8 and the admin admin ui module. Create a new bean type. Try and add fields to it. Clicking on the edit, manage fields, and manage display links all and up presenting the same form to the user (the main edit form) which only allows you to edit the title.

1. http://dev.example.com/admin/structure/block/types/manage/optics-banner-...

2. http://dev.example.com/admin/structure/block/types/manage/optics-banner-...

3. http://dev.example.com/admin/structure/block/types/manage/optics-banner-...

The links look correct, the form that gets displayed is incorrect in all cases except for 1.

Clearing the cache twice resolved the problem.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mrfelton’s picture

Links didn't come out well in that post. Should have read.

1. /admin/structure/block/types/manage/optics-banner-content/edit
2. /admin/structure/block/types/manage/optics-banner-content/fields
3. /admin/structure/block/types/manage/optics-banner-content/display
indytechcook’s picture

Status: Active » Postponed (maintainer needs more info)

I'm not sure I follow. Can you elaborate on "the form that gets displayed is incorrect in all cases except for 1" Maybe screenshots.

mrfelton’s picture

All pages show what /admin/structure/block/types/manage/optics-banner-content/edit is supposed to show (a form that allows editing the name of the bean type only)

Maciej Lukianski’s picture

Status: Active » Postponed (maintainer needs more info)

Hi, I can add to that.

When on a new install I installe a module with custom bean plugin, I could not edit the bean type it provided. A message is displayed "This block cannot be edited". And I could not add fields to the bean type (the whole manage fields form was missing)

Only when You create at least one bean type via the UI, you are able to add fields to beans wich come from code.

indytechcook’s picture

Status: Postponed (maintainer needs more info) » Active

Yeah, I saw that also. awesome.

indytechcook’s picture

Version: 7.x-1.0-beta8 » 7.x-1.x-dev
Status: Postponed (maintainer needs more info) » Active
Issue tags: +Release blocker

Adding release blocker tag

PJnes’s picture

Clearing cache sorted the problem for me as well.

willvincent’s picture

I suspect the reason for this has to do with the call to block_flush_caches() in the save method of bean.core.inc.

On save block caches are flushed, but on module enable they're probably not being flushed.

There are a couple ways this could be addressed:

1) Modules that provide custom beans implement a hook_enable() to clear cache.

or better

2) Bean implements a hook_modules_enabled() that checks if the just enabled module(s) provide beans, and if so flushes the block cache. or just flushes the block cache regardless whenever the hook is fired.

I think the second approach is better as it doesn't require implementing another hook in modules that provide custom beans, since bean itself would handle clearing the cache.

indytechcook’s picture

I like the 2nd options. Great idea and great catch!

willvincent’s picture

I've tried several variations of option 2, ultimately the most heavy handed approach:

/**
 * Implements hook_modules_enabled().
 */
function bean_modules_enabled($modules) {
  $beans_found = FALSE;
  foreach ($modules as $module) {
    // If module implements hook_bean_types(), clear caches for each bean type it provides.
    if (function_exists($module .'_bean_types')) {
      $beans_found = TRUE;
    }
  }
  // Flush block caches if any of the enabled modules provide bean types.
  if ($beans_found) {
    drupal_flush_all_caches();
  }
}

And still no joy.. While I think we're probably on the right track here, there's got to be something else we're missing. The majority of what drupal_flush_all_chaches() does is already done during module enabling anyway, so this really shouldn't be necessary though.

willvincent’s picture

Alright, I've got this sorted out.

It's a bit heavy handed, in that it calls drupal_flush_all_caches() and drupal_static_reset(), but it only does so if a module has just been enabled that provides at least one bean type.

/**
 * Implements hook_modules_enabled().
 */
function bean_admin_ui_modules_enabled($modules) {
  $beans_found = FALSE;
  foreach ($modules as $module) {
    if (function_exists($module .'_bean_types')) {
      $beans_found = TRUE;
    }
  }
  // Flush caches and reset statics if any of the enabled modules provide bean types.
  if ($beans_found) {
    drupal_flush_all_caches();
    drupal_static_reset();
  }
}

I also moved it into the bean_admin_ui module as it's only relevant to the UI, not Beans created entirely in code.

willvincent’s picture

Status: Active » Needs review
willvincent’s picture

Better approach, simply calls bean_reset().

indytechcook’s picture

Issue tags: +Needs tests

@willvincent, This looks good. When the tests run I'll commit it.

In the mean time can you add a test to make sure this doesn't occur again?

willvincent’s picture

Hmm.. I have no idea how to write a test for this

indytechcook’s picture

@willvincent. See the original description.

Install bean 7.x-1.0-beta8 and the admin admin ui module. Create a new bean type. Try and add fields to it. Clicking on the edit, manage fields, and manage display links all and up presenting the same form to the user (the main edit form) which only allows you to edit the title.

Just do all that in the simple test and make sure the links to go the correct place. I just want to make sure this doesn't get rebroken in the future.

indytechcook’s picture

barraponto’s picture

Status: Fixed » Needs work

I'm using rc3 and have been bitten by this bug. I'm using only bean and bean_admin_ui.

willvincent’s picture

Try the dev version.

indytechcook’s picture

Status: Needs work » Postponed (maintainer needs more info)

@barraponto, did you try the dev version?

barraponto’s picture

Assigned: Unassigned » barraponto

not yet, i'll assign this to myself and test it.

alexweber’s picture

Status: Postponed (maintainer needs more info) » Fixed

Works for me! :)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

lilbebel’s picture

Awesome. Thank you!

DamienMcKenna’s picture

Version: 7.x-1.x-dev » 7.x-1.0
Status: Closed (fixed) » Needs review
FileSize
721 bytes

Sorry to have to re-open this issue, but the patch in #13 has nothing to do with the problem, which still persists in 1.0. To be clear, this is a problem when creating new block types in the Bean Admin UI module pages, it has nothing to do with enabling that module.

Scenario:

  • Enable the Bean and Bean Admin UI modules.
  • Go to admin/structure/block-types/add and create a new block type.
  • The browser is returned to admin/structure/block-types, which lists the new block type the following links: Edit,Delete, manage fields and manage display.
  • Clicking the manage fields or manage display links loads the correct URLs but the page loads the edit form for the block type (i.e. to edit its name and description) and not the page requested.

What should happen is that the bean_admin_ui_type_form_submit() function should clear the appropriate caches so that the two new pages work.

This patch uses drupal_flush_all_caches() simply because neither running menu_rebuild() nor running bean_reset() was enough to make the new pages load.

Status: Needs review » Needs work

The last submitted patch, bean-n1354824-25.patch, failed testing.

DamienMcKenna’s picture

Version: 7.x-1.0 » 7.x-1.x-dev
DamienMcKenna’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests, -Release blocker

#25: bean-n1354824-25.patch queued for re-testing.

Status: Needs review » Needs work
Issue tags: +Needs tests, +Release blocker

The last submitted patch, bean-n1354824-25.patch, failed testing.

DamienMcKenna’s picture

Status: Needs work » Needs review
FileSize
721 bytes

Try again.

Status: Needs review » Needs work

The last submitted patch, bean-n1354824-25.patch, failed testing.

DamienMcKenna’s picture

Status: Needs work » Needs review
FileSize
597 bytes

*facepalm*. I created that patch from my local D7 install, not my checkout of Bean. This one should work.

barraponto’s picture

Status: Needs review » Reviewed & tested by the community

Just tested the patch and the steps to reproduce. Works ok.

indytechcook’s picture

Status: Reviewed & tested by the community » Needs work

I was really trying to avoid a full cache flush. Oh well.

I'd still rather see the specific caches that need clearing in bean_admin_ui_bean_cache_clear() then we can still call bean_reset.

I've committed this for now but keeping the issue open to see if we can find a better way.

EDIT:

Commit: http://drupal.org/commitlog/commit/22232/29ca8eefc61bca990acca820f1941b9...

Mile23’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
702 bytes

I noticed that #32 is in 1.11, updated to 1.13 and it's in there, like #34 mentions.

It's important to update the caches, but it might be better to use a targeted approach more like bean_reset(TRUE, FALSE);

I say this because I'm working on a site with ~37k beans and ~380k nodes. drupal_flush_all_caches() means that all of these pieces of content have to be cached on the redirect back to the types listing page because of another caching issue with menu_rebuild(). Rebuilding the page takes an hour or so.

In an ideal world, we'd have hook_bean_clear_cache_for_type($type) and hook_clear_cache_for_bean($bean), and then other modules could adapt to the use-case.