FADmark

Just piling on here that I’ve also had 2 orders in the last 2 days with the latest 8.7.0 update that have a valid credit card charge (using Woo Payments), but where the order is missing all customer billing/shipping info in the order details, including an email address. The payment info includes an email address, which allows the order to be reconstructed, but it’s time-consuming (and annoying for the customer). Any help here would be appreciated.

-Mark

I can confirm that the patched v2.4.1 plugin worked for me also on a fairly active production site, with WP 6.4.1 and WC 8.3.0.

• This reply was modified 1 year, 3 months ago by FADmark. Reason: added more context

Additional… [br] and </br> do not work, as if the new template is ignoring any html.

Confirmed that unchecking “Use HTML content type” does produce cleaner mail with line breaks and new lines.

I was talking about the anti-spam plugin, which was blocking order data to the Woo smartphone app. I discovered that turning off the SpamFirewall option allowed it to communicate again, but of course I lose all of that functionality of the plugin, which is rather disappointing. Maybe you can test the plugin further because unless it was just a coincidence, it doesn’t seem to have all of the Woo IPs whitelisted.

Same problem here for about the past 24 hours. I’ve probably lost $2k in sales today because of this and have both Woo and ShipStation working on it, but it appears to be the same USPS auth problem with the Woo Shipping & Tax plugin. I can’t find anywhere to update or enter an API key, so it must be something handled by the plugin directly? Yet hours later, Woo can’t seem to fix this.

I updated my WP Rocket after I saw the release notes this morning also, and then did the CF7 5.4 update, and all is good (and fast) now. ??

Argh! I wish I had checked here first. Same problem with unending submission spin. Trying to roll back now as I have a huge product launch going on now and I’m getting flooded with inquiries. I should have listened to the voice in my head that said update tonight after hours, but no, I had to do it now. ??

Thanks Raj! I’m glad my post saved you some time.

Follow up: I’ve been using Mandrill for a while now (no dedicated IP, but on a paid account), and it’s working pretty good. I’ve had nice, consistent deliverability now for all my transactional cart email, with very few issues. But, when there are issues, it’s easy to see what the problem was, and even worst case, copy the failed email and shoot it to the customer manually. My traffic at https://BetterSafeRadio.com is really picking up now due to the pandemic, so I’m happy I got this solution in place just in time. ??

• This reply was modified 4 years, 7 months ago by FADmark.

Yeah, honestly, I’ve been running my own sites since, well, before the WWW, and it really hadn’t been a problem, at least in my direct experience, until recently (as in the last few years). But I have definitely been having deliverability issues from shared hosting servers and my reseller server, hence the need to have someone else handle the nuances of email deliverability now for some of my higher-traffic sites. Wish me luck! ?? And good luck to you as well. ??

Of note, I actually seemed out the Mandrill solution after having tried SendGrid for a while. Without a dedicated IP, I found SendGrid to be abysmal at deliverability, generating more bounces than using my shared hosting SMTP, which kind of defeats the purpose of the service. When I questioned them about it, they informed me in no uncertain terms, that SendGrid was NOT intended to be used for transactional email. What the…??? Apparently, they only recommend their service, or at least this was their current excuse for it’s failings, for marketing email, and at that, only with a dedicated IP do they claim any kind of reliable deliverability. That was a hard-pass for me. At leas Mandrill is specifically for transactional email, and so I’ll probably reluctantly give it a try since it can be paid for on a monthly basis, and even if their “free trial” is a completely misleading waste of time and isn’t actually a trial of anything. ??

Hi tcosentino, As it turns out, this error was due to a limitation of the “free trial” of Mandrill, which I’ve now learned, after wasting an entire day trying to troubleshoot it with multiple plugins, only allows email going to the host domain. Argh! Nowhere could I find in the documentation, FAQ, support area, or elsewhere that this was a limitation of the “trial” for Mandrill. It seems like if they really wanted people to try it, especially when there’s a send count limit, they would at least let you try the entire functionality to make sure it works before you commit to their service. I’m not sure if I’ll bother to actually subscribe now, but it would be convenient since I already use MailChimp. When I recommended to the tech that they publish this limitation so they aren’t wasting their potential customers’ time, they were totally indifferent. That’s pretty lame in my book. Anyway, I hope that’s the same issue you’re having and I hope perhaps this thread will save some others a bunch of wasted time in the future if they happen to find it first. ?? Cheers!

Further, these errors are using the API, and my host does not allow Port 587, even as a fallback, and that can’t be changed in Mandrill (that I know of), so I’m forced to use the API. Oddly, when I send mail via my Contact 7 form, the mail send works! But any mail using the plugin test forms and notifications on Woo orders will all fail.

I just updated to Woo 3.3 and I’m missing the Order Action icons also.

Same problem here. I think it may be related to running iThemes Security (Better WP Security), which I just learned is not compatible, even though I’ve been running it for a year with A2. ?? I ended up reinstalling my W3 Total Cache, but it took about 8 tries because there was some problem with the A2 plugin.

• This reply was modified 7 years, 5 months ago by FADmark. Reason: typo

I too encountered this problem with the Egecia 1.2 template for WordPress. After searching all over for an answer, I decided to dig into the code a bit to see if I could find the problem.

It seems as if there’s a closing DIV on the comments.php that should be conditional. When there are no comments, this closing DIV becomes an extra tag, which breaks the layout.

This may not be the very best way to fix the template, but it seems to be working fine on at least 2 of my clients’ blogs that I just applied the fix to.

Here’s what you do:

Open up the comments.php template in the WordPress Theme Editor and scroll to the very bottom of the code. You will see a closing </div> tag on the third line from the bottom. Simply replace the tag with the following:

<?php if ($comments) : ?>
</div>
<?php endif; ?>

(or just wrap the PHP around the existing tag – same diff.)

This will now add the same condition to the closing tag as the opening tag (when comments are on), and hence won’t add an extra closing tag.

I hope this helps someone else out as it took me an hour or so to figure it out. Feel free to comment or email me so you can get my PayPal address and send me a “thank you” donation – hehe.

Hit me up on my Web Audio Marketing, Royalty-Free Music Licensing or Custom Web Design & Hosting sites if you need any help.

Cheers,

-Mark