This bug happens in rather spesific circumstances only. When it happens there is bunch of notices like these:
Notice: Undefined index: widget types in field_info_widget_types() (line 501 of /var/www/d7/modules/field/field.info.inc).
Notice: Undefined index: field types in field_info_field_types() (line 476 of /var/www/d7/modules/field/field.info.inc).
After some debugging I figured that the bug can be reproduced by doing these 3 steps:
- create a module that adds any relation type with hook_relation_default_relation_types() implementation
- add a dependency from that module to relation module
- on a clean Drupal installation enable the custom module (with Drush - I didn't test the UI way)
Step 3. will then install relation, relation_endpoint, ctools and the newly created custom module. endpoint field is added to the relation type but without the default widget.
As a work-around this bug didn't occur if relation module is enabled before enabling the module with hook_relation_default_relation_types() implementation.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | 1936206-field_read-to-field_info-12.patch | 3.48 KB | naught101 |
| #11 | field_info_instance-1936206-11.patch | 388 bytes | mikran |
| #8 | patch_file_deleted.patch | 4.34 KB | mikran |
| #7 | tests_only-1936206-7.patch | 8.28 KB | mikran |
| #7 | fix-1936206-7.patch | 8.6 KB | mikran |
Comments
Comment #1
mikran commentedFurther testing showed that the issue was actually in specific relation type and not 'any relation type' as I had in bug report. What was special is that endpoint was a bundle that got created on custom_module_install and thus it wasn't available when relation was enabled and default relation types were created.
Comment #2
mikran commentedWhat I said in previous comment is totally not true. The real issue happens when defaults hook provides more than one relation type. Here is a test to prove this. Test should produce some warnings
Comment #3
mikran commentedComment #4
mikran commentedCan someone test the patch locally? This is very annoying
Comment #5
mikran commentedobviously it can't fail if it isn't run in the first place ...
Comment #7
mikran commentedI don't know why additional field_read_instance call fixes this, but here is a patch anyway.
Comment #8
mikran commentedand a patch without old patch file
Comment #9
naught101 commentedWFM, although I'm kind of surprised you can get away with just one test. Guess we can add more later. Do it!
Comment #10
mikran commentedI've committed this, not sure if it's an issue in d8
Comment #11
mikran commentedI'm getting test failures from feature modules because of this. Somehow the the fields added by a feature module require the static cache set by field_info_instance. Here is a patch that changes the added field_read_instance to field_info_instance.
I have no clue how to easily create a test to reproduce the error without actually using a feature module. I'll try to return to this later if I figure out something more.
Comment #12
naught101 commentedBoth https://api.drupal.org/api/drupal/modules!field!field.crud.inc/function/... and https://api.drupal.org/api/drupal/modules!field!field.crud.inc/function/... say that the field_info_* version is preferred, and they return the same thing, with extra info. So how about this instead:
Comment #13
mikran commentedLooks good and works well. So we shouldn't have ever used
field_read_instancehere.Comment #14
mikran commentedComment #16
busla commentedGreat mikran. Thanks for committing to this issue.
It was messing up my features. I had been trying to track down this issue for a while.
Comment #17
jelle_sThis breaks an install profile of mine that has relation types defined in code.
Here's the call stack:
So basically, here's what happens:
hook_entity_info(relation_entity_info) is called.relation_entity_infocallsrelation_get_typesrelation_get_typescallsrelation_type_ensure_instancewhich creates the instance of the FIRST relation typefield_info_extra_fieldsis called (I think by drupal core code)hook_field_extra_fields(entity_field_extra_fields) is called.entity_field_extra_fieldscallsentity_get_extra_fields_controllerfor each entity typeentity_get_extra_fields_controllerlooks like this:'extra fields controller class'defaults toEntityDefaultExtraFieldsController$static[$type]inentity_get_extra_fields_controllerstaysFALSEuntilEntityDefaultExtraFieldsController's constructor has finishedEntityDefaultExtraFieldsController's constructor callsentity_get_property_info($static[$type]is stillFALSE)entity_get_property_infocallsrelation_entity_property_info_alter($static[$type]is stillFALSE)relation_entity_property_info_altercallsrelation_type_ensure_instancewhich creates the instance of the SECOND relation type ($static[$type]is stillFALSE)field_info_extra_fieldsis called (I think by drupal core code) ($static[$type]is stillFALSE)hook_field_extra_fields(entity_field_extra_fields) is called. ($static[$type]is stillFALSE)entity_field_extra_fieldscallsentity_get_extra_fields_controllerfor each entity type ($static[$type]is stillFALSE)$static[$type]is stillFALSEentity_get_extra_fields_controllerreturnsFALSEFatal error: Call to a member function fieldExtraFields() on a non-objectQuite a long report but I hope it helps debug and fix the issue.
Comment #18
mikran commentedThat's not the same bug, please
reopenopen a new issue and try to reduce the list of steps a bit. Also, see (and test) this #1891356: D7: Reset drupal static caches when a module is enabled or disabled..Comment #19
mikran commented@Jelle_S I just encountered the same problem and the patch from #1891356: D7: Reset drupal static caches when a module is enabled or disabled. was indeed a working solution to it.
Comment #20
mikran commented