joshuaiz

Hi Jack,

In our case it is for new post notifications.

Let me know if you need additional info.

J

Same thing – getting massive amounts of duplicate emails being sent out. I got reports of 20-24 emails per post.

Thus if more than one person is seeing this behavior this points to BNFW as the culprit.

Just FYI, I had the following email chain:

BNFW
WP-Mail-SMTP
wpMandrill

As I have a membership site that pays for market analysis emails we need to get this resolved asap.

Thanks!!

Solved:

There’s an error in the filter code on the ‘Other Notes’ page:

Instead of:

function modify_categories_dropdown( $placeholder, $taxonomy ) {

    return 'New placeholder';
}
add_filter( 'beautiful_filters_dropdown_placeholder', 'modify_dropdown_placeholder', 10, 2 );

The function needs to be named modify_dropdown_placeholder to match the filter. Took me a few days to catch it ??

Yep that fixes it – thanks for that.

Some additional info:

I am using wpMandrill and checking the Mandrill logs, no emails went out at all after the 1.37 upgrade.

Not working on my site either since the WP 4.4 upgrade. Going to try to roll back to previous BNFW version.

That solved this for me. Thanks for the fix.

Another question: how does WordPress handle the user_name field if there isn’t one with this kind of import?

Follow up question for this. I have a ‘Password’ field in my MailChimp list to send out to my subscribers to log in for the first time. How can I modify the code from #2 to use this field for the user_pass in WordPress?

For a little more info, this Password field is a duplicate of the EUID field as it is a unique identifier that I can include via merge tag to each user.

I’m asking this question here before trying anything as I only want to import my MailChimp subscribers as users once ??

Thanks Mike – I have been using those tools to isolate the error(s).

I have that set for the CardConnect client – they cannot change gateways but we are working closely with the gateway plugin developer.

For the PayPal Standard I could not repeat the error – it was intermittent (my favorite :). But there was nothing in the debug.log or in the dev tools console/XHR response at least on my end.

@mike Jolley CardConnect – they are already working on a fix but another client is using PayPal Standard and still getting the syntax error.

The DEBUG_DISPLAY setting is not working in either of those cases.

@mike Jolley For now if you’re having trouble getting 2.4 compatibility updates from developers, perhaps its time to switch gateway plugin to one thats more actively supported.

I wish I could…that’s just not an option with some clients.

****edited after reading previous response by Mike Jolley****

@mike Jolley Not sure what you are referring to by “hack” or “3rd party code”.

Yes I agree it should have been tested by the gateway developers before the update. But this is not dealing with the reality we are facing now.

The fact that this happened with 6 of my clients on 4 different gateways points to something you should have anticipated. I don’t believe that in proper real-world testing that this issue never came up if it is happening to hundreds (if not thousands) of people now.

WooCommerce cannot work without gateways and to get this syntax error with gateways that you support out of the box cannot entirely be blamed on 3rd party code.

While I fully understand that you cannot test for every situation or setup, the sheer quantity of the threads inquiring about this issue should motivate you guys to do *something* rather than throw your hands up, say “we warned you” and blame everyone else. That is not helping anyone.

Furthermore, as a WP developer, I am having to tell my clients to wait for a fix while they cannot sell their products. It makes me and other developers look bad while we can only sit back and hope a fix comes soon.

@mike Jolley The only change here is enforcing valid JSON rather than allowing any response. Any output from a plugin, be that a notice, warning, or echoing of HTML, will break this valid JSON response.

In the call for beta testers, and prompts for developers to test code, no reports came in about the above, no one asked that it change, no Woo gateways broke.

I have had reports of this error on multiple sites and 4 different gateways (PayPal, CardConnect, Authorize.net, Stripe) and those are only *my* clients, not to mention all of the threads about this. There are lots and lots.

Disabling error displays on the screen is not exactly a “fix” either. What’s more, this “solution” has not fixed the issue on 4 out of 6 sites. This forced me to contact the gateway developers to update their code. That takes time and in the interim, my client(s) cannot sell their products. And try that with PayPal (Spoiler alert: you can’t).

To me, if some of the largest gateways return HTML or something else, then WC should anticipate this and not just break and say “No beta testers mentioned this.” That’s a complete cop-out. A simple conditional could solve this and still support the gateways that have not upgraded yet.

Part of having a successful platform, be it WordPress or WooCommerce is backwards compatibility. You can’t just eliminate support for legacy code (however bad it may be) and then blame your users and developers. This is horrible practice and bad business. You have to take some of the blame for this and you should fix it, not expect everyone else to (even if they *should*).

What’s more it makes me think twice about recommending WooCommerce for e-commerce with WordPress.

Thanks for the update. As in my case changing permalinks did not work so hopefully the upcoming release will solve it.