Troubleshooting

The site is not working anymore

It may happen, that an ECA model contains instructions, that may break your site. As ECA tries catching all the known risks automatically, this shouldn't happen really, but you never know. However, should you find yourself in such a situation, it's not too easy to get yourself out of it again. The UI may not be accessible any longer and disabling a model with e.g. drush won't work either then, because that bootstraps the Drupal site as well before it could change the config.

Only for situations like that, ECA provides an easy kill-switch:

$settings['eca_disable'] = TRUE;

Put this into your settings.php somewhere and ECA will be completely disabled. Users with the permission administer eca will be notified with a message on the screen, to make them aware that ECA is actually not working.

In this disabled mode you can fix the model, that's causing the issue by either editing that model or you can disable or delete that model. When done, remove that line from your settings again and ECA will continue working right away.

Can't save ECA model due to a missing plugin

When saving a model, ECA is validating the config entity to make sure that no obviously wrong configuration gets stored. This will refuse to save, e.g. if a model is missing a value for a required field or if it contains a plugin for either an event, a condition or an action, that no longer exists.

A missing plugin happens rarely. It could actually happen, if a module which provides one or more plugins gets updated and no longer delivers all the previous plugins any longer. Another scenario could be with dynamically created plugins that get derived from some other config values. In such cases, plugins could either disappear or simply get renamed, which is the equivalence to a plugin, that no longer exists, i.e. not under the original name.

In such a situation, it won't be possible to save the ECA model any longer, not even after removing or replacing the object in the model. This is caused by the way Drupal core's configuration validation is being implemented where the original config entity gets validated once before updating it as well.

To circumvent this issue, you can manually add a query argument to the URL in the browser to temporarily turn off the model validation when saving the updated version once. So, if the URL to edit your model looks like this:

https://www.example.com/admin/config/workflow/eca/process_someid/edit

You should add the query argument eca_validation=off to it:

https://www.example.com/admin/config/workflow/eca/process_someid/edit?eca_validation=off

Then you can make your corrections to the model and save it. From then on, you no longer need that query argument anymore.

Workflow transition sometimes not recognized

When using the workflows module from Drupal core together with content moderation, then the event Workflow: state transition may not recognize the changed state, because the pre-save method in Drupal core may load the wrong revision under certain circumstances.

There is a fix in the works for Drupal 11, but it's not yet committed and is unlikely to be back ported to Drupal 10 or even 9.

As a workaround, Drupal core can be patched with this file and which is discussed and provided by this Drupal issue.

Using non-stable releases

If you want to use non-stable releases (e.g. RC, beta or dev), then you should configure your root project to allow that by configuring the minimum acceptable stability with e.g. composer config minimum-stability beta for accepting beta releases. Without this, Composer may run into dependency issues.