ECA brings great value to Drupal CMS, and still has to improve

Update: Thanks to careful readers, 2 mistakes have been identified and corrected.
- Add the missing elevator statement to the end of the post.
- Swap 404->403 to 403->404 response code handling.

Yesterday, I’ve spoken to Dries Buytaert about the next steps on the way to a much improved ECA user interface. And he asked: “We all know that ECA ships with Drupal CMS, but honestly, what does it do for the user?”. Not that he didn’t know the answer to this question himself. But, what happened was that I couldn’t just give that elevator statement he was looking for. I had to think, and explain why each of the deliverables are of any value.
That’s his gentle way of getting the message across. His question made me realize that the end user has no way of knowing why ECA is part of Drupal CMS and what they actually get out of it.
So, this blog post is the beginning of a journey where I’m going to change that. Not only will I explain what’s in Drupal CMS today. Even more importantly, the journey to the promised, and much improved ECA user interface will focus on use cases, and why they really matter. I’ll explain what ECA can do, and why it’s the recommended way for end users to address their requirements.

What’s in Drupal CMS today

But let’s start with the already existing things first. Not all of them are solving end-user requirements, actually some of them are tweaking either Drupal core or one of the included contribution modules. That’s not of much interest to the end-user, though. So, let’s start with real user benefits:

• Content duplication: While there are numerous modules available, that can clone nodes, or even entities in general, each of them came with pros and cons. Almost always they are opinionated solutions and some are not as actively maintained as a product like Drupal CMS demands. Building that functionality with ECA allows for flexible customization if needed, and it avoids the maintenance of yet another module.
• Redirects after login and logout: What should happen right after a user authenticates to a Drupal site? Ask 5 site owners, and expect 8 or more different answers. That’s why this behaviour should be customizable. Exactly what ECA is a perfect solution for. It lets the user add any number of scenarios, each of which can depend upon any context. Examples are, that authenticated users should be redirected to different landing pages, depending upon their user roles.
• Alter the user registration form: If a site owner creates a new user account on their Drupal site, they find themselves in front of a comprehensive form that contains fields, that are often unnecessary, or the order of those fields is confusing. As an example, if the new user gets notified about their account, they receive a one-time login-link that allows them to set their own password. In that case, there is no reason why the site-owner, who creates that account, should set a password for that user in the first place. ECA is there to fix that. It alters that form such that the password fields are hidden when they’re not needed.
• Avoid disclosure of existing but unpublished content: The response to a browser request to an unpublished page to non-permitted users is that 403 "Access denied". We’ve all seen that. But that discloses, at least, that the requested page exists. That may well be something, the site owner doesn’t want to let the world know about yet. For that reason, an ECA model has been built which recognizes that and forces Drupal to respond with a famous 404 instead.
• Automatically turn on consent management for remote content when needed: Privacy is an important feature in Drupal CMS, and its consent management got implemented such that it’s not annoying to website visitors. That means, apart from many other things, that a Drupal site doesn’t ask for user consent to display remote content like videos from YouTube or Vimeo, if there isn’t even a single such video available on the site. However, to avoid the mistake that such a video gets added to the site later, and it will be forgotten to adjust the consent management for that matter, ECA is there to take care of this. It enables the remote content default settings automatically, as soon as the first remote video gets added to the site.
• Create newsletter subscription blocks when enabling Mailchimp: Websites, that enable the Mailchimp module to manage newsletter subscriptions, usually have a lot to do configuring their Drupal site for just that requirement. In Drupal CMS, a combination of a recipe and an ECA model automates that almost entirely. As soon as the site owner authenticates to their Mailchimp account, ECA reads the available lists from that account and creates a subscription block for each of them. The site builder can then place those blocks anywhere on their site without having to bother about all the previous steps. ECA will have taken care of them already.

This is a lot of functionality. And most Drupal CMS users will not have noticed that they’re there. But for those, who’re interested, and then probably have the desire to customize the behaviour, they can. ECA is there to just allow that to happen. And any modification a user will make to the default functionality will just be stored in config. No code is being written, not another module needed to be added to the already long list, and there’s not another dependency that may have to be maintained to be compatible with the next minor or major release update of Drupal core.

Tweaking Drupal Core and modules

• Provide dynamic breakpoints: Breakpoints are required by the suite of media management modules in Drupal to provide optimized image styles out of the box. However, breakpoints are defined by themes, not modules. Since Drupal CMS can’t make assumptions about the theme being used on a site, it’s difficult to provide the convenience of prepared image optimisation with styles when not knowing what breakpoints will be available. ECA resolves that dilemma by dynamically bridging between theme related breakpoints and modules actually using them.
• Add a privacy link to the footer menu: Drupal CMS automatically applies the privacy recipe on new sites, which enables the Klaro consent management module and configures it automatically. Part of that configuration is to define the node that contains the privacy policy, something every site should provide. ECA takes care of this by determining the specific URL for that node, creating a menu item for it, and adding that to the config for Klaro.
• Automatically configure sitemap for new content types: Drupal CMS comes with recipes that configure the sitemap for content types at install time. But what if the user defines new content types in the future? ECA ensures that the same default settings will be applied to those automatically. That provides the site builder with the same defaults without having to copy and paste them manually, if they even realize that this needed to be done.
• Automatically configure content types for SEO meta tags: Similarly, there are meta tag fields that Drupal CMS carefully determined how they should be configured out-of-the box. Again, those default settings are applied at install time. And ECA takes care of new content types that will be created in the future.

All these tweaks would not be required, if we had a chance to implement them right in Drupal core, or in one of the modules that add extra functionality like consent management, sitemaps, SEO, and others.
But that’s, in most cases, impractical. Convincing maintainers to add the extra feature, finding time to implement them, maintaining them for the next 10 years or more, and still lacking the flexibility that a configuration based no-code solution can provide. That’s what makes ECA so valuable for Drupal CMS, and not to forget, any Drupal site either built by an agency or the end-users themselves.

What needs to improve, and how we’re approaching this

ECA is so powerful, the above features are just scratching the surface. The problem that’s yet to be solved, is to make it more intuitive for more users so that they can modify the existing ECA models on their site, or even create new ones for additional requirements they come across.
There has been a lot of research performed in the last few months. And the main pain points have been identified and written down. What comes next is to define the use cases that are the most frequent ones for Drupal users, and work out the ideal UX on how to implement them.
This effort happens in public, and you can follow and/or participate by joining the #eca-next-gen channel in Drupal Slack. In the next days and weeks, I will follow up with separate blog posts to explore those use cases in more detail.

Elevator statement

ECA (Event-Condition-Action) is a powerful no-code automation tool included in Drupal CMS that provides features like content duplication, customizable login/logout redirects, form alterations, privacy protections, and automatic configuration for integrations like Mailchimp. Beyond user-facing features, ECA also handles behind-the-scenes tasks such as dynamic breakpoints, automatic sitemap configuration for new content types, and SEO meta tag defaults. While ECA offers significant flexibility without requiring additional modules or code, the user interface needs improvement to make it more intuitive for users who want to customize or create their own automation models.

Join us on Drupal Slack