Initialized fields of an entity clone have a reference to the original entity object instead to the cloned entity object

> Class 'Drupal\migrate\Event\MigrateEvents' not found

I've seen that before, some fun stuff about class autoloading... #2776235: Cached autoloader misses cause failures when missed class becomes available and possibly other issues. but that was fixed?

And cached autoloader might also explain why you still get fails even after reverting the changes, as something is still cached in apcu, a restart might help?

Wow, another beautiful find!

Code-wise it looks perfect. I think we can improve the comments a bit, though.

1. I think one detail that is missing is pinpointing that the getTranslation() call is the culprit and that the cache needs to be cleared so that new objects get created through initializeTranslation()
2. The second chunk about the property references is hard to parse, especially the "cloning of the clone" part. It's factually correct, as far as I can tell, I'm not saying it's wrong in any way, I just think it's hard to understand what you mean.

I had a go at trying to improve this:

1. The translation cache has to be cleared before cloning the fields below so that the call to getTranslation() does not re-use the translation objects of the old entity but instead creates new translation objects from the newly cloned entity. Otherwise the newly cloned field item lists would hold references to the old translation objects in their $parent property after the call to setContext().

2. Because the new translation objects that are created below are themselves created by *cloning* the newly cloned entity we need to make sure that the references to property values are properly cloned before cloning the fields. Otherwise calling $items->getEntity()->isNew(), for example, would return the $enforceIsNew value of the old entity.

Also one minor note:

+++ b/core/tests/Drupal/KernelTests/Core/Entity/ContentEntityCloneTest.php
@@ -53,10 +61,12 @@ public function testFieldEntityReferenceAfterClone() {
+          $this->assertSame($translation, $field->getEntity(), new FormattableMarkup('Translatable field %field_name on translation %langcode has correct entity reference to the cloned entity object.', $args));
...
+          $this->assertSame($translation->getUntranslated(), $field->getEntity(), new FormattableMarkup('Non translatable field %field_name on translation %langcode has correct entity reference to the cloned entity object in the default translation %default_langcode.', $args));

Let's use just "reference" instead of "entity reference" here, please, to avoid confusions with the field.

@hchonov pointed me here as closely related to a migration stubbing issue I'm having with taxonomy entities (and specifically not with any other entity type). In a non-multilingual site.

1. Migration step 1 stubs a term
2. Migration step 2 wants to create that term
3. ChangedItem::preSave() ends up seeing the entity from step (2) as a not-new entity, however it does not have the original property on the entity. Also, the entity ID does not match the one generated for the stub in step (1), instead it has a tid I do not see in the database.
4. Process crashes on the error below Fatal error: Call to a member function hasTranslation() on null in core/lib/Drupal/Core/Field/Plugin/Field/FieldType/ChangedItem.php on line 52

Re-posting as a consolidated version of what I shared on #2543726: Make $term->parent behave like any other entity reference field, to fix REST and Migrate support and de-customize its Views integration for discovery/solution review purposes.

Now it needs a reroll :)

Rerolled.

Conflict was #2675010: Cloned entity will point to the same field objects if the clone was created after an entity translation has been initialized for anyone following along at home, BTW.

Oops, yeah I think I'm allowed to RTBC that interdiff then. ;-)

Here is a broad backport of the patch to Drupal 8.2/8.1. There were enough changes in ContentEntityBase::__clone() that I ended up copying that method entirely over what I found in Drupal 8.2, but preliminary testing shows it's working fine.

This does appear to solve the issue I outlined in #19.

Re-uploading latest patch.

Committed and pushed 151050c to 8.4.x and 6245eeb to 8.3.x. Thanks!

This is really just a move of code around so that the translation cache is cleared first. Test coverage looks good.