Entity reference doesn't update its field settings when referenced entity bundles are deleted

+++ b/core/modules/entity_reference/entity_reference.moduleundefined
@@ -470,3 +470,71 @@ function entity_reference_create_instance($entity_type, $bundle, $field_name, $f
+    foreach ($instance['settings']['handler_settings']['target_bundles'] as $delta => $target_bundle) {

Just in general I'm wondering whether it should be converted on the longrun to key/value with the target bundle. This for example results in a better diff at the end.

+++ b/core/modules/entity_reference/entity_reference.moduleundefined
@@ -470,3 +470,71 @@ function entity_reference_create_instance($entity_type, $bundle, $field_name, $f
+      if (empty($instance['settings']['handler_settings']['target_bundles'])) {
+        $instance->delete();
+      }

It feels wrong to delete the full instance, as it still somehow contains data.

+++ b/core/modules/entity_reference/lib/Drupal/entity_reference/Tests/EntityReferenceFieldTest.phpundefined
@@ -0,0 +1,161 @@
+    $this->field = field_info_field($this->fieldName);
+    $this->instance = field_info_instance($this->entityType, $this->fieldName, $this->bundle);

We could use Field::fieldInfo()->getField directly

+++ b/core/modules/entity_reference/lib/Drupal/entity_reference/Tests/EntityReferenceFieldTest.phpundefined
@@ -0,0 +1,161 @@
+  function testEntityReferenceFieldValidation() {
...
+  function testEntityReferenceFieldChangeMachineName() {

should be public ...

+++ b/core/modules/entity_reference/lib/Drupal/entity_reference/Tests/EntityReferenceFieldTest.phpundefined
@@ -0,0 +1,161 @@
+    $bad_referenced_entity = entity_create($this->referencedEntityType, array('type' => drupal_strtolower($this->randomName())));
+    $bad_referenced_entity->save();
+
+    $entity = entity_create($this->entityType, array('type' => $this->bundle));
+    $entity->{$this->fieldName}->target_id = $bad_referenced_entity->id();
+    try {
+      field_attach_validate($entity->getBCEntity());
+      $this->fail('Wrong reference causes validation error.');
+    }
+    catch (FieldValidationException $e) {
+      $this->pass('Wrong reference causes validation error.');
+    }

Nice test coverage. Maybe add a short sentence to the top of the two groups to explain the idea of the test.

taxonomy.module does the same thing (in a different place though):

Because we know that when you delete a taxonomy vocabulary, it deletes all of the containing entities. This is not the case for other entity types/bundles. When you delete a node type, it does not delete the nodes of that type. I agree that auto-removing the field does seem out of place. Maybe it should be only limited if the entity type target is taxonomy terms.

Rerolled

@@ -0,0 +1,132 @@
+    $test_bundle_2 = drupal_strtolower($this->randomName());
...
+    $test_bundle_2_new = drupal_strtolower($this->randomName());

It would be cool to use Unicode::strtolower() instead.

@@ -0,0 +1,132 @@
+    entity_test_create_bundle($test_bundle_2, NULL, $this->referencedEntityType);

lol, I had a bit of grime while reviewing exactly over the ',' so it looked like a ';'

@@ -0,0 +1,132 @@
+      $test_bundle_2,
+      $test_bundle_2,

It is a bit odd to target the same bundle twice?

@@ -0,0 +1,132 @@
+    $this->assertEqual(count($target_bundles[0]), 1, "The 'target_bundles' setting contains only one element.");

count of a non array for sure returns 1 ... it should be count($target_bundles) instead. Why do we not just use $this->assertEqual(array($this->bundle)) (potentially also before)

This looks great now.

1. +++ b/core/modules/entity_reference/entity_reference.module
   @@ -424,3 +424,68 @@ function entity_reference_create_instance($entity_type, $bundle, $field_name, $f
   +  // Iterate over all entity reference fields referencing the given entity type
   +  // and delete those which target only the bundle that was deleted.
   ...
   +    if ($modified_instance) {
   ...
   +      // Update the instance definition with the new target bundles.
   +      $instance->save();
   +    }
   

   The comment does not match the code, but IMO the comment does actually make sense. The current code makes the instance reference *all* bundles, if I'm not mistaken.

   I just read that this was discussed above, but I'm not sure the behavior above was taken into account. I think if you have a field instance set up to specifically reference a certain entity bundle, having that instance reference all bundles of that entity types is a huge WTF. Ideally we would have the instance reference *no bundles at all*, so that it does not show up on the edit form at all, but then lets the administrator decide whether he wants the field to reference a different bundle or if he wants to delete the field.

2. +++ b/core/modules/entity_reference/lib/Drupal/entity_reference/Tests/EntityReferenceFieldTest.php
   @@ -0,0 +1,134 @@
   +    $this->assertEqual($target_bundles[1], $this->bundle, 'Index 2: Machine name was left untouched.');
   

   Should be "Index 1"

   Also might make sense to add a check for count() as well, here.

I would have re-rolled for the test changes, but I didn't know what to do about the first item.

OK, so should we simply disallow deleting the bundle then? That would be a pretty major change but it really sounds like that's what would be the ideal solution in this case.

Rerolled the patch to bring it inline with the latest changes. Setting to needs review for the bot. This still needs work as per the above.

I agree with #18, just show a message to the user. It will mainly be site builders that are going to delete bundles, and they will know how to update the reference fields.

Updated the patch with the remarks from #15, and provided the message.

I noticed that when a node bundle is deleted it still appears in the list of the entity reference field. This is because the cache of node_type_get_names() is not cleared when a node type is deleted. Created an issue for this: #2169531: Invalidate node_type_get_names() cache when deleting a node type.

@amateescu, I missed your post from #21.

I'll try implementing your idea. If you want to tag this for some more input, sure!

Now only loads the entity_reference field instances, instead of all of them.

Lol seems like I forgot to update entity_reference_entity_bundle_delete(). Thanks for catching it!!

There's some duplicated code between update entity_reference_entity_bundle_delete() and update entity_reference_entity_bundle_rename() now - the discovery of the entity_reference field instances from the field map. Shall we factor that out into a separate function?

Made a reroll for this; bit unsure cause by some reason the test in previous patch wasn't merged so added it manually.

yeah I figured that by the comments but

1. I needed to try to a reroll on a patch involving psr-0 to -4
2. It's often easier to work form a green patch then from a red one.
3. nothing have happened in this since january so figured it needed some attention.

Completely rewritten, so no interdiff.

The test is more compact now.

Rerolled and applied #2452619: Move entity_reference_create_field function to EntityReferenceTestTrait.

@amateescu, I had no idea where to place it. I saw it sitting in EntityManager next to ::getFieldMap() or ::getFieldMapByFieldType() or other FiledInfo methods. And yes, it hardcodes ER because right now I cannot imagine that this can be used to other fields.

OK. Here with $field_type but I still think that maybe we need to filter the whole list of fields, check if their field type plugin class descends from entity reference.

+++ b/core/lib/Drupal/Core/Entity/EntityManagerInterface.php
@@ -143,6 +143,22 @@ public function getFieldMap();
+  public function getFieldsReferencing($field_type, $target_type, $target_bundle);

This method is specific to ER so it doesn't make sense to have it in EMI. How would DER going to override it? It's a helper method in a wrong class imo. We should move it to some other class or ER.module file.

+++ b/core/lib/Drupal/Core/Entity/EntityManager.php
@@ -30,6 +30,7 @@
+use Drupal\field\Entity\FieldConfig;

Ouch - that's really unfortunate, we tried hard to remove dependencies of Core to field.module :-/.
Couldn't getFieldsReferencing() use $this->getFieldDefinitions() instead, and entity_reference_sync_fields() would then limit itself to configurable fields ?

Or, agreed with @jibran that putting ER-specific code in EntityManager feels a little off.

Also, what's the plan once e_r.module is gone ?

I think moving it out of EntityManager is enough for DER. If we are making it specific for ER field then core shouldn't worry about contrib. As long as it's not in the EntityManager DER can always implements it's own hooks.

+++ b/core/modules/entity_reference/src/Tests/EntityReferenceSettingsTest.php
@@ -0,0 +1,96 @@
+  public static $modules = ['node', 'taxonomy', 'field', 'user', 'text', 'entity_reference'];

This test should live in taxonomy module

I know, I know... we still have to deal with auto_create_bundle that is coming only in #2412569: Allow setting the auto-create bundle on entity reference fields with multiple target bundles but let's have some feedback here.

EDIT: Because no one liked to add that field finder to Entity Manager, I created a new service that can accept additional methods in the interface in the future. I really see no place where to move that.

Well it's a shame we don't fire an event when a bundle is renamed this all can live in a one class.

Not sure if we really need a service for the "find field definitions referencing $entity_type + $bundle", but its current name & doc are a bit cryptic / misleading :

+/**
+ * Interface for entity reference finder.
+ */
+interface EntityReferenceFinderInterface {

I'd more expect that to be something that finds references (like, find entities referencing some other entity, aka backreference) ?

Few comments:

• @yched, you're right. I have no other idea right now. I'm expecting that this interface will be expanded in the future with other "finders" (methods).
• The bundle deletion is now part of #2412569: Allow setting the auto-create bundle on entity reference fields with multiple target bundles (if that will remain in that shape).
• The test class with be merged with the one from #2412569: Allow setting the auto-create bundle on entity reference fields with multiple target bundles.

That new method/service would probably make more sense as part of one the new services that will be created by this issue: #2337191: Split up EntityManager into many services

+1

@amateescu, @yched, I'm OK with #49 but right now that is NR for 1 month and it's not a simple issue. We can expect some time till will go in. In the meantime it would be good if we can make some steps forward with this issue. So, let's move on with this and put back that 'finder' in EntityManager. If #2337191: Split up EntityManager into many services will be in first, then we'll update this. Otherwise that will take care to move this method in a new class.

What you think?

Mhyeah, I guess you're right ... :-)

Other remarks then :
- The logic in getFieldsReferencing() should leverage the field map (EntityManager::getFieldMap()) rather than loading all field storage config on earth :-)
- There's a question of "do we want all fields including base fields" or "only configurable fields" ?
The specific use case here only wants to update configurable fields, but it would be strange for a "generic getFieldsReferencing() method" to omit base fields ? (As a side note, the field map will get you all fields)
- Not sure statically caching (especially without a way to clear the cache) is a good thing. The field map is already statically cached.

@yched, thank you. Now re-reading older comments I found @jibran's comment #40. He, and also @amateescu, are saying that this is too ER specific to live in EntityManager (or its successors). And I'm tempted to agree. So #49 conflicts with #40.

I still think that we need a ER method (but where?) and since ER will move in core, we can add the new method directly in core. Course we include observations from #53.

Out of ideas :(

Well, if a "FieldDefinitionsManager" was split off from EntityManager, then a method in there to find ER fields pointing to some entity-type + bundle could be OK IMO, ER fields are an important, structuring field type provided by Core.

Adding it in the already much crowded EntityManager is more debatable, true.

For the time being, do we really need to put that code in a reusable place ? Looks like the patch only calls the method once ?

...do we really need to put that code in a reusable place ? Looks like the patch only calls the method once ?

We can make it a procedural helper in ER and in #2429191: Deprecate entity_reference.module and move its functionality to core we'll move it to system module (grrr, how ugly!)

Or...

If #2553169: Dispatch bundle CRUD events would go in, we just add the event subscriber and make the 'finder' a protected method in that subscriber.

@yched,

I'm very tempted by #57 because is not forcing us to choose an unnatural home for getFieldsReferencing(). The event subscriber would be a good place for that. But then #2553169: Dispatch bundle CRUD events needs a review and commit. Is there a chance for that?

Tagging.

Tagging.

Closed #2571187: EntityReferenceItem should add the target_bundles as config dependencies in favor of this. And yes, we must handle the bundle entity removal through config dependencies.

This includes #53, #61, #62.

1. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/EntityReferenceItem.php
   @@ -284,9 +284,12 @@ public function hasNewEntity() {
   +    $manager = \Drupal::entityManager();
   +    $target_entity_type = $manager->getDefinition($field_definition->getFieldStorageDefinition()->getSetting('target_type'));
   

   Clarity nitpick : s/$manager/$entity_manager ?
   Not clear what the "manager" is when it's used 10 lines below ;-)

2. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/EntityReferenceItem.php
   @@ -298,6 +301,19 @@ public static function calculateDependencies(FieldDefinitionInterface $field_def
   +    $handler = $field_definition->getSetting('handler_settings');
   

   Clarity : s/$handler/$handler_settings ?
   Sorry about those, but calling it a "handler" is kind of a lie :-)

3. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/EntityReferenceItem.php
   @@ -305,12 +321,14 @@ public static function calculateDependencies(FieldDefinitionInterface $field_def
   +    $manager = \Drupal::entityManager();
   

   $entity_manager

4. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/EntityReferenceItem.php
   @@ -322,6 +340,25 @@ public static function onDependencyRemoval(FieldDefinitionInterface $field_defin
   +    $handler = $field_definition->getSetting('handler_settings');
   

   $handler_settings

5. +++ b/core/modules/entity_reference/entity_reference.module
   @@ -211,3 +210,40 @@ function entity_reference_query_entity_reference_alter(AlterableInterface $query
   +function entity_reference_entity_bundle_rename($entity_type, $bundle_old, $bundle_new) {
   

   Minor : the function could use a couple inline comments, 30 lines of code without a comment is usually not good :-)

6. +++ b/core/modules/entity_reference/entity_reference.module
   @@ -211,3 +210,40 @@ function entity_reference_query_entity_reference_alter(AlterableInterface $query
   +  foreach (FieldConfig::loadMultiple($ids) as $config) {
   

   Nitpick : s/$config/$field_config for clarity ?

7. +++ b/core/modules/entity_reference/entity_reference.module
   @@ -211,3 +210,40 @@ function entity_reference_query_entity_reference_alter(AlterableInterface $query
   +      $bundles = !empty($handler['target_bundles']) ? array_keys($handler['target_bundles']) : [];
   +      foreach ($bundles as $bundle) {
   +        if ($bundle == $bundle_old) {
   +          $handler['target_bundles'][$bundle_new] = $bundle_new;
   +          unset($handler['target_bundles'][$bundle_old]);
   +          $config->setSetting('handler_settings', $handler);
   +          $config->save();
   +          break;
   +        }
   +      }
   

   Would be simpler as :

   if (isset($handler['target_bundles'][$bundle_old]) {
     unset($handler['target_bundles'][$bundle_old])
     $handler['target_bundles'][$bundle_new] = $bundle_new;
     $config->setSetting(...)->save();
   }
   

   ?

8. +++ b/core/modules/entity_reference/entity_reference.module
   @@ -211,3 +210,40 @@ function entity_reference_query_entity_reference_alter(AlterableInterface $query
   +  // Release memory.
   +  unset($map, $ids);
   

   Is that really needed ? The memory should be freeable by GC the moment we leave the function and the variables get out of scope ?

   I don't think we do similar things (unset vars used in the function before leaving it) in any other place ?

9. +++ b/core/modules/entity_reference/src/Tests/EntityReferenceSettingsTest.php
   @@ -0,0 +1,96 @@
   +  public function testSyncTargetBundleChanges() {
   

   Nitpick : the "Sync" part refers to a function name that no longer exists, right ?
   Why not just testTargetBundleChanges ?

Also : that is an awful lot of non-trivial code to repeat for anything that stores "a list of bundles for which some feature is enabled", which seems like a fairly common pattern :-/

Not for this issue to enhance, though...

Forgot : EntityReferenceItem::onDependencyRemoval() could use a couple inline comments (mirroring the ones delimiting code sections in calculateDependencies())

Can we include #2479257: EntityReferenceItem::calculateDependencies() assumes $field_definition is FieldConfigBase here as well and close that as duplicate?

@jibran : see over there - that issue got fixed meanwhile :)

+++ b/core/modules/entity_reference/entity_reference.module
@@ -228,22 +226,57 @@ function entity_reference_entity_bundle_rename($entity_type, $bundle_old, $bundl
+/**
+ * Implements hook_entity_bundle_delete().
+ */
+function entity_reference_entity_bundle_delete($entity_type_id, $bundle) {

This is useless. We handle this now in onDependencyRemoval(). See the tests passing in my latest patch without this hook implementation :)

Patch looks solid now.

1. +++ b/core/modules/taxonomy/src/Entity/Vocabulary.php
   @@ -127,40 +127,6 @@ public function getDescription() {
      public function postSave(EntityStorageInterface $storage, $update = TRUE) {
   

   <3 this clean up.

2. +++ b/core/modules/entity_reference/entity_reference.module
   @@ -211,3 +210,78 @@ function entity_reference_query_entity_reference_alter(AlterableInterface $query
   + * Implements hook_entity_bundle_rename().
   

   I get it that I have to update DERItem like ERItem. But do I have to add this hook to DER as well?

3. +++ b/core/modules/entity_reference/entity_reference.module
   @@ -211,3 +210,78 @@ function entity_reference_query_entity_reference_alter(AlterableInterface $query
   +        if ($handler_settings['target_bundles'] === []) {
   

   Can't this also happen in entity_reference_entity_bundle_rename?

Thanks @yched for closing the issue as duplicate.

It is not useless at all :) We also need to take into account bundles that are not provided by a config entity type and therefore are not config dependencies.

hook_entity_bundle_delete() is invoked only by bundles based on config entities. At least in core. If a module wants to provide a bundle that is not a configurable, we needs to provide a mechanism for keep in sync entities.

@claudiu.cristea : Yeah, we discussed that with @amateescu yesterday.

If an entity type has non-config bundles, then they are most probably hardcoded in code somewhere. If one of them is removed from the code, then the corresponding module should call hook_entity_bundle_delete() in a hook_post_update_N()

I hate the code duplication between onDependencyRemoval() and entity_reference_entity_bundle_delete(), but we couldn't find a way around that.

@jibran re #77.3 : I don't think that can happen, a rename cannot cause the set of bundles to become 0.

1. +++ b/core/lib/Drupal/Core/Entity/Plugin/EntityReferenceSelection/SelectionBase.php
   @@ -207,7 +210,14 @@ public function buildConfigurationForm(array $form, FormStateInterface $form_sta
   +    // Normalize the value of the 'target_bundles' setting. In case it is an
   +    // empty array we need to change it to NULL in order to allow the field to
   +    // reference all bundles of the target entity type.
   

   Nitpick : we could clarify that this is about adjusting the UI behavior.

   Suggestion :
   "If no checkboxes were checked for 'target_bundles', store NULL ("all bundles are referenceable") rather than empty array ("no bundle is referenceable" - typically happens when all referenceable bundles have been deleted).é

2. +++ b/core/lib/Drupal/Core/Entity/Plugin/EntityReferenceSelection/SelectionBase.php
   @@ -326,6 +336,15 @@ protected function buildEntityQuery($match = NULL, $match_operator = 'CONTAINS')
   +
   +    // If the 'target_bundles' setting is an empty array, force the query to
   +    // never return anything and bail out early.
   +    if (isset($handler_settings['target_bundles']) && $handler_settings['target_bundles'] === []) {
   +      $query->condition($entity_type->getKey('id'), NULL, '=');
   +
   +      return $query;
   +    }
   +
        if (!empty($handler_settings['target_bundles'])) {
          $query->condition($entity_type->getKey('bundle'), $handler_settings['target_bundles'], 'IN');
        }
   

   That works, but the NULL case could be a bit more explicit, for clarity.

   Maybe :

   // If 'target_bundles' is NULL, all bundles are referenceable, no further conditions are needed.
   if (!is_null($handler_settings['target_bundles']) {
     // If 'target_bundles' is an empty array, no bundle is referencable, force the query to    // never return anything and bail out early.
     if ($handler_settings['target_bundles'] === []) {
     ... add unfullfillable condition ...
   }
   else {
     ... add condition on bundles...
   }
   

   ?

3. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/EntityReferenceItem.php
   @@ -305,12 +321,14 @@ public static function calculateDependencies(FieldDefinitionInterface $field_def
      public static function onDependencyRemoval(FieldDefinitionInterface $field_definition, array $dependencies) {
   

   Can we add short inline comments delimiting the two parts ("default values" & "target bundles"), like calculateDependencies() does ?

4. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/EntityReferenceItem.php
   @@ -322,6 +340,39 @@ public static function onDependencyRemoval(FieldDefinitionInterface $field_defin
   +              // In case we deleted the only target bundle allowed by the field we
   +              // have to log a warning message because the field will not function
   +              // correctly anymore.
   

   copy/paste breaks the 80 chars limit ;-)

   Also, nitpick, but "warning" is an actual log level, and that's not the one we use here. So maybe just "Log a message if the field no longer has any referenceable bundle" ?

Thanks for the explanation @yched.

+++ b/core/modules/entity_reference/entity_reference.module
@@ -211,3 +210,78 @@ function entity_reference_query_entity_reference_alter(AlterableInterface $query
+ * Implements hook_entity_bundle_rename().
...
+ * Implements hook_entity_bundle_delete().
+ *
+ * We are duplicating the work done by
+ * \Drupal\Core\Field\Plugin\Field\FieldType\EntityReferenceItem::onDependencyRemoval()
+ * because we need to take into account bundles that are not provided by a
+ * config entity type so they are not part of the config dependencies.

Can we add a test for non config entity types?

Hm, so FWIW, #2172843: Remove ability to update entity bundle machine names just got bumped to critical :-)

@amateescu: Thanks !

Now that #2064191: Fix the 'target_bundle' field setting - 'target_bundles' are not validated when entity_reference is enabled got in, we probably want to adjust the code that it added in ERItem::getConstraints(), for the NULL / [] difference added in this patch here.

(if NULL, we don't want to add any Bundle constraint. If [], the Bundle constraint should be fine, since the in_array() check its validator does will always fail)

Yay ! RTBC if green :-)

RTBC +1

Gee, those testbot fail notifications on old patches are painful :-/

Good job, I like that the potentially confusing difference between NULL and an empty array is spelled out very clearly in the documentation every time it is used.

It needs reroll as per https://www.drupal.org/pift-ci-job/44851

Let's assign the issue to @alexpott for the review of config dependencies part of the patch.

1. The patch generally looks good - I think the issue summary could do with fleshing out why this is important to get done before the release candidate.

2. +++ b/core/lib/Drupal/Core/Entity/Plugin/EntityReferenceSelection/SelectionBase.php
   @@ -326,8 +337,20 @@ protected function buildEntityQuery($match = NULL, $match_operator = 'CONTAINS')
   +      // If 'target_bundles' is an empty array, no bundle is referencable, force
   

   referenceable to be consistent with the rest of core.

3. +++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldType/EntityReferenceItem.php
   @@ -321,12 +337,15 @@ public static function calculateDependencies(FieldDefinitionInterface $field_def
   +    $changed = parent::calculateDependencies($field_definition, $dependencies);
   

   I think this should be parent::onDependencyRemoval().

@alexpott : Now that bundle renames are out of the equation, I'd think the patch on itself is not critical to get before RC1, and could go in as a bugfix after that.
But it's blocking #2412569: Allow setting the auto-create bundle on entity reference fields with multiple target bundles, which would really need to get in before RC since it implies config/schema changes.

Added that to the IS

Fixed #100. IS still needs an update as per #100.

+++ b/core/lib/Drupal/Core/Entity/Plugin/EntityReferenceSelection/SelectionBase.php
@@ -326,8 +337,20 @@ protected function buildEntityQuery($match = NULL, $match_operator = 'CONTAINS')
+    if (isset($handler_settings['target_bundles']) && !is_null($handler_settings['target_bundles'])) {

This is somehow superfluous. If $handler_settings['target_bundles'] is NULL both expressions are FALSE, so the second doesn't make any sense -- isset() should be enough. Maybe we can test if that is an array?

if (isset($handler_settings['target_bundles']) && is_array($handler_settings['target_bundles'])) {
  ...
  if (empty($handler_settings['target_bundles'])) {
    ...

@jibran

IS still needs an update as per #100.

I did that in #101, but forgot to remove the tag.

@claudiu.cristea :
Correct. This should fix it.

Back to RTBC as #100 got addressed.

PS: I only made a doc fix and a typo fix so I think I'm eligible to RTBC it.

This is a good bug fix to make before the rc deadline and it has test coverage. Sites will be more robust after a bundle delete if they use entity reference fields.

I was wondering about the upgrade path - but I think sites that are in this state will already have fixed their problematic er field or it will have broken them - so I think it is okay for this to not have an upgrade path.

Committed fa0af0b and pushed to 8.0.x. Thanks!

I discussed this with @amateescu and @yched in Barcelona therefore adding myself to the issue credit list.

Thnaks @alexpott. I'll unpostpone and reroll #2412569: Allow setting the auto-create bundle on entity reference fields with multiple target bundles