Posted by fenstrat on June 17, 2010 at 12:36am
2 followers
Jump to:
| Project: | MailChimp |
| Version: | 6.x-2.0-rc5 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
#600246: provide a block for each individual list provided the great feature of having a block for each individual mailing list. However it also reverted the behaviour of those blocks for authenticated users.
Authenticated users no longer see their mailing lists they are subscribed to with checkboxes (as they do at user/%uid/mailchimp), but now see the anonymous subscription form.
This commit http://drupal.org/cvs?commit=377270 shows a TODO pointing out the fact that mailchimp_subscribe_anon_form() really needs to be refactored. But it also pulled out the call to mailchimp_subscribe_auth_form() from the block view.
Comments
#1
I'm aware of the tradeoff, but felt that this approach makes sense for the majority of uses cases. Still have plans for the major refactor. In the meantime, I'm considering an additional block, like the previous version, that would contain all available lists for a given user as only checkboxes. Would that make sense?
#2
I appreciate the plans for a major refactor, but adding that functionality back would be great. However I can't see the use case to have it as an additional block. Surely the same block which shows a full signup form for anonymous users should switch to show a checkbox to an authenticated user. Aside from the technical function of the code what would be the use case to have this as two separate blocks?
One use case that springs to mind is a site with multiple mailing lists. In this case an authenticated user block could make sense, i.e. manage all their subscriptions from one block. But apart from that I think the most straight forward approach would be for the same block to keep it's functionality be it for anonymous or authenticated users.
#3
> However I can't see the use case to have it as an additional block.
The additional block can be used INSTEAD of the new individual ones, working the same way the previous ones did.
> Aside from the technical function of the code what would be the use case to have this as two separate blocks?
One allows a user to change their MC merge fields from the defaults derived from their profiles. Plus, the checkbox you're referring to is "expensive" in that it must request a users subscription status from MC, which may not be desirable in every case. I understand you're point and will definitely take it into account.
#4
Thanks for clearing that up. I hadn't appreciated you're planning the additional block for use instead of the new individual ones. I can see the use case now, especially given that the checkboxes are expensive due to the having to phone home to MC (would this subscription status be cacheable in user->data or elsewhere?).
Still can't say it makes much sense from an end user / site admin point of view. Clearly distinguishing the use/functionality of the two different block types will be key.
#5
Check the latest dev release (or checkout from CVS). I addressed this, along with some other refactoring and bug fixes.
#6
Wonderful, seems to have restored the previous functionality. The blocks change functionality seamlessly from anonymous to authenticated. Thanks!
#7