Updated: Comment #20
Modules that alter an existing non-configurable field type to be configurable, should also set the provider value to their own name, because field_sync_field_status() will automatically de-activate any field that is of those types and if those types still have Core as their provider. This applies to the email and entity_reference field types.
Modules that implement hook_field_info_alter() to make an entity type 'theirs', must also update the provider value.
None.
None.
None.
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | interdiff.txt | 2.52 KB | plopesc |
| #17 | field_provider-2115291-17.patch | 3.58 KB | plopesc |
| #17 | field_provider-2115291-17-test-only.patch | 2.52 KB | plopesc |
| #14 | field_provider.png | 88.04 KB | plopesc |
| #11 | entity_reference_options-2115291-11.patch | 714 bytes | agentrickard |
Comments
Comment #1
plopescAttaching patch.
Comment #2
amateescu commentedHow do you keep finding all these things? :)
Comment #3
agentrickardHaving tests in contrib helps. Confirming this patch works.
There is a serious follow-up need, though, as none of the ER tests currenty catch this bug.
Comment #4
agentrickardThis is a release blocker.
Comment #5
aspilicious commentedThis clearly needs a test
Comment #6
berdirThe fact that entity_reference still relies on hook_options_list() is a bug on it's own, it is deprecated in favor of AllowedValuesInterface. See #2015687: Convert field type to FieldType plugin for taxonomy module which does this for the taxonomy field.
I also think that "Core" is weird as a provider, IMHO, the component should be in there, maybe core.entity, or something like that. (Wouldn't work here either, of course).
Comment #7
agentrickardDo we have a change notice for that conversion? I couldn't find one. I'm ok turning this into a test-only patch issue.
Comment #8
berdirThere is https://drupal.org/node/2075873.
This might be a valid change, it is arguably the entity_reference.module that provides the configurable entity_reference field type. So this change might be valid. Just saying the reason the actual but here happens is because the field type hasn't been completely converted.
Comment #9
agentrickardThanks.
This fails with Node and User, which both seem to be using the new interface system. It just fails for field widget types other than autocomplete. So I suppose we need tests for that first.
Comment #10
mrconnerton commentedI am writing the test for this.
Comment #11
agentrickardUpdated patch. This should really go in without a test, as it's an API violation, not a testable bug.
Comment #12
amateescu commentedI agree with that.
Comment #13
swentel commentedRelated: #2131765: Fields are gone after field info rebuild - more field types suffer from this bug - date and email too.
Comment #14
plopescIncluding same line for email module.
Now, all field types are using its own module as provider, as you can see below:
Comment #15
Micha1111 commentedProblem not solved in dev and alpha5 ?
I have added this code line manually in file entity_reference.module:
$info['entity_reference']['provider'] = 'entity_reference';
But the error is still there.
Comment #16
berdirSetting to needs work for tests. Shouldn't be complicated, just take an existing test, rebuild the field information and check that the fields are still active.
Comment #17
plopescHello.
Patch rebuilding field info in field types affected by this patch to check that they don't dissapear.
I moved the last lines of
EmailFieldTestinside an if block because those lines break the testing when $entity is not created.Regards.
Comment #19
xanoOne of my (contrib) tests that relied on an ER field failed because of this. Applying the patch solves the patch failures. I also manually confirmed that the field is picked up by field API by checking the UI where it is displayed and be configured.
Setting to RTBC as per #11, #12, and the bot in #17.
Comment #20
xanoComment #21
catchCommitted/pushed to 8.x, thanks!