ECA Content knocks out "Promote content to front page" and "Make content sticky" Admin actions

I can confirm this behaviour. This happens in \Drupal\eca_content\Plugin\Action\FieldUpdateActionBase::save where ECA tries to determine with empty($entity->eca_context) whether the field change was called from within an ECA model or not. When using the bulk form, it appears that $entity->eca_context equals TRUE, which should not be.

Will have to dig deeper to find out what's wrong with this.

The flag, that an entity was related to an entity event, was set too broadly. Also, the method that was used is deprecated in PHP 8.2 since we used a dynamic property.

This is now replaced by an entity stack that only gets filled, if the entity event really got dispatched. If not, our set field value class can now properly determine, that NO eca model was involved and will correctly save the entity.

Hmm, a test is broken, will have a look.

jurgenhaas → credited danielspeicher → .

I've taken a completely different approach, the entity stack from the first approach didn't work out. The reason is that the action plugins, that set field values on entities behave differently in ECA context than outside: inside ECA, the action plugin can be configured such that the entity should be saved or not when the field value has been set. For action plugins that don't have that configuration option (like core's promote and sticky actions), ECA assumes the default value, i.e. not to save the entity after changing the field value.

However, if those plugins run outside ECA, e.g. as a bulk action, then the entity needs to be saved, otherwise the changes would be saved.

Therefore, I've now added a method isEcaContext() in the ECA processor, which can tell if the current stack trace is within an ECA processing event or not. That works 100% reliable in real life.

However, this failed for some tests, since they call the set field value action plugin without going through the processor. For that special case I've now also added a state value, which simulates that context for those tests.

@danielspeicher, is that acceptable from your point of view?

Yes, that sounds reasonable. Code looks fine as well.

Merged and back ported to 1.1.x

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