About: Andy Burnett

OK – I _think_ I’ve temporarily fixed this by changing the slug of the ‘Sign In’ page from ‘login’ to ‘log-in’. At least there’s no 404s now on logging out. Not sure what else might be broken now though :)

I’m going to start from a clean install of WP and try to work out if/when/how this unravels…

Still be interested if you have any pointers, but not urgent now.

Thanks.

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:

1. Create a user via the backend, including custom fields
2. Export that user
3. Delete that user
4. 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.

Thanks for the analysis and advice – I would certainly agree we are trying to do more than the mailchimp filter is designed for, and so separating that code out makes sense.

The only concern I now have is that those user fields are needed on the mailchimp side as well, so we need to be sure the custom fields are updated before any calls to the mailchimp api. I presume things would happen in the right order, but do you know for sure if ws_plugin__s2member_during_configure_user_registration_front_side is called before ws_plugin__s2member_mailchimp_merge_array? In general, is there an easy way to know in what order these filters are applied?

Thanks again!

PS – off topic: I can’t find the tag to put those filter names in ‘code hilite inline’ format as you did – the code tags always create a block for me – is there a trick? Tx!

Re the default fields – those options only seem to take effect if the field is visible to the user. This is pure metadata and is set to Invisible during and after registration. The default value is set in the options, but comes in as an empty string in this filter.

Re the date – thanks, I’ll change that to call empty(). Out of interest, what’s the advantage of a second call to date() in the assignment, rather than just using $today, which is already assigned?

More importantly, yes, the output included ‘fields updated’. To test, I created a user account with a ‘Start Date’ of 2012-12-19 and role of ‘Subscriber’. I then promoted that user to ‘s2 Level 1’ – here’s the full output when the debugging ‘echos’ are uncommented:

$cFields[course]: Faculty
$cFields[start_date]: 2012-12-19
$cFields[institution]: my inst
$cFields[department]: my dept
fields updated
$cFields[course]: Faculty
$cFields[start_date]: 2012-12-20
$cFields[institution]: my inst
$cFields[department]: my dept
reloaded custom fields
$dFields[course]: Faculty
$dFields[start_date]: 2012-12-20
$dFields[institution]: my inst
$dFields[department]: my dept

What’s really odd is the last call to get_user_option() uses a different array ($dField[]) and does load the correct data. But it only seems to persist like that until the end of the function. The userlist on WP still shows 2012-12-19 for that user. I can change the ‘Start Date’ from the Edit User page on WP, and then it does stick.

Thanks – is this on a roadmap / timeline anywhere? Just wondering if we can wait for the next release, or whether we need to fix it sooner than that…

Thanks.

Regarding user deletions and the setting you mentioned (Dashboard -› s2Member® -› API / List Servers -› Automate Unsubscribes/Opt-Outs), I have ticked the top-level box labelled ‘Anytime a User is deleted ( including manual deletions )’.

I just deleted 16 users, but only the very first was unsubscribed from the MailChimp list, and the API logs from MC show only a single call was made. Could you confirm if this is a bug, and if it is, if there’s any more information I can dig out of logs, etc. which might show what went wrong?

Thanks!

Update: I just deleted a few more test users, this time in 2 goes, and saw 2 calls to the MC API, removing 1 user each time. So I suspect something which should be in a loop isn’t :)

• This reply was modified 4 years ago by  Andy Burnett.

On a related but separate issue, I’m having problems with SublimeText and imports-in.inc.php – specifically it’s causing SublimeLinter to freeze! Would you be happy for me to post the contents of just that php file to the SublimeLinter support group so I can ask why? It’s making editing it a pain, as I have to remember to turn off linting before starting!

Thanks!

• This reply was modified 4 years ago by  Andy Burnett.

Thanks – I’ll take a look at that and see how we get on. We’re only talking about a few tens of users at a time to import, but we might be doing it on a regular basis (rather than hundreds or thousands once in a blue moon).

Does that principle apply to bulk deletes via the WordPress system too? I’ve noticed quite a discrepancy between the WP list and MC list as we’ve been testing this…

Yup – that’s what I was referring to in the original message. I ticked the main box which then ticked the 3 sub-boxes.

Thanks – I guess that would be doable. I also found this code from Raam – is that the kind of thing we’d need?

// Get an array of all the users' s2Member Custom Fields
$custom_fields = get_user_option("s2member_custom_fields");
// Set the value for a specific field ($custom_fields is an array)
$custom_fields["custom_field_name"] = $NewValue;
// Update the Custom Field data
update_user_option($user->ID, "s2member_custom_fields", $custom_fields);

Hmm – that’s a shame. It will make me the bottleneck if he can’t post things too, and he won’t get notifications of replies… Is there no way just to elevate his account as if he’d paid? If it’s a ‘number of people’ thing, it would be better that he has access to the support forums rather than me…

Thanks,

Andy