Just downloaded the newest update, and it appears there is no way to get the form builder function to build the mergefields so the user can actually sign up for anything.

EDIT: The fields do appear for anonymous users, but only a checkbox is rendered for non-anonymous users. Is this preferred behavior over previous versions where the signup fields would always render? If so I can patch it up in my local module to get the desired functionality, but it definitely seems counterintuitive for a signup form to not have any signup fields at all.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

gcb’s picture

Status: Active » Closed (works as designed)

The functionality is intentional. For non-anonymous users, they have an email address and other information associated with their user account, which is what will be used. This is the result, in part, of making "anonymous list" a setting as opposed to making it an entire list type.

Letting logged-in users sign up email addresses other than their account email, then letting them having control over their subscription (but not that one) is pretty confusing, or seems so to me.

Perhaps we need to consider some more obvious display option here, but this is not a bug.

patpluspun’s picture

I understand. May I perhaps suggest disabling the email field for authenticated users? If a site builder has the intention of collecting first and last names in their newsletter, but has no need to add the relevant fields to the user object (as there is no use for them in the site itself), there seems to be no built-in way to collect these from an already registered user.

gcb’s picture

Category: bug » feature
Status: Closed (works as designed) » Active

I see what you mean. We'll convert this to a feature request. (If others would find this useful, please say so here.) We have some plans for future architecture improvements that may allow for this functionality incidentally in the future anyway.

gcb’s picture

Patch here. This should also treat authenticated users as anonymous for cases when they are not explicitly given access to a list, which is much more sensible.

After patching, check the list settings for the option "Present the subscription block with fields even to logged-in users." I'll come up with a cleaner/name description before rolling into a release.

Please test this patch and provide feedback here!

gcb’s picture

Status: Active » Needs review
gcb’s picture

Issue summary: View changes

Edited with new information

nadavoid’s picture

The patch seems to work fine for controlling access to the block. However, it does not affect the display of the newsletter subscription page at /mailchimp/subscribe. It has to do with mailchimp_lists_get_available_lists().

tripper54’s picture

Issue summary: View changes

Patch in #4 works for me. Thanks for rolling this, I was worried I was going to have to hack the module to get this behaviour.

zonesny’s picture

Patch in #4 worked for me as well. Thanks!

CodigoVision’s picture

Thanks for the patch! In my opinion the best solution would be to pre-populate fields for registered users. It's important to show the fields because it gives another opportunity for a user to fill out optional fields that may not have been filled out on registration.

joelpittet’s picture

Version: 7.x-2.12 » 7.x-2.x-dev
Status: Needs review » Needs work

Awesome work getting this UX issue fixed.

Wondering if maybe this should be a different type of block entirely? That way it doesn't have to do as much logic checking/processing and it would be easier to pass the logged in user's email address as default field value (campaignmonitor's block does this and is highly hackable with a hook_form_alter() I've found out;-) @see http://drupalcode.org/project/campaignmonitor.git/blob/4af5b9f4144ffd56e... ).

Never the less thank you for the working patch!

Just a quick drive-by review:

  1. +++ b/modules/mailchimp_lists/mailchimp_lists.module
    @@ -858,22 +858,33 @@ function mailchimp_lists_block_view($delta = '') {
    +  $accessable = FALSE;
    

    I noticed that this was spelled incorrect before but it should be '$accessible' or to avoid this problem change it to $has_access.

  2. +++ b/modules/mailchimp_lists/mailchimp_lists.module
    @@ -858,22 +858,33 @@ function mailchimp_lists_block_view($delta = '') {
    +  $present_as_anonymous = isset($list->settings['present_anonymous_block_universally']) && $list->settings['present_anonymous_block_universally'];
    

    This could do with a !empty() to keep it short and sweet. empty does an implicit isset() check.

bogdan khrupa’s picture

Hello,

Just now i'm apply patch on my dev site and their correctly worked!
When planned to apply this patch to the module?

Yoran Scholiers’s picture

Is this also going to be added to the 7.x.3 version?
Prepopulating the fields is the better way imho.

gcb’s picture

Yoran, the 3.x version uses a different concept of how these forms work entirely. If you want to prepopulate the fields when users are logged in, you can that pretty easily with hook_form_alter. It might be an optional feature we would add to 3.x in the future, but if you want that you need to create a "feature request" ticket under the 3.x Version tag.

amytswan’s picture

Status: Needs work » Closed (won't fix)

“And now our watch [for support of the 7.x-2.x version of the MailChimp module] has ended…” With the approaching deprecation of MailChimp’s API version 2.0, I’m sad to say we too must turn the page. This branch will become unsupported in early October and officially deprecated by the end of this year (2016).

Fret not! The 7.x-4.x and 8.x versions come highly recommended. Both are using Mailchimp’s new API 3.0 and are being actively maintained. If you find this issue still exists on either the 7.x-4.x or 8.x branches, let us know by opening a new ticket. “What is dead may never die, but rises again, harder and stronger!”