Closed (fixed)
Project:
Mailchimp
Version:
6.x-2.0-rc4
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
27 May 2010 at 06:02 UTC
Updated:
5 Aug 2010 at 17:00 UTC
Jump to comment: Most recent file
Comments
Comment #1
fenstratI can confirm this.
Comment #2
levelos commentedThis is already fixed in the latest dev version. I'll create a new official release soon.
Comment #3
tylor commentedI'm still having this problem with the latest dev release and with rc5 (released since the last message). What ideas were there to fix this? I would like to help if I can.
Comment #4
levelos commentedThe latest release now has a block for each list, so it's really possible to have the same issue as originally reported in this issue. Please provide more details of how to reproduce the issue and the setup you have.
Comment #5
tylor commentedJust tested again on a fresh install of Drupal 6.17 with the latest dev snapshot (from 2010-06-26) of Mailchimp and still having the same problem. PHP 5.3.1.
Steps:
0. Clean install of Drupal, enable Mailchimp.
1. Enter API key on /admin/settings/mailchimp.
2. Turn on two newsletters for each role and set to opt-in on /admin/settings/mailchimp.
3. Visit /mailchimp/subscribe with anonymous user and try to subscribe.
or
3. Set blocks to left region.
4. Visit any page with anonymous user and try to subscribe.
In either case it tells you that it has subscribed to the first newsletter in the page and, checking the list management in Mailchimp, this is true.
Comment #6
levelos commentedProblem identified and resolved in the last commit. If there's more than one available list, /mailchimp/subscribe now presents a combined form with a single submit button. Individual form are still available via blocks. Please help test and we'll get a new release out.
Comment #7
fenstratI tested this (again) with mailchimp 6.x-2.x-dev with multiple mailing lists and can't confirm #5
Both anonymous and authenticated user subscribe/unsubscribe works fine from both user/%uid/mailchimp and their respective blocks.
Comment #8
tylor commentedTested again with dev snapshot from 2010-06-29. It now appears to be a form validation problem, since it seems to still validate the first form if I just fill out the second... see attached.
Fenstrat can you confirm that you were successful with both newsletter forms on the same page (ie. on /mailchimp/subscribe) for an anonymous user?
Comment #9
levelos commentedtylor - Your first screen shot, where there are two blocks on the same page, does appear to be a bug. Although I don't know where the bug lies. Either I'm missing something or it's a core bug. The two email fields in this case have unique names and IDs, and are in a different place within the form tree. Not sure why the first would validate when submitting the second.
The second one indicates a tricker problem. If you're presenting user with two anon forms, the only way I can think of to make one optional would be to offer checkboxes, or just make email optional and use the filling in of that field as a trigger to grab the rest of the details and sign up the user. That's what I'm leaning towards.
fenstrat, I'm not following you with #7.
Comment #10
fenstrattylor - No sorry, I had multiple mailing lists but only one mailing list block visible per page. Single blocks like this work fine. As does authenticated subscribe/unsubscribe from user/$uid/mailchimp. As for /mailchimp/subscribe I can't say, didn't even know that page existed till now. So atm I cannot confirm the bug you're seeing.
loubabe - The second issue on /mailchimp/subscribe is certainly a problem. Your idea of making the email's optional seems like the most straight forward solution.
Will be away from work for a few days but will look into this again after that.
Comment #11
fenstratOk, problem still persists for anon users on mailchimp/subscribe - all email fields are required so it's impossible to signup unless you signup for all newsletters. Using mailchimp-6.x-2.x-dev from 06-07-10, it appears this commit didn't fix this issue.
Comment #12
levelos commentedFixed with commit #391732.
Comment #13
fenstratYep, works well. Thanks.
Comment #14
tylor commentedFantastic, confirmed as working too. Thanks loubabe!