Support » Plugin: MailChimp List Subscribe Form » mailchimp_widget.php littered with PHP undefined index notices

  • Hi Mailchimp plugin team. I am a developer and looking through your code it seems like you made a bunch of updates to the plugin and missed a few big spots in the widget code. There are also several warnings triggered when submitting an email that could easily be causing problems for people.

    PLEASE: Have your developers enable WP_DEBUG (described below, preferably with XDEBUG so the notices are obvious) and use PHP7 to test your plugin. You will discover a lot of problems.

    Specifically please test loading the widget on frontend, submitting an empty field, and submitting a normal field.

    At various times you pass around a $var array with various settings for form fields. In the functions given $var you test for sub-values like $var['required'], apparently assuming that the fields will be there whether they are true or not. Unfortunately as of right now the code OFTEN runs into errors where the array key doesn’t exist at all, and PHP throws notices if you have WP_DEBUG enabled, which should always be the case when developing.

    Error example:

    ( ! ) Notice: Undefined index: type in /SITE/wp-content/plugins/mailchimp/mailchimp_widget.php on line 348

    First, please ensure your developers are using WP_DEBUG mode when coding your plugin. Not only does it maintain compatibility with other developers who rely on clean output in debug mode, but it is extremely helpful in identifying bugs like this (the bugs I’ll outline below are surely affecting reliability for some users!).

    Note that “Undefined index” errors can be solved in many ways. Most superficially we cause !empty($var['key']), which tests for “true” values in array keys without throwing notices if they don’t exist. This will silence errors but not fix the underlying problems though. Your solutions should ensure that all the expected data is named correctly and being fed into the right functions.


    These happen when I am looking at the frontend of the site where widget is used.

    From what I can tell they are mostly driven by a mismatch between the keys in $var being passed into functions and the keys that the functions try to access. Specifically:

    * $var['required'] is referenced in many places, but the contents of $var show that $var['req'] is probably the value you are looking for.
    * $var['type'] is checked several times, but $var['field_type'] is what’s actually in the array
    * $var['default_value'] is used, but $var['default'] is what’s actually in the array

    For the record, here are the contents of my $var array that is choking your widget code so badly:

    mailchimp_form_field() -- $var:
     [name] => Email Address
     [req] => 1
     [field_type] => email
     [public] => 1
     [show] => 1
     [order] => 1
     [default] =>
     [helptext] =>
     [size] => 25
     [tag] => EMAIL
     [id] => 0


    line ~151: use req instead of required

    //			if ($var['required'] || get_option($opt) == 'on') {
    			if ($var['req'] || get_option($opt) == 'on') {


    line ~340 use req instead of required

    //	if ($var['required'] || get_option($opt) == 'on') {
    	if ($var['req'] || get_option($opt) == 'on') {

    line ~341 use field_type instead of type

    //$label = '<label for="'.esc_attr($opt).'" class="mc_var_label mc_header mc_header_'.esc_attr($var['type']).'">'.esc_html($var['name']);
    		$label = '<label for="'.esc_attr($opt).'" class="mc_var_label mc_header mc_header_'.esc_attr($var['field_type']).'">'.esc_html($var['name']);

    line ~342: use req instead of required

    //		if (!empty($var['required']) && $num_fields > 1) {
    		if (!empty($var['req']) && $num_fields > 1) {

    line ~350: use field_type instead of type

    //		switch ($var['type']) {
    		switch ($var['field_type']) {

    line ~456: use ‘default’ instead of ‘default_value’ because that’s whats in $var:

    //				$html .= '
    //	<input type="text" size="18" placeholder="'.esc_html($var['default_value']).'" name="'.esc_attr($opt).'" id="'.esc_attr($opt).'" class="mc_input"/>';
    				$html .= '
    	<input type="text" size="18" placeholder="'.esc_html($var['default']).'" name="'.esc_attr($opt).'" id="'.esc_attr($opt).'" class="mc_input"/>';


    mailchimpSF_merge_submit() line 817: use field_type instead of type

    //if ($var['type'] === 'phone' && $var['options']['phone_format'] === 'US') {
            if ($var['field_type'] === 'phone' && $var['options']['phone_format'] === 'US') {

    line ~845: use req instead of required

    //        if ($var['required'] == 'Y' && trim($opt_val) == '') {
            if ($var['req'] == 'Y' && trim($opt_val) == '') {

    line ~852: Avoid $merge->$var['tag'] because it throws the following error:

    Notice: Array to string conversion in /SITE/wp-content/plugins/mailchimp/mailchimp.php on line XXX

    and this one (one or both may be PHP7 related but still need fixing):

    Warning: trim() expects parameter 1 to be string, array given in /Users/ungratefulbiped/Sites/dev.advocacy/wp-content/plugins/mailchimp/mailchimp.php on line XXX

    Here’s how the fix looks:

    //$merge->$var['tag'] = $opt_val;
    	$tag = $var['tag'];
    	$merge->$tag = $opt_val


    Thank you for addressing these issues and releasing a new version that supports WP_DEBUG and PHP7 ASAP.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Okay, after even more debugging I’ve finally identified the real problem, which is that the recent update dramatically changed the format of the ‘mc_merge_vars` option in the database, but nothing was done to prevent the old format from triggering neverending errors.

    So the notices I mention above were caused by my list being saved in the old format but run by the new code. When I resaved my list the result was all my “fixes” became notices since the new code didn’t have the old fields (‘req’ etc.).

    Can a developer from MC comment on this? What was your plan? Did you test existing sites for compatibility with the new code?

    If refreshing the list was necessary after update, why wasn’t it at least mentioned in the changelog?!?

    Really a change like this should come with something that automatically updates the settings that will cause errors. If not it should automatically warn users with out-of-date settings that they need to reload their MC options. BARE MINIMUM would be a warning in the Changelog.

    So in the end only a couple of my bugs mentioned above are still relevant (specifically the one about $merge->$var['tag'] = $opt_val which I think is PHP7 related).

    Mostly I need you to think about backwards compatibility more!

    More: It’s specifically merge variables (in my case groups on one site and HTML/Text radio on another) that cause the problems. Sites without merge variables wouldn’t exhibit the problem.

    Please add “test plugin update on site with active group options in the form” to your QA list 🙂

    Also: After resaving my form, my “groups” option became unticked and wasn’t visible on the form. IMHO this shouldn’t happen when I use “Update list”. It should remember the “Show” checkbox for any merge variables shouldn’t it?

    Plugin Author mc_nate


    Hey Jeremy —

    First and foremost, thanks so much for the detailed bug report. We are already testing fixes that will automatically refresh the list’s fields and groupings on initialization (among a couple of other bugfixes). As far as the list refresh, that was an oversight by me. We’ll get these fixes out soon, though.

    PHP7 and WP_DEBUG hasn’t been a part of my normal testing routine thus far, but I can assure that moving forward it definitely will be. Our QA team is putting the finishing touches on everything and a new version should be available soon.

    Again, thanks for your detailed report and hopefully these fixes will be out shortly.

    – Nate

    Thank you. That’s what I needed to hear. Looking forward to a new version and appreciate having a response from one of the developers.

    Plugin Author mc_nate


    Hey again Jeremy —

    Just pushed out the newest version. Thanks again for your patience.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘mailchimp_widget.php littered with PHP undefined index notices’ is closed to new replies.