Update/sync optional lists as well as required lists with cron

grobot - I'm not seeing how this patch will solve the problem. The pending flag is only flipped for required lists, so there are many other changes that would need to be made for supporting cron management of non-required lists. Hopefully not that many, but at least some others.

please can we have this feature! Would like to unsubscribe users who delete their accounts on the website without having to manually sync lists

In my case, we wanted to retro-actively add all users of a certain role to an optional list. I switched the list to "Required" during Cron and then switched it back. I'm not sure if this work-around causes any issues?

I've gone through the mailchimp module because I was having this problem as well.

After debugging the code, I've come to the conclusion, that the 6.x module is full of bugs and needs to be properly reviewed.

With that said, I've started the process and resolved a bunch of problems for my particular use case.

--
CRON SUBSCRIBE

First problem I was having was that cron was not actually subscribing users to "optional lists". I've resolved this problem with my batch by iterating over all lists, instead of just optional ones. In order to get subscribed in cron though, the user will need to have this flag set in their $account->data['mailchimp_list_' . $LISTID]. I believe the module is already doing this, so this is the information I'm using to determine which lists they should get subscribed to.

--
CRON UNSUBSCRIBE

There was also a problem, where during cron if the user getting subscribed to a particular list "List 1" which his role is apart of, but his roles are not apart of "List 2", the user while he'll get subscribed to "List 1", will get un-subscribed from "List 2". This is a problem in my opinion. "List 2" in mailchimp might be a list you don't want to have in your drupal site, so you've removed all roles from it. Perhaps it's a list you are using on your Facebook. Now if someone has registered to "List 2" via facebook, and then registered on your website for "List 1", there's no reason why the Drupal module should un-subscribe this email address from "List 2" simply because it's hidden on the Drupal site.

I've left in a way to get "Un-Subscribed" from "List 2" though. This will be the case, where in $user->data['mailchimp_list_LIST2"] is set to Subscribe, where this role does not have access to subscribe to this list. It will also un-subscribe the user to LIST2, if $user->data['mailchimp_list_LIST2"] is set to 0 (won't unsubscribe if the key is never set).

--

_mailchimp_get_api_object() was improperly written and tests for it failing will always return TRUE.

I've changed this function to become a factory function always returning a static object. This should speed things up a little.

There was another problem with this function in that while it was testing for existence of an $q->errorCode upon creation, since there are no remote calls in the function, it will always be set to blank and thus this function will never return NULL.

The problem with this is that other code in the module expects this to return NULL if something fails. A quick hack I added to resolve this (as I didn't want to refactor the entire module) was to call ->lists() in the constructor, so we'll at least initialize the errorCode function and can fail appropriately. This is a hack and should be resolved.

--

MERGE KEYS & MERGE VALUES was broken

the merge_keys and merge_values external hooks, while written with good intentions for allowing others to add in new tokens, I don't believe would have actually worked as it called module_invoke_all which uses array_combine_recursive.

The problem with that is if you have two modules which return something like

function MODULEONE_mailchimp_merge_vaues($user) {
  return array('apples' => 'red', 'pinapple' => 'yellow');
}

function MODULETWO_mailchimp_merge_values($user) {
  return array('apples' => 'green', 'grapes' => 'purple');
}

$results = module_invoke_all('mailchimp_merge_values', $user);
/* result looks like this */
$results  = array(
  'apples' => array('red', 'green'),
  'pinapple' => 'yellow', 
  'grapes' => 'purple',
);

So I've changed this functions to look like this, which replaces the values of the keys instead of appending to them in an array.

/**                                                                                                                       
 * Get the available merge var keys                                                                                       
 */                                                                                                                       
function mailchimp_get_merge_keys() {                                                                                     
  // We can't use module_invoke_all because it uses array_merge_recursive,                                                
  $results = array();                                                                                                     
  foreach(module_implements('mailchimp_merge_keys') as $module) {                                                         
    $func = $module . '_mailchimp_merge_keys';                                                                            
    $results += $func();                                                                                                  
  }                                                                                                                       
  return $results;                                                                                                        
}                                                                                                                         

--

Aside from that I did a little bit extra clean up. There's still more to be done, but I think this resolves a fair bit.

changing status for testbot.

I'll need feedback on whether or not we can depend on $account->data['mailchimp_list_' . $ LISTID] data to keep track of which users have subscribed to which lists.

I don't believe my patch goes far enough, and it appears I can't rely on $account->data for mailchimp information as it's only set upon signup.

Mailchimp for D6 really needs a clean up and re-write. I may decide to either hack more fixes for the current D6 version, attempt a port of the D7 2.x version or drop the module all together. It's up in the air.

If anyone else wants to assist in improving this module under D6 let me know and we can start a sandbox module for mailchimp 3.x in D6.

“And now our watch [for support of the 6.x version of the MailChimp module] has ended…” With the end of Drupal 6 support, I’m sad to say we too must turn the page.

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. “What is dead may never die, but rises again, harder and stronger!”