🇺🇸United States @xenophyle

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.

xenophyle → created an issue.

Looks like WebhookHashTest needs updating since the hash now gets set upon installation.

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

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

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

Ok, makes sense.

Some things to test
- Does this work on a signup form implemented as a page rather than a block?
- Does it work with signup forms that submit with AJAX?
- I'm guessing you tested this but I'm not familiar with the UUID Interface -- are the UUIDs the same for each instance, e.g., if you place a block in the footer on multiple pages will the UUID stay the same across pages, and across installations, for example both on a dev and live site?

There are some changes that look like they may not be central to this fix, like removing the constructor for the subscribe block and using setMessenger. If they are not required for this ticket they should be put in a separate issue to keep this fix easier to understand.

Thanks!

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

Tests no longer failing for 2.x

Hi dj1999,

In MailchimpSignupPageForm::buildForm()

      '#attributes' => [
        'id' => 'mailchimp-signup-submit-' . $this->getFormId(),
      ],

for the submit ID might be a simpler solution. Can you check if this serves your purposes?

xenophyle → created an issue.

xenophyle → created an issue.

@MegaChriz Might as well make translatable strings a new issue.

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

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

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

Duplicate of 🐛 Signup form labels are hidden Postponed: needs info

I don't think this formatting is coming from the module. Might any of your active themes apply this formatting to input labels?

I've been working on this and hope to have a fix soon.

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

I'm thinking this won't work when the email address is on a referenced entity. So you have a content type with the mailchimp subscription field and maybe a reference to a user. The subscription field uses the user's email field. If the user entity gets updated, this module won't notice and be able to unsubscribe the old email.

Or does anyone have that working?

Duplicate of 🐛 Update mailchimp_update_member_process for $tags Active

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

Do you think we should go forward with this even if it might exclude some non-entity-reference fields that should not be excluded? Are we feeling biased toward action?

Marking as a duplicate of 🐛 mailchimp_lists_load_email fails to find email address field when attached to a related entity. Needs work

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

Noting that the description does show in 2.x.