Apologies for the long post – this is more involved than I originally thought.
I knew the import format had changed, and we have updated our import spreadsheet accordingly. I originally used the help page to format the new spreadsheet, but when this didn’t work, I exported our data via the s2 Export Users option using this process:
- Create a user via the backend, including custom fields
- Export that user
- Delete that user
- Re-import that user
and no custom profile field data was brought back in – even though it was there in the exported csv file.
However, I think this problem might have a slightly obscure root cause. We’ve modified the imports-in.inc.php file (via mu-plugins) to process list servers on import. There’s a support thread here about what we’ve done, including the additional code, and all has been working fine. However, this particular user I was exporting / importing above was for a membership level that doesn’t have an associated Mailchimp list, and so the import routine logs an error that it was unable to process the list sign-up. I wondered if this was causing the problem, so I edited the csv data to associate that user with an s2 level which did have a Mailchimp list (and hence the list signup should work fine). When I imported this data, I got a different error:
Warning: array_merge() [function.array-merge]: Argument #1 is not an array in /home/tctc4me/public_html/learn.tctc4.me/wp-content/mu-plugins/s2hacks.php on line 59
The relevant function we’ve attached to that hook is to ensure the custom fields are passed over to Mailchimp, and here’s the code:
function tctc_merge_filter($merge, $vars) {
$asParts = parse_url(site_url());
if ( ! $asParts )
$host = "unknown";
else
$host = $asParts['host'];
$uid = $vars['user_id'];
$fields = $vars['fields'];
$today = date('Y-m-d'); // yyyy-mm-dd
$cFields = get_user_option('s2member_custom_fields', $uid);
// Only start_date needs checking - others should have been checked by tctc_default_custom_fields()
if (strtotime($cFields['start_date']) < strtotime($today)) { // Start date is in the past - bring it to today
$cFields['start_date'] = $today; // yyyy-mm-dd
// Below is Line 59
$fields = array_merge($fields, $cFields);
update_user_option($uid, 's2member_custom_fields', $cFields);
}
return array_merge($merge, array(
'COURSE' => $cFields['course'],
'STARTDATE' => $cFields['start_date'],
'INST' => $cFields['institution'],
'DEPT' => $cFields['department'],
'SOURCE' => $cFields['source'],
'GROUP' => $cFields['group_id'],
'COHORT' => $cFields['cohort'],
'S2LEVEL' => get_user_field('s2member_access_label', $uid),
'DOMAIN' => $host
));
}
So, $fields isn’t an array, which I guess means where it is initialised with $fields = $vars[‘fields’]; isn’t returning an array for some reason.
I then realised that imports-in.inc.php has been upgraded since we patched it for list server processing. I replaced the imports-in.inc.php file on our server with the latest one from s2, and lo and behold the import worked fine (albeit with no list integration, obviously).
I then applied our list integration patch to the new version of imports-in.inc.php, and now custom fields are imported properly (regardless of whether there’s a MC list associated with the user’s level), so that’s at least one thing fixed. But I am now stuck with the ‘isn’t an array’ message on the merge function above. The patch to imports-in.inc.php is below, and it’s inserted at line 330 of the current version of imports-in.inc.php:
if(!c_ws_plugin__s2member_list_servers::process_list_servers(
$role,
(($role == "subscriber") ? 0 : substr($role, 14)), // Convert from descriptive back to numeric
$user_login,
'xxx',
$user_email,
$first_name,
$last_name,
'',
true,
false,
$user_id
)) {
$errors[] = 'List Server Update failed for user ' . $user_id;
}
Perhaps these two things are unconnected, and I know it’s only a warning from the merge filter. It does look like it’s working, in that the custom fields are being updated and sent across to Mailchimp. Is it just that we need to check for an empty result when initialising the $fields variable?
And secondly, is there a more reliable way to achieve the the patch to imports-in.inc.php? Obviously we’ll need to check if this file has been upgraded each time we update the plugin – something I hadn’t thought to do, and it would be great if there was some way to automate this. Or perhaps there’s a hook available now which could do this?
Many thanks.