Error 500 and timeout with product entity with more than 10 fields adding

No clue - I haven't tested the performance of the Field UI. Are you sure this isn't just a Drupal thing? Perhaps try adding 10 fields to a node type and seeing what happens. There's nothing in this code that should be specific to Drupal Commerce itself, but perhaps there's a performance issue in the product reference module's field injection. If there is, I'd have expected us to hit it earlier... we've had sites with many more fields on product types than 10.

We'll need to be able to reproduce the issue on a clean install of Commerce to debug.

It could indeed, though I don't know why that module would be a problem unless you were specifically using its forms. Let's move this issue to its queue.

Hm, this is strange. BPC does perform a form_alter on the field settings form, but it only adds one or two form elements ... a hunch: After field creation, BPC rebuilds the menu---could it be that the real culprit is some other module that makes the menu-rebuild die? Though in that case, we would expect that the problem persists. After you tried to add a field ...

The form alter isn't on the field overview but an individual field's settings form so that you can enable a field for BPC usage. It's targeted to the individual field form and so shouldn't introduce a performance problem in general usage. Must be something else going on.

Well, but the individual field settings page would have been the next one displayed, so this form_alter could, conceivably, have an effect.

What version fo BPC were you using, exactly?

Correction: BPC adds an instance setting, so it does NOT alter the form that is displayed first when adding a new field (but it does alter the one that is displayed first when adding an existing field).

Which makes it even less likely that BPC is the culprit here ...

I had the same issue and also resolved it through disabling BPC.

So this is definitely an issue. Reclassfiying as a bug and raising priority.

Hm, I still cannot reproduce the problem, regardless of how many fields I add. I also tried to apply the patch from #951098: tab_root_map and tab_parent_map notices undefined in _menu_translate(), just in case, but this did not create the problem, either.

@chasematterhorn: You did not apply that patch, right? How many fields do your product types have?

Just posting a "me too" on this issue. The 500 errors were PHP timeouts. I was able to "function" by upping the timeout to 3 minutes but as you can imagine waiting 2-3 minutes to add multiple fields to multiple product types gets old quick. I found this, diasabled BPC and was back in business.

(Side note: Product type cloning please. An option to add fields to multiple existing product types in one operation would also be handy and also help with keeping settings consistent where appropriate between product types.)

I still cannot reproduce this, sadly.

BUT: We do know that the problem must have something to do with the menu rebuild. BPC was doing a menu_rebuild() on instance creation, which MIGHT (though I don't quite see how) have triggered multiple rebuilds of the menu, leading to the time-out. I just committed a fix that delays the rebuild till the next page load (as commerce core does it since #1574746: Replace menu_rebuild() with variable_set('menu_rebuild_needed', TRUE) for better performance)---so this MIGHT solve the issue.

It would be great if someone who had the issue could try updating to the latest 7.x-1.x-dev version once it is rolled and see if the problem is solved.

maybe this will help you ....
http://rickchristie.com/blog/2011/note/apache-mod_fcgid-read-data-timeou...

greets

I came across this issue. During debug I found menu_rebuild() was being called for every field instance when a product type was saved.

I see there's a patch to 7.x-2.x that uses variable_set('menu_rebuild_needed', TRUE); instead.

That's better, however variable_set is still called multiple times per page load, flushing and rebuilding the entire variable cache uneccessarily.

The attached patch uses a static variable to check whether the variable hasn't already been set, prior to setting and requesting a menu_rebuild.