Can't edit and save existing Bean type

Is this still an issue since that code has been commttted?

Sorry about that. I reverted that change. I was working on block entities in D8 and was making changes in the wrong window.

I just rolled rc3 which should be available soon

Having trouble recreating this error doing a manual test. Strange that the code is looking to do an insert in this case since it should be doing an update. Definitely would be good to start writing some more tests for the Bean UI.

I'm also unable to reproduce this.

@beanluc, can you try on a clean environment?

@beanluc you're using sqlite, right?

I thought I had posted this before, but I'll post it now, since i've been affected by the same (or a similar) bug. Running drush qd -y beantestsite bean will setup a Drupal installation with bean and its dependencies enabled. It will use sqlite as database by default. Once it's up and running, enable bean_admin_ui (drush or admin/modules). Then, visit admin/structure/block-types and create a block type. It will take you back to admin/structure/block-types and nothing will be shown. Yet if you create another block type, the first one will show up, but not the new one.

I'm uploading a video.

Here's the video http://www.youtube.com/watch?v=aSRW9Xfphio
And I confirm it happens on mysql as well.
Yet it doesn't happen at all if the description is filled.

More info: it happens for the first block type I create, even if I set the description.

I'm running PHP 5.3.6-13ubuntu3.6 with Suhosin-Patch on Ubuntu 11.10. I've tested with sqlite 2.8.17 and mysql 14.14 Distrib 5.1.61. I'm running lighttpd, but I don't think the web server is responsible for this.

tagging as Release blocker.

Thanks @barraponto the video was perfect.

I was able to reproduce this in RC3. I just released RC4 which no longer has the issue. http://drupal.org/node/1538818

I can confirm I couldn't replicate this in a fresh sandbox running RC5.

@beanluc are you testing on a fresh sandbox each time?

I'll tested this module for a few days without seeing this and as mentioned in #20, it should have been fixed. @beanluc, do you have time to test it one more time?

OK, what db server is this site running on? And could you do a 'DESCRIBE bean_type' or the equivalent for your db server type and post it? Perhaps the hook_update() that fixed it failed?

It looks like comment #25 beanluc says it works fine on new sites, It's the sites with older versions that do not.

I get a blank white screen when attempting to edit a bean type. This did not occur when bean was initially installed and it was used successfully for a few weeks. Several modules were installed since. Here is some information on our server.

Drupal 7.16
Bean 7.x-1.0-rc6
PHP Version 5.3.3
Apache 2.0 Handler
mysql 5.1.52

sorry @mhoff, but that doesn't seem to be a Bean issue. Please reopen if you figure out steps to reproduce the bug. Also, if you find it is a compatibilty issue with another module, open a new issue.

I've find how to fix this issue.
I think the problem was due to the multilingual system.

bean_admin_ui.admin.inc file row 85

before
elseif (!method_exists($bean_type, 'getExportStatus') || $bean_type->getExportStatus() == 'Normal') {

after
elseif (!method_exists($bean_type, 'getExportStatus') || $bean_type->getExportStatus() == t('Normal')) {

Can you confirm?

Here's a patch for enricotersi's suggestion. Reading through the code it looks correct.

Lets add some tests to confirm it works correctly.

I've found another way to trigger the integrity constraint violation. If a bean type has been exported to a feature, and modifications are later made to the bean structure, the export status will change to "Overridden". However, the conditional logic only triggers $form['new']['#value'] = FALSE if the bean type does not have an export status, or has an export status of t('Normal').

The error is generated by going to /admin/structure/block-types/manage/<bean>/edit and clicking "Save Block type" when a block type is in Overridden status. The code attempts to insert a new bean type because $form_state['values']['new'] is set to TRUE, when it should be FALSE.

This can be fixed by either including Overridden, or disabling the Save button when in the Overridden state. I think including Overridden is better, since it allows a site builder to modify a bean name or description when Overridden. However we need to ensure machine_name is not modified, otherwise it will break the exported feature.

See the updated patch. I'd appreciate your feedback.

Just found a bug in patch #35 when creating a new bean type. I'll post an update shortly.

Ok, this new patch seems to be working as I would expect. When creating a bean type, an error was generated due to the $bean_type->getExportStatus() == t('Overridden') code.

The export_status index doesn't exist until the bean type has been saved, so I added a check to getExportStatus to determine if it is set. I also modified the conditional to use an in_array instead of multiple ORs.

I've looked at the code a little more closely to see if there was a way I could avoid modifying getExportStatus. I was able to do so, but there are a couple of things about the existing code that make no sense.

FIrst, if visiting the admin form for an existing bean type, the "Delete Block type" button is unset if export_status is Normal. Why? I can go to admin/structure/block-types and click the "Delete" link to delete the bean type. Does not make sense why the link is available on the summary page, but not the edit page.

Second, the submit function sets a value for $form_state['redirect'] if the operation is revert or delete, but then six lines later, $form_state['redirect'] is changed. Why is $form_state['redirect'] set to a value, and then immediately modified? I can't see a reason why it would be.

I've made some changes to the previous patch that should resolve these issues.