Create a recipe that uses ECA to set up one-click Mailchimp integration

Created on 29 July 2025, about 1 month ago

Problem/Motivation

We'd really like to have one-click Mailchimp integration in Drupal CMS.

Mailchimp's authentication with OAuth is already really slick, and all we need is some kind of recipe that expedites the initial set-up process after you, as the site owner, have successfully authenticated with Mailchimp.

The set-up process, such as it is, includes:

  • Creating some signup entities, based on the lists you have set up at the Mailchimp end
  • Creating some signup forms, based on those signup entities

How can we translate this to a recipe? Why, with Drupal CMS's favorite tool: ECA, which is the best tool out there for implementing complex workflows without code.

Let's create an ECA model which:

  • Springs into action when authentication has been finished. We can detect this because the access_token config setting will change. At that point...
  • ...the model should invoke a custom action (supplied by a new Mailchimp submodule) which queries the Mailchimp API for all currently defined lists.
  • The model should take the output of that action (a list of lists), and for each one, create a signup entity.

The model should also take action whenever a signup entity is created -- that action should be creating a signup form for that signup entity.

We'll package that ECA model into a new recipe (name TBD). The recipe will expose a "Log in" task to Project Browser (see https://project.pages.drupalcode.org/distributions_recipes/integrations.... for info) which, when clicked, sends you to the OAuth authentication form. The recipe will also, as a matter of course, unconditionally opt the site into using OAuth to authenticate with Mailchimp.

✨ Feature request
Status

Active

Version

3.0

Component

Signup Module

Created by

πŸ‡ΊπŸ‡ΈUnited States phenaproxima Massachusetts

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @phenaproxima
  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    I'm getting started on this.

  • @jurgenhaas opened merge request.
  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    The action plugin appeared to be straightforward, already available in the MR above. I'm now building the ECA model that creates the entities and blocks.

  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    This is now ready for review. Here are the steps to take:

    • Checkout the MR above
    • Unpack the attached recipe
    • Add the requirements in composer.json of the recipe to the requirement of the Drupal project
    • Update composer to install all the dependencies
    • Apply the recipe

    The ECA model currently responds to a changed api_timeout config value. This can later be changed when oauth is being sorted out.

    This model reads the lists from the MC account and then creates (or updates) basic signup entities and blocks. There are still some details that need to be sorted, especially the merge field information that's in the signup entity. I'm not sure where they're coming from or how they get generated.

    If you want to review or modify the ECA model, you need to install the bpmn_io module and then go to /admin/config/workflow/eca where you can view or edit the model.

  • πŸ‡ΊπŸ‡ΈUnited States gcb
  • πŸ‡ΊπŸ‡ΈUnited States gcb

    Exciting stuff! Some thoughts here

    I've attempted to add an ECA Action that collects our mergevars. You can see it here.

    Using that, and the config file attached here, I thought I could initialize those in the configurations. Any feedback on those elements would be welcome, I'm not having great success getting a good configuration created.

  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    I've attempted to add an ECA Action that collects our mergevars. You can see it here.

    Amazing, well done.

    Using that, and the config file attached here, I thought I could initialize those in the configurations. Any feedback on those elements would be welcome, I'm not having great success getting a good configuration created.

    There are 3 problems I found:

    • You've change the ID of the entity to signup_form_[item:id] but the config name remained unchanged as mailchimp_signup.mailchimp_signup.[item:id]. That causes a problem that the config name doesn't match the entity ID and that makes it invalid. Please keep that consistent.
    • In the condition where you check if the list of mergevars equals zero, there is a missing "s", you check against the list mergevar, but that needs to be mergevars.
    • And the last one took me a while to see what going wrong. If you run the ECA model twice, then the config entity is correct, but not for the first time. The reason for that is that you call mailchimp_get_mergevars in your new action plugin before the signup entity has been created. That seems to be causing an issue.

    Hope this helps you going the next steps. Please let me know if I should have another look when you addressed those issues.

  • πŸ‡ΊπŸ‡ΈUnited States gcb

    Ok @jurgenhaas -- here's a PR with an improved plugin, the foundation of an actual api service, and here's a working version of our ECA setup that uses it (renamed awkwardly by drupal.org security)

  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    @gcb I guess there must be some updated or enhanced PHP code but I can't find that. Could you commit that to the existing MR?

  • πŸ‡ΊπŸ‡ΈUnited States gcb

    Yeah it would help if I linked to the MR :/

    https://git.drupalcode.org/project/mailchimp/-/merge_requests/111

  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    OK, thanks @gcb. I've merged that MR into MR!110 which is the attached MR to this issue, that's probably easier to handle?

    The current code looks really good and it works as expected.

    In Slack you mentioned that you're now looking for a new event: "Now to trigger the authentication when the recipe is enabled…". However, what's already in the ECA model is an event that triggers the thing when the API key gets updated. This could be adjusted to oauth settings when you're using them instead. I don't think that you need yet another event which is recipe related, because that would be dispatched too early, probably. You want to run when authentication is being configured.

  • πŸ‡ΊπŸ‡ΈUnited States gcb

    Oh, there sure is! I didn't even notice the second trigger. So we would just remove the Config change trigger from our existing recipe.

Production build 0.71.5 2024