Using hook_entity_info_alter to add bundles results in Notices on manage fields

Subscribe

Happens here with Redirect module for D7.

I remember that I've seen that issue sometimes myself, but wasn't able to reproduce it right now.

Anyway, thanks for all the investigation. Sounds like a weird cache-rebuilding issue, i.e. entity load triggers the field API info to be rebuilt, which in affect is rebuilt with an incomplete hook-entity-info?

Howsoever, I agree with you that the current workaround is not optimal and might cause problems like this, so we should change that.

However, does the full entity really need to be loaded? It seems that we only need the bundle key and the label. Presumably, those are things that could be hard coded in the module using the API -- the module author can be expected to know which table to access and which fields are the key and label, so it could be a direct database query rather than a function call.

Yep, it's unfortunate but perhaps the only way to go. I'm unsure whether the label is used at all, but it's documented. Anyway, as in our case the bundle is an entity type we have most of the information anyway but can't read it is it sits in hook-entity-info too.

While thinking about that, I've come up with another idea. So what about this:
* Let's implement an entity-info-alter hook by the entity API which cares about writing all the necessary bundle information. We can use hook_module_implements_alter() to make sure we are the last alter hook that runs and complete the entity information as necessary.
* At this point the static cache from entity_get_info() should equal the usual, completed entity info. This should fix any cache-rebuilding issues, though doesn't help the RDF module issue.
* Having the entity API caring about the bundle-entity info should not only make it easier for devs, moreover we have to do all the module_implements_alter trickery only once and don't have to burden each dev making use of the API doing so.

@RDF issue:
The problem is basically the same as the entity API faces here. The module assumes during entity-info-alter that the information there is complete and works with that, but that's not the case. If we implement the above work-a-round for the entity API though, we can easily care about the RDF module by ensuring it is the last one called. Actually it should try to enforce this on its own though.

A non-generic fix for testing this approach for profile2 should be that:

function profile2_module_implements_alter(&$implementations, $hook) {
  if ($hook == 'entity_info_alter') {
    // Move my_module_rdf_mapping() to the end of the list. module_implements()
    // iterates through $implementations with a foreach loop which PHP iterates
    // in the order that the items were added, so to move an item to the end of
    // the array, we remove it and then add it.
    $group = $implementations['profile2'];
    unset($implementations['profile2']);
    $implementations['profile2'] = $group;
  }
}

Maybe, you could test whether this fixes this issue with a module causing the notice? If so, we just need to make sure RDF module comes even later and we should be fine.

ok, found the problem. See #1069318-5: Notice: Undefined index: field_collection_item in field_info_instances().

Let's implement the fix from here in a generic function inside the entity API.

ok, I took first stab on implementing that.

As not only entity_load() calls but also field collection itself trigger field-info rebuilding during info-alter, a generic entity-bundle-info routine doesn't suffice. We also need to ensure the field-info cache is cleared after field-collection has added its bundles.

Attached patches work for me.
TODO:
* update the 'entity_test' module and add in admin bundle-info as example
* update the docs and point to 'entity_test' as example implemenation without entity admin ui
* auto-generate the admin bundle-info for modules using the entity API admin ui -> makes the profile2 patch obsolete

Looks like this fix for the other contrib modules could break modules that actually use data from entity_get_info() but don't want to depend on Entity API.

>Should Entity use a "private" function from the Field module? My understanding is that it goes against coding convention to use "private" functions defined by other modules, even though these aren't really private.

Yep, we shouldn't. But we cannot use the public function field_info_cache_clear() as it clears the entity cache, what is obviously not a good idea to do during entity-cache-building.

>Looks like this fix for the other contrib modules could break modules that actually use data from entity_get_info() but don't want to depend on Entity API.

Why should they break!? Could you elaborate on that?

ok, I came up with a simpler fix, which doesn't unnecessarily change the API.

Attached patch fixes the problems for me with field-collection + should do it generally.

fago: @ http://drupal.org/files/issues/entity_bundle_notice.patch
+ // Move the our hook implementation to the bottom.

fixed that

in the above patch, modules keep attaching their bundles on their own as they do now.

@linclark: ah I see, you are referring to the rdf-module issue, being #1092192: Using hook_entity_info_alter to add the bundles prevents some modules from altering entities.
Yep, this patch only fixes this issue, but not the rdf-module issue. Let's deal with that issue over there.

As #12 worked fine for me, I've committed it.