Embrace ECA: The Future Beyond Classic Module Development

If you've been building Drupal sites for a while, you know the pattern: a new requirement comes in, you reach for a custom or dust off an aging contributed module, and before long your code base is a patchwork of narrowly-focused solutions. Over time, maintenance becomes a chore.

There's a better way.

Drupal 8 introduced the plugin system — a big leap toward modularity. Suddenly, we could write small, focused classes to add functionality in a clean, reusable way:

But plugins are still code. They still need to be implemented, deployed, and maintained in modules.

The Event-Condition-Action (ECA) module has changed how we think about Drupal development. Instead of building bespoke modules or hunting for contributed plugins to match each edge case, ECA lets you assemble site logic from reusable building blocks — events, conditions, and actions — directly in the user interface (UI). Need a missing piece? Just implement that piece in code, and plug it into the ECA framework. The rest is configuration, not development.

From Plugins to Scenarios: A Real-World Shift

ECA takes the next leap. With ECA, your plugins become scenarios — configurable event-driven workflows. Code only the missing building blocks, then assemble everything else visually:

The Migrate API has long supported chaining process plugins, but that’s been limited to migrations. Since the release of ECA's modeler_api, we now have a visual UI for chaining any logic, site-wide.

Migrate process trim

The migrate_process_trim module provides a quick and simple means to remove leading or trailing characters (such as spaces) in a Drupal migration. It worked for Drupal 8 and 9, had automated fixes for Drupal 10 and 11, but is no longer supported.

One of our client's applications relied heavily on it for data imports. For the upgrade to Drupal 11, we could have stepped in as maintainers — but instead, we chose a different path: replace it entirely with an ECA-powered migrate process plugin.

Here's why:

• The same trim functionality already existed in Tamper and was available in ECA via ECA Tamper.
• By using ECA, we could make the trimming logic far more flexible.

Instead of a standalone process plugin, we created a migration process plugin that triggers an ECA event. The scenario handles the trimming — whether it’s a basic white space strip or a complex string manipulation — without touching migration code.

Result: One unsupported contributed module replaced by a reusable ECA scenario that works across multiple migrations.

Replacing migrate_conditions with ECA Conditions

Sometimes you only want to transform a value if certain conditions are met. Traditionally, migrate_conditions handled that. But with ECA, you can implement the same conditions and more, directly in your scenario.

Your migration process plugin fires an event, ECA evaluates the conditions, and only if they pass, the transformation action runs. This keeps migration YAML clean, and lets you manage conditional rules in a central, reusable place.

This swap meant we could retire another module from the client's stack — and as a bonus, we no longer need to worry about whether it'll be ported to future Drupal versions. Given jurgenhaas' pledge at the Drupal Conference in Portland 2024 to maintain ECA "for life", we're in safe hands.

Bringing the Same Logic to entity_import

One of ECA's biggest strengths is reusability across contexts.

Entity Import offers a UI for importing various entities, built on top of the Migrate API. But:

• To reuse migrate process plugins, you need to wrap them in configurable plugins.
• Due to its plugin selection limits, you can use the same process plugin only once per migration property. For most imports that's fine, but not always.

With the ECA Entity Import process plugin, those restrictions disappear. You can reuse the same trimming or conditional logic scenarios from your migrations in entity imports — no extra wrappers, no duplicate code.

Why This Matters

ECA's building-block approach pays off in multiple ways:

• Rapid prototyping – Create features in minutes, test immediately, and iterate without redeploying code.
• Reusability – One transformation or condition can power multiple features across your site.
• Collaboration – Site builders and stakeholders can adjust scenarios without touching code.
• Maintainability – Updates are simpler and safer — modify the ECA scenario instead of rewriting modules.

A New Default Mindset

The takeaway is simple: stop defaulting to "write a new module". Start thinking in terms of events, conditions, and actions.

Code becomes a last resort, used only to fill in the truly missing pieces. Everything else? Configurable in the UI, testable without redeploys, and reusable across your site.

If you're tired of maintaining a library of single-purpose modules and want a cleaner, faster development workflow, ECA isn't just another contributed module — it's the next stage in Drupal site logic.