🇺🇸United States @xenophyle

I've just released 2.1.0-beta3, which should have that fix.

xenophyle → created an issue.

Made a change to the patch that allows roles from a referenced entity.

xenophyle → made their first commit to this issue’s fork.

I'm just realizing there is some relationship between COI and core config validation. We plan to eventually support the core config validation and I'm wondering if applying this MR will create any kind of conflict. If we have both "#config" and '#config_target" attributes will that cause any weirdness or is it simply that if your suggestion in 📌 Drupal >=10.2: Use the new #config_target Form API property Active is followed we will need to update the code to remove the "#config"s?

The code added in the patch comes after a call to mailchimp_lists_load_email(), which is already trying to validate the email address. Would it make more sense to put your improved validation in mailchimp_lists_load_email() instead of mailchimp_lists_process_subscribe_form_choices()?

xenophyle → made their first commit to this issue’s fork.

The patch from #15 was causing
InvalidArgumentException: "content" is an invalid render array key. Value should be an array but got a string. in Drupal\Core\Render\Element::children() (line 97 of core/lib/Drupal/Core/Render/Element.php).

The error went away when we reverted to patch #12.

Addressed by ✨ Allow to hide error messages on frontend Needs review

D10 compatible since 2023

This sounds like an error on the Mailchimp API end. Have you still been seeing this lately?

Went in the direction suggested in 🐛 Error logging seems to be broken Needs work

Seems fixed by 🐛 404 resource not found (when updating amount in cart, WSOD) Needs review . Reopen if that is not true.

I think they mean in the fulltext search filter configuration in a view

xenophyle → made their first commit to this issue’s fork.

xenophyle → made their first commit to this issue’s fork.

Aren't the first, last, and email fields required in the form? I am not able to submit the form without these values and cannot the reproduce the error.

If anyone is seeing this in any 2.x, could you test the changes from the patch and report whether that fixes it for you? Thanks.

Some of these changes were done recently as part of another fix. I added some of the changes for the mailchimp_ecommerce_page_attachments() part but won't be adding an alter hook for the campaign ID since it is no longer being sent to the API (https://mailchimp.com/help/about-mailchimp-attribution/).

@susie Since this version still supports PHP 7, I committed a version of your solution that is compatible with that.

@nadja_stu @sriharsha.uppuluri It sounds like the additional check on $lists was necessary. Let me know if the latest changes helps.

Next step: port to 3.x.

@akulsaxena I am working on this but need to stop for a couple hours, so it won't be ready until then.

xenophyle → made their first commit to this issue’s fork.

@nadja_stu If you are using 3.0.0, you should use 3.x-dev →

@akulsaxena, yes, you are right!

@sriharsha.uppuluri It is not clear to me what changes you applied. Did you use https://git.drupalcode.org/project/mailchimp/-/merge_requests/96.diff?

Akul, the tests in this branch, 2.x, are now targeting D10. I notice there are 5 failing phpunit tests, most of which will be fixed by the solution to 🐛 After upgrading to Mailchimp 2.2.5, failure to get lists results in a fatal error on login Active .

Merged MR, cherry picked to branch 3.x.

Yes, this doesn't work. The labels set do not appear in the form.

xenophyle → made their first commit to this issue’s fork.

@mlncn does @ericgsmith's modification work for you?

This change is included in the new release 3.0.0.

xenophyle → made their first commit to this issue’s fork.

Dupilcate of 📌 Drupal 11 compatibility fixes for mailchimp Active

Great tip! I just updated 2.x-dev with a change I think should fix this. Do you want to see if it helps?

Using these steps, I was not able to reproduce the problem; I was still seeing the full set of options for email address.

-Install Mailchimp 2.2.2 on a standard Drupal install of 10.3
-Enable Mailchimp and Mailchimp Audiences
-Authenticate with OAuth
-Create a subscription field on users
-Set email address merge field to the user email property
-Update to Mailchimp 2.2.4 and clear caches

Is there any additional information you might be able to supply? Are you using any patches?

Are you able to experiment with 2.2.4 to see if that fixes it?

xenophyle → made their first commit to this issue’s fork.

What if you go to the "Manage form display" page and change the widget of the subscription field to "subscription form"?

Looks good, thanks!

xenophyle → made their first commit to this issue’s fork.

I updated the MR to check that $instance->getValue()['interest_groups'] is an array since $groups_default will be passed to a function that expects an array.

Do you want to verify that this works on your installation?

xenophyle → made their first commit to this issue’s fork.

But what about other entity types or custom routes? These are surely rare but I don't want to break existing installations if someone needs to resave the form, and their destination page is no longer allowed by the field.

@matthiaso

Here is the expected behavior
- 'Require subscribers to Double Opt-in' is selected for a form on the Drupal site
- A site visitor subscribes using this form
- The subscription status at Mailchimp is set to 'pending'
- Mailchimp (not the Drupal site) sends a confirmation email to the subscriber
- The subscriber confirms
- The subscription status at Mailchimp is set to 'subscribed'

When I was testing this I found that the confirmation email went to the spam folder.

Are you also using 2.2.2? If so, can you try the latest version?

@zann1e Are you still having this problem, and are you still on 8.x?

Finally got to this! Thanks for the MR.
When I tried the steps to test it actually did send me a confirmation email (went to spam) but it is best to just keep a subscribed email as subscribed.

xenophyle → made their first commit to this issue’s fork.

This looks like it would only work when the destination page is a node, specifically a basic page. This would probably cover most use cases but would cause a problem for the odd site whose destination was another type of entity or custom route.

I could not reproduce this. It looks like part of the steps to reproduce would be to install and set up simplenews some way?

Added spin-off ticket 📌 Use translatable strings for literals Active

xenophyle → created an issue.

Based on a web search of this phrase, this is an issue on the Mailchimp end of things and isn't related to the module.

Are you seeing it on any other "Add field" pages, for example, on the node "Add field" page?

If you save the settings the message should go away when you view the form again.

Merged MR 88 because it applied to the dev branch.

xenophyle → changed the visibility of the branch 3143873-add-email-autocomplete-attribute to active.

Thanks for your contribution, but we have asked Intuit to provide the graphic so we can be sure it meets their preferences.

Do you have a folder vendor/thinkshout/mailchimp-api-php? This should be downloaded when you run composer require drupal/mailchimp:^2.2 or composer install any point after that.

Have you verified that the latest version of the mailchimp module has been downloaded to your installation?

When and where are you seeing the notice about package mailchimp/mailchimp? That should not be needed at all.

Marking as fixed. Please reopen if this is not accurate.

This looks good, I think. Is it correct to say this will not cause any hiccups on an existing installation that currently uses the cache, the code will simply see the collection is empty and fill it?

Yes, we can definitely reduce the severity.
As far as reducing the frequency, are you using any kind of captcha?

This looks like an error you would get when autoloading is not getting triggered. If clearing the cache does not fix this, you might consider using composer, which handles autoloading, as suggested on the Ludwig project page.

xenophyle → made their first commit to this issue’s fork.

Do you think you could add a setting to make this non-logging optional?

@Matt B The scope has crept to include other merge data besides email, which has drawn this out into a major project. There is an MR in progress that needs testing and review.