PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

Prevent MailChimp Add-on from overwriting subscribed users' data with blanks

  1. Phil
    Member

    Feature Request for MailChimp Add-on
    Allow devs to prevent blank fields from overwriting existing data for list members who are already subscribed.

    Example Scenario to Prevent

    1. User subscribes to mailing list, adding name to MC list.
    2. User forgets and subscribes again (via GF MC add-on), but leaves name field blank.
    3. MC add-on updates/overwrites list member's name with blank values.

    Potential Code Adjustment
    A new filter, perhaps 'gform_mailchimp_allow_blank_overwrite', could give GF users control over whether fields left blank will overwrite existing data for subscribed users.

    For example, consider replacing these two lines of GFMailChimp::export_feed() ...

    self::log_debug("Calling - listUpdateMember ...
    $retval = $api->listUpdateMember($feed ...

    ... with these lines ...

    $allow_blank_overwrite = apply_filters( 'gform_mailchimp_allow_blank_overwrite', ... // defaults to false (some may argue for true)
    // maybe remove blank fields from $merge_vars
    if ( ! $allow_blank_overwrite )
      $merge_vars = array_filter($merge_vars);            
    
    if ( ! empty($merge_vars) ) {
      self::log_debug("Calling - listUpdateMember ...
      $retval = $api->listUpdateMember($feed ...
    }
    else
      self::log_debug("listUpdateMember not called because $merge_vars was empty ...

    In limited tests, this worked for me, without breaking anything that I noticed. Time will tell.

    Thanks for the great work.

    Posted 11 years ago on Saturday April 6, 2013 | Permalink
  2. I'll bring this to the attention of the development team.

    Posted 11 years ago on Sunday April 7, 2013 | Permalink
  3. Hi, Phil,

    I have added this issue to our feature/bug tracking tool. I need to discuss this further with the team to see if a filter is adequate or if we need to rethink some logic.

    Posted 11 years ago on Tuesday April 9, 2013 | Permalink