Event data not available

That's 2 different events, isn't it. One of them is eca_render.entity (with the red line) and eca_views.pre_execute with the green line). The tokens are provided by the events, though. The pre_execute provides the view arguments, the render event doesn't. And the scope of tokens is only always within the chain of the current event, never outside of that.

The one with red line is wrong, in my opinion; it's showing the context of an action within the eca_views.pre_execute-event, but with the data of the eca_render.entity-event. Both logs within the squares start with "Start [event name]... for event eca_views.pre_execute".

The files don't seem to fully match, as some of them use pre_execute and others use pre_build. But that put aside, here is what happens:

When the eca_views.pre_execute event gets dispatched, and no other events has been processed by ECA before then, the token stack is empty and that's what we see in the screenshot with the green line.

In the other log with the red lines, there has been the entity render event before, which calls the view render action. At that point, when calling the action, the token stack is filled with data from the previous event. Then, Drupal dispatches the eca_views.pre_execute event and ECA responds as it has a model with this event. At that point, we still, have the token stack from the calling action. That's why we have all the tokens in the log line "Begin applying process ..." that come from the outer context. Only once ECA determines that it really needs to execute the model with the eca_views.pre_execute event, is it then saving away the token stack, resetting it for its own processing, to restore it right afterwards.

The resetting of the token stack happens in \Drupal\eca\EventSubscriber\EcaExecutionTokenSubscriber::onBeforeInitialExecution, so we need to find out if it really doesn't clean-out the token called event, or if just the logger messes things up. I'll build a simple example that should let us find out what's going on.

OK, here is what happens: whenever an event starts processing, \Drupal\eca\EventSubscriber\EcaExecutionGeneralSubscriber::onBeforeInitialExecution is being called, which adds the current event as a token provider to the token service.

While \Drupal\eca\EventSubscriber\EcaExecutionTokenSubscriber::onBeforeInitialExec clears the token stack, adding a new event as a token provider leaves the previous event as a token provider.

Then, when \Drupal\eca\Token\TokenDecoratorTrait::getTokenData is trying to find tokens, it goes through the list of token providers and the first event responds with the event token.

This is a major bug, and we need to resolve this. This only applies to events as token providers, as we don't have other token providers that are only valid within a certain context. Therefore, we have 2 options to resolve this:

• Walk through the provider list in reverse order to find the last event first.
• Remove the previous event from the provider list and bring it back when the current event finished processing.

The first one may still produce false tokens if the current event doesn't provide a requested token, but the previous event did. The second one is more difficult to implement but we should go for it.

It wasn't that complicated. The MR in here fixes the issue in my tests, please review and test it in your environment.

Thank you for the quick resolution! I can confirm that it's fixed on the project that I was working on. See attached screenshot of logs.

Thanks @lammensj for your quick response. I've merged this and will also backport that to the 2.0.x branch next.