Here's a simple patch resolving the issue.
johnjw59 → created an issue.
Attached is a re-roll of this patch for 5.10
I also added a check to see if mailchimp_campaign is enabled before adding the new field and made the field a "webform_select_other" field in case you want to directly add a segment ID.
Attached is re-roll of this patch for 3.x
Attached is a patch fixing the integration. This patch keeps the current behaviour as to not break compatibility with page_manager < 4.0-rc3.
johnjw59@gmail.com → created an issue.
Attached is an updated patch for 2.0.0-beta2
Whoops, missed instantiating the module handler service in that last patch. Here's the correct one!
After using the patch I provided in #2 for a bit, I don't think it's the right approach. Making the data in the cached variable an array leads to it bloating as each field just adds to the array, never cleaning it out. This can lead to some content having the wrong entity passed to the token method.
I think a better approach is to just add an alter there allowing other modules to tweak the data array before it gets passed to the token method. Attached is a patch doing just that (no interdiff as it's a completely different approach). This is also just a must simpler solution I feel.
@darvanen - I will add further documentation and roll a proper MR with this tweak once I have some spare time!
Here's the promised patch. I left the drupal_static key as-is as others may already be targeting it and I didn't want to introduce any breakages.
johnjw59@gmail.com → created an issue.
Here's a patch that just removes metatag_page_manager_page_attachments()
johnjw59@gmail.com → created an issue.
Simply changing the comparison to be strict fixes the error and is probably always the correct approach when comparing objects like this.
johnjw59@gmail.com → created an issue.
Sorry to resurrect this after 6 years (maybe I should have created a new issue?), but the same fix needs to be applied to Vimeo embeds. Patch attached.
Yup, this is an issue!
I think we should keep the call to $mailer->setFrom() as-is though; if a Reply-To header is not present, the default should be whatever the "From" address is. Therefore, my proposed solution is to just clear out any set Reply-To headers before we explicitly add them. Patch doing just that is attached.
We should probably be making use of Drupal's jquery.once library for this as that's the more standard solution. Here's accomplishing the same goal, but using jquery.once instead of a custom class solution.
No interdiff is provided as this is a new patch with no relation to the first.
The point is for it to override the behaviour of all other modules. Some SMTP providers require emails to be sent from a single "From" address. That is also what the field description says it does. If that behaviour isn't wanted, then the field needs to simply be left blank.