I was missing status part in the EntityFormDisplay::create function. Here is the corrected code part:
// Load the form display for the vocabulary
$form_display = EntityFormDisplay::load('taxonomy_term.' . $bundle . '.default');
if (!$form_display) {
$form_display = EntityFormDisplay::create([
'targetEntityType' => 'taxonomy_term',
'bundle' => $bundle,
'mode' => 'default',
'status' => TRUE,
]);
}
Thank you, @amateescu, I can see that the hierarchy thing is probably a bit complicated :)
I think the question here also is what should happen with children when the parent is trashed. For me, the logical thing would be to also trash its child nodes (recursively, if they have their own child nodes), so they don't get orphaned, nor added to an arbitrary new parent. If they, however do have another parent, then, just as in the example here, I'd leave them be and only store metadata of the parent that's being trashed. Otherwise, we'd probably need to store metadata of all the trashed children (and possibly their children) as well.
If trashing works like this, then we wouldn't even need to ask whether to re-parent the restored children once their parent gets restored, since they'd be restored alongside of it. Of, if they had another parent, then they'd get re-attached to the restored parent as well.
I checked how Drupal's current delete on parent terms work and it seems that children terms are indeed auto-removed with the parent. So that functionality logically doesn't change from the default Drupal behavior.
What do you think?
At the end, this seems to be a problem with our own import script from an external product management application.
mambrus → created an issue.
mambrus → created an issue.