DANSE settings for content always use the defaults

According to this code snippet at the beginning of \Drupal\danse_content\Plugin\Danse\Content::processEntity, the order of processing must have been different before:

    if ($values === NULL && isset($this->processedEntitiesByUi[$entity->getEntityTypeId()][$entity->id()])) {
      // We got here from an entity hook, but don't want to process that entity
      // right here, because it got edited through the UI and we want to grab
      // the settings from the entity edit form. So let's skip this, we will
      // be getting here a second time for this entity and process it then.
      return;
    }
    if (!empty($processedEntities[$entity->getEntityTypeId()][$entity->id()])) {
      // Avoid double processing.
      return;
    }
    $processedEntities[$entity->getEntityTypeId()][$entity->id()] = TRUE;

At the time when we built that, the UI processing (form submit) must have been first, and hook processing second.

If that order is now the other way round, something in core must have changed since. Let's see how we get our form submit being processed earlier. But we need to be sure that we don't execute the DANSE form submit handler before the entity got saved, because then we don't have a proper entity to operate upon yet.

Just realized that the currently implemented concept has another aspect which makes it to work properly with just a slight modification.

What's happening is that during submission, the "build form" process will be called again, before validation and submission. The content plugin already fills the variable $processedEntitiesByUi with the necessary data such that when the insert or update hook calls processEntity, that method knows that the insert/update was triggered from a form, and it will NOT process the entity at that point. Instead, the entity will be processed the second time, when the form submit handler calls processEntity with the values from the form.

That's how it was supposed to be working. For some reason, the variable $processedEntitiesByUi was empty, when getting into processEntity. It must be that there is a new instance of the content plugin at that time.

To fix this, changing the $processedEntitiesByUi variable to static, this works as intended.

I tried out this merge request and I realized, that the condition in line 677 in Conetent.php is always false when we insert a node:

self::$processedEntitiesByUi[$entity->getEntityTypeId()][$entity->id()]).

This is because in line 632 in function buildContentForm the statement self::$processedEntitiesByUi[$entity->getEntityTypeId()][$entity->bundle()] = TRUE; results in:

We do not have an entity yet, so id() is null.

I changed this to bundle().

I know, that it is not the final solution..

I left it static, but I think this is not necessary.

We might switch to our first proposal to remember the DANSE values and pass them. What do you think?

I have added the user ID to the array. This might increase the safety, that we catch the correct entity. I also reset the static variable after processing, so we have a clean state again.

After several testings with the option to handle this via validateForm, I think this does not solve the problem, because we have to remember the entity processed via UI anyway.

The current state works for inserting and updating, etc.

But I am not sure, if this, like mentioned above, is the final solution.

Great point, thanks for finding this. However, bundle and user ID won't help much, since they will always be the same in the single PHP process.

However, the form alter can only be present once for a single PHP request and if it's about a new entity, the ID is zero, and we can use that as the ID, while also telling the processEntity method, when we call it from the insert hook and not by the update hook.

I've made another commit and believe, this should now catch it all.

Thx. Is working like expected.

Automatically closed - issue fixed for 2 weeks with no activity.