bug: when using an address merge field on a Mail Chimp subscription form, data doesn't upload from a drupal based, MailChimp module enabled subscription form to the MailChimp Newsletter service.
To reproduce:
Create a subscription form at MailChimp.com that includes an address field and make sure it has a merge variable name.
At drupal site, sync with Mailchimp to get the new form
Test your form by going to /mailchimp/subscribe
What I see is that the address field is a single textbox, not the mutli-textbox grouping at MailChimp.
What worse, is that when I type in an address into the address field and submit the form, the information is lost.
Comments
Comment #1
rickmanelius CreditAttribution: rickmanelius commentedThis also happens for me. None of the information makes it back to Mailchimp.
See similar issue here - http://drupal.org/node/581494
It seems its by design that the address fields are not broken down to their individual components. And this essentially renders them ineffective.
I've tried tinkering with this, but it's a bit more complicated than my current knowledge level will allow me to fix!
The magic appears to happen here...
Unfortunately, my client insists on the form people on his site... and so I can't even embed a form from mailchimp either! So I'm kinda stuck on this...
It doesn't seem to be a simple modification, as both the collection and submission portions have to be synced up.
Comment #2
rickmanelius CreditAttribution: rickmanelius commentedNevermind... it does seem you can do a copy/paste of the full form.
http://server.iad.liveperson.net/hc/s-31286565/cmd/kbresource/kb-8430247...
Not as convienent, but doable for now!
Comment #3
rickmanelius CreditAttribution: rickmanelius commentedBTW, I've been messing with this all morning. But yes, if you absolutely need anonymous user subscriptions with address field informatin, you can easily do so by going to the form creator, getting an embeddable version with the non-required fields listed as well... and then make sure you have all the proper JS files included when you call this form.
This is probably a better solution for my case... but on another site, I want to have authenticated users with address information, so the merge vars thing is still a sticking point.
Comment #4
Exploratus CreditAttribution: Exploratus commentedsoooo. does this mean you cannot import an address from Drupal to Mailchimp? Really? Seems like an obvious need.
Comment #5
levelos CreditAttribution: levelos commentedAddress fields are complex multi-part within MailChimp and can't be merged with a single token value. As a stop gap, I've prevented them from being used as a merge field and added some messaging along those lines. We need to move this into a feature request for the 7.x branch for supporting more complex merge fields.
Comment #6
chrisdfeld CreditAttribution: chrisdfeld commentedSorry to drag up an old issue, but I wrote some code a while back to handle MailChimp's combined address fields and have been meaning to share. This code can be used inside a custom helper module you would create and it maps Drupal address fields to MailChimp format only (not the reverse). Replace 'myhelpermodule' with your own module name in the code below. You must create Drupal profile fields corresponding to the MailChimp combined address field components, as follows:
The Country field selection options must match the standard list of countries MailChimp offers in their drop-down list. You can scrape that list from any MailChimp sign-up form that uses a combined address field, like this one: http://eepurl.com/sVqL. You just need the textual country names, not MailChimp's numerical values, and be sure not to pick up any stray trailing spaces.
Make note of your Drupal internal field names and insert them in the appropriate spot in the code below. After enabling this helper code there will be a new merge key named "My Helper Module: MailChimp Combined Address" that can be used for mapping. Please note that I used this code with version 6.x-2.0-rc4, so it's possible the change levelos references above has altered the procedure in the interim.
Apologies for the rough nature of this write-up, but I no longer use this module and didn't find time to create a proper patch. I figured it would be better to post as-is rather than let it continue to collect dust.