The property emptyDestinationProperties of the Row object is set during the execution of MigrateExecutable::import
Before the actual entity save, the Row objects can be altered with an event listener on MigratePreRowSaveEvent
e.g.: $event->getRow()->setDestinationProperty('uid', 1);
But in the case that uid was added before to emptyDestinationProperties by setting a new value on the property does not remove the property from the emptyDestinationProperties array
And this is causing for the example above that EntityContentBase::updateEntity is setting the value NULL for the property and not the value that was set in the event listener MigratePreRowSaveEvent
foreach ($empty_destinations as $field_name) {
$entity->$field_name = NULL;
}within Raw::setDestinationProperty remove the property from the emptyDestinationProperties array
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 3561197.patch | 8.12 KB | aurelianzaha |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !14026
Comments
Comment #2
aurelianzaha commentedComment #3
aurelianzaha commentedComment #4
aurelianzaha commentedjust found that this issue was solved in 11.x already
https://www.drupal.org/project/drupal/issues/3520065
will backport the MR to solve this is 10.x as well
Comment #6
aurelianzaha commentedComment #7
andriy khomych commentedThanks, Aurelian Zaha.
It looks good to me.
It seems we should update the description of the issue
Ideally, we need core maintainer feedback. Those methods are helpful, but it might be a better approach.
Comment #8
aurelianzaha commentedthanks Andriy Khomych for the review
the approach was approved basically because this was merged to 11.x already https://git.drupalcode.org/project/drupal/-/commit/8326e01e92f2e1857bcd9...
this MR is only a backport of that
Comment #9
aurelianzaha commentedattached a static path for the MR, in case someone else needs that as well
Comment #10
benjifisher@aurelianzaha, @andriy khomych:
When @longwave committed the fix for #3520065, he wrote,
Since Drupal 10 is in maintenance, not active, development, it is covered by the policy for Maintenance minor releases. Those are the criteria that @longwave cited.
In other words, the decision has already been made not to back-port #3520065 to Drupal 10.
I will change the status of this issue to NW for now, in case you want to challenge that decision, but I think the correct status will be "Closed (won't fix)".
Comment #12
quietone commented@benjifisher, thank you the git history for this.
I confirmed the decision made be longwave as explained in #10. That is what he said. This is a won't fix.