bigredseo

It’s a very bad idea to go editing the core files. Edits like this should be done either in a custom override via a separate file or via functions.php

Editing the core file is not a solution.

Thanks for the reply.

Just to clarify, it’s not a “seeing the wrong email” as a problem. They’re all sending out under an info@ address. The potential theory of mail throttle by gmail.

The “Envelope From Email Address” was filled out. The only thing different on that screen is that you have “Authentication: Plain” and I have “Authentication: oAuth 2.0” which isn’t a problem.

The forcing of the Email Address and Name on the Message Tab I had filled out, but didn’t enforce the Prevention of the change. I have enabled that just for good measure.

Since these are sent directly via a function in a cron script, we’re not defining a FROM either directly or in the $headers. So it should be using the default from the Post SMTP Mailer. Here’s what we were calling;
wp_mail( $to, $subject, $body, $headers );

I didn’t notice any issues on the mail sending for the 16th (we have two BIG days for sending.. 1st & 16th based on the majority of subscriptions ending/renewing).

I extended our logging to 1,000 records so we’ll keep an eye on it and post here during the next big batch.

Thanks again for the reply.

Just a comment that we ran into the same issue and reverted without a problem.

While I could easily find the “50% !important” that was introduced, there are some other areas that were modified and it’s causing the problem there. Sadly, limited documentation. Will likely run a full plugin files comparison to find which edits were made and what others can do to resolve the issue.

For now, downgrade to 1.2.9 got things back on track!

Waiting on the developer to issue an update….

Thanks for the reply. I can’t post the actual logs here as they have email addresses, content and private links in the original_content sections, so is there a better way to get you these logs?

As far as the content being sent, it’s not exactly a bulk email, but they are notices about memberships or subscriptions about to expire. More than 5,000 members in the system and a few hundred get notified on the 1st, with 2-5 notices each other night as their membership dates come up for renewal.

The emails are sent via a cronjob which triggers once each day to see if a user has hit specific metrics (stored in User ACF Fields) and then matches expiration date of subscription. The system then changes their user role if needed.

It acts/looks like a timeout. The “Solution” solucmn says “No found, check status column for more info.”

The status column has the following (domain has been XXXX’d out, as has a portion of the XOAUTH2 string;

"smtp:tls:oauth2://smtp.gmail.com:587

220 smtp.gmail.com ESMTP z4-20020a92d184000000b002b7bdf53db1sm7157949ilz.39 - gsmtp
EHLO XXXXXXXXXXXXXXXXXXXXX.com
250-smtp.gmail.com at your service, [35.209.120.77]
250-SIZE 35882577
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
STARTTLS
220 2.0.0 Ready to start TLS
EHLO XXXXXXXXXXXXXXXXXXXXX.com
250-smtp.gmail.com at your service, [35.209.120.77]
250-SIZE 35882577
250-8BITMIME
250-AUTH LOGIN PLAIN XOAUTH2 PLAIN-CLIENTTOKEN OAUTHBEARER XOAUTH
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
AUTH XOAUTH2 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX5lWGt5dDRGWGtzb055cGIzOHZ1eXpZam5OM2ZPZDRqeGVCRlJnVkQ3bzFaa1ZHZXhOOWpVWElWeEgwREFaQTBDeGdnOAEB
334 eyJzdGF0dXMiOiI0MDAiLCJzY2hlbWVzIjoiQmVhcmVyIiwic2NvcGUiOiJodHRwczovL21haWwuZ29vZ2xlLmNvbS8ifQ==
"

Instead of getting a 235 Accepted status and then the mail headers, then the 354 to go ahead with data, it’s returning a 334 status (server challenge) and then dropping off.

Like I said, even though dozens of emails get sent successfully, we then hit this 25 batch, and then no mail between that time and an 90 minutes later. I don’t know if that was the end of the sending, or if other mail just didn’t bother sending since it saw 25 failed attempts.

Just wanted to comment that “you’re not alone” on this one.
I see the break on one of our client sites too.
Re-uploading the old version of the plugin resolves the issue for the moment.

Hi Stanimir,

It looks like the latest update to the 5.8.1 released in the last couple of hours has now resolved the purge issues.

Fought with this myself.

The problem on our end was that we chose on the “Manage My Business” option, we selected NO. It turns out, ALL of those need to be marked YES, or the connectivity fails.

Set them to YES, and you should be good to go.

(developers: why bother to have a yes/no option if you are required to pick YES)

Unfortunately no. Never found a solution.

Ended up with an alternate plugin that I picked up for $10 and moved on.

Wish I had a solution as I really liked this plugin overall.

Not sure I feel comfortable promoting a competitor plugin here on these forums, but feel free to send me a message and I’ll provide you the link on where I headed.

Yay – it looks like you’re back online in the system!

It should disappear, it does on my end when I test.

Can you verify under the WooComemrce > Settings that the AJAX is enabled? This tripped me up before. It needs to have AJAX enabled in order to do a realtime refresh without having to refresh the page.

See if that helps.

Just in case anyone else runs into the issue, my problem had to do with AJAX not being enabled.

WooCommerce > Settings > Products > “Enable AJAX add to cart buttons on archives”

Now the flyout works when you click Add.

For extra clarification, I’m using
WordPress: 5.3.2
WooCommerce: 3.9.2
Cart All In One For WooCommerce: 1.0.8.1

As a side note, I’m using the following that does work, but wanted to check if there was anything inherent that maybe I was missing.

Here’s code to join fields and search custom fields (not my code, just something I’ve used before): https://adambalee.com/search-wordpress-by-custom-fields-without-a-plugin/

It worked just fine on several client sites over the past 2 weeks – no issues.
I have not tested it with 4.9, but it works flawlessly on the 4.8 branch.