Wudman

Thanks for the validation. A fair follow up for the client would be to extend his Table Rate Shipping subscription until 2028, (5 years from the original expire which would have been tomorrow). His costs associated with only the hours dedicated to engaging WooCommerce. That wouldn’t cover work lost or time spent at WooCommerce’s direction, looking for issues such as plugin conflicts…

If just one of the “Happiness Engineers”, didn’t not focused on punting the issue to that “plugin conflict”, it would have saved about ten hours. Instead, the gross failure in transparency and honest tech support ends up costing the client hours it should not have.

My first email, was one of two that was never responded to beyond an receipt. In that email, I requested a copy of the previous version of the plugin, 3.1.4. I also alerted WooCommerce to an issue with the 3.1.5 update.

Yet twenty-three hours later I am in a six-hour circular argument later with “Happiness Engineers” who kept on focusing on the plugin conflict.

There are three chats involved with this issue. Conveniently the six hour chat was heavily truncated. If someone at WooCommerce needs to read it, I will gladly send my full copy in support of a fair response to the client involved. What was forwarded after that long chat, left off the first six hours!

I can’t imagine WooCommerce trains tech support to stall customers for six hours in chat?

A Happiness Engineer suggested in chat and email, even if we rolled the site back, the issue might not be resolved. My comments that highlighted the process I used to assure as clean an install as possible, was used as a reference to suggest rolling back would not fix the issue, but 3.1.4 fixed it for everyone else.

Again, confirmation the issue was known. Without any solutions coming from WooCommerce, I ended up rolling back to 3.1.3, which resolved the issue. That is where the site will be until this evening’s day of business ends across all time zones.

Again, to begin to make this right for the client/owner, WooCommerce should extend the license for TRS running on the site in question, for a full five years (2028). That will at least cover the costs incurred by the client for the tech support runaround. I will eat the hours restoring the new attributes and variations once 3.1.6 updates and operates as expected.

Follow up. After five hours of chat, WooCommerce Tech Support laid the issue on a plugin conflict. While in chat, with WooCommerce tech support watching and enabled with Admin privileges, I performed actions that suggested it was a Table Rate Shipping issue. Yet I was dismissed.

The chat agent left the chat open which was more to keep it from posting the transcript. In the meantime, I disabled every plugin except for Table Rate Shipping and WooCommerce (both by Automatic/WooCommerce), flushed all the caches, and the problem was still present. Then I uploaded the older version of the plugin that was sent to me and that made the problem worse.

Then and only then did WooCommerce admitted that their plugin, Table Rate Shipping, which pushed an update on 10/3/2023 was broken.

Furthermore, they have no ETA on when it will be resolved. Apparently even rolling back the site will not resolve this. We don’t see any option but to try rolling back this weekend.

Think about the real costs of rebuilding a mature ecommerce site with just 25 skus. Think about years worth of SEO including specific efforts in product SEO. The site in question has over 200 skus with thousands of ours and tens of thousands of dollars vested in development, marketing, content and product SEO.

Yet six hours of chat support gets you nowhere except an apology for our “frustration”.

Run from WordPress and WooCommerce. Something is going on in the house that Matt M. built and it is not transparency. The only other time I never need WooCommerce Premium Support ended with the same, “It must be a plugin conflict”. Then a few days later, a WooCommerce update and the problem went away.

PS, WooCommerce never answered the original or follow up tech support email either.

We have spent thousands of dollars on extensions for the “free” WooCommerce plugin. I can’t see any serious business relying on Automattic at this point.

Heads up if you make the mistake of buying into WPEngine hosting and appreciate using a fully featured version of WordFence. This should be of particular interest if you are here because you would be a rare WordPress site manager. That is a WordPress user that cares about your visitor’s experience and your site’s security.

Over the last week I have been going back and forth with WPEngine regarding a server lockout of the ability to select “All Traffic”. WordFence says WPEngine is the issue, WPEngine says WordFence locks this down. Last September when there was a different issue, it was the same thing, each entity point at each other.

Below is the second of two “advanced” support emails from WPEngine. In the first email, WPEngine responded by suggesting their useless “Access Logs” made WordFence “redundant”. Yet those Access logs take advance scripting to parse and that would take specialized code writing and time whereas tracking down a failed login with WordFence may take only minutes. The second email is a real winner. From the same level of tech support, an entirely new excuse…
—————————————–
“John Wheeler (WP Engine Support) Jul 19, 2023, 8:25?PM CDT
Howdy John,?
Thank you for your continued patience here.? I’ve reviewed both the chat as well as the ticket up to this point and I understand that you wish to be able to use the Live Traffic monitoring Feature that WordFence has available in the wp-admin dashboard.?

To clarify, WP Engine has no configurations on our end that force the WordFence traffic logs to utilize Security-only events – WordFence itself detects when it is running on WP Engine and disables Live traffic logging, and the plugin code would need to be modified to alter this behavior.? In reviewing internal communications from when WordFence worked with our product team to have the plugin removed from our disallowed list, it appears that this was put in place due to how WordFence handles logging when running on WP Engine.? Specifically, we do not allow anonymous requests to write to files within the wp-content directory, and so WordFence when running on WP Engine stores logs in the database as opposed to using files.?

With WordFence’s logged traffic going to the database on our platform, it seems they decided to toggle the live monitoring off by default when running on WP Engine to prevent database bloat that could negatively impact overall site performance.? In addition to the previously mentioned methods in which we make the access logs available, they can also be viewed/downloaded from the wp-admin area of the site. Once logged in to the backend, navitate to the WP Engine tools and once here you can scroll down to the Access and Error Logs section.?

There are three log files here available for consumption; Previous Access Logs: This will be the access logs for the previous day Current Access Logs: This will be the access logs for the current day Current Error Logs: These will be the php error logs for the current day Unfortunately, as getting this behavior back would require the plugin code to be altered, I’m afraid that this is something that we would be unable to handle, and such changes to the plugin could would ultimately overwritten when the plugin updates.?

If WordFence is able to confirm how they are determining a site is on WP Engine, we might be able to offer some solutions to circumvent that, but at present this information does not appear to be documented anywhere publicly.? Apologies for not being able to offer an equitable solution from our side – should you have any further questions or concerns, please do not hesitate to let us know and we’ll be pleased to further assist.?

Johnathon Wheeler | TECHNICAL SUPPORT SPECIALIST

• This reply was modified 1 year, 4 months ago by Wudman.
• This reply was modified 1 year, 4 months ago by Wudman.

I just ended a conversation with GoDaddy’s “Advanced Tech Support”. It has been like talking to a wall. The last thing the moron said after he asked me to try logging in using an incognito browser was, “the site is working fine, all looks good on our end”. This is after I sent him three images from three different private/incognito browsers showing the Denied because of too many attempts. screen.

I also sent the ATS support images of the 2FA authorization screen that only appears when I enter the proper password. To add some special lack of awareness, this allegedly advance tech support agent told me to disable the plugin. Apparently he is not familiar with his own product. Otherwise he’d know that Limit Login Attempts Reloaded does not show up in the Plug-ins list.

So my fix is going to be pretty simple. We are firing GoDaddy and moving the client’s site. It is the last active client site on GoDaddy. Perfect timing too since the client’s subscription expires in January 2023.

The GoDaddy install of Limit Login Attempts Reloaded is still improperly configured. It isn’t a plugin conflict either. Getting someone that can correct this has been impossible. So for the tens of thousands using certain GoDaddy accounts, this plugin is not working very well unless you are a legitimate user who wants to login to your site. In those situations, this plugin is awesome. No one gets to log in, not even site owners an admin.

FYI,
GoDaddy is giving your plugin a bad name. GoDaddy has baked your plug into their Managed WordPress Hosting. There are but a few configuration options and apparently none of the tech support people know how to fix this. There is also no way to disable the plugin that GoDaddy will admit too. Then there are the annoying update messages. As it is, I don’t want the free version, so upgrading isn’t going to happen.

It is notable that GoDaddy recently updated their CDN.

One correct login and I also get the “Denied for Too Many Attempts”. This appeared to start after either Limit Login Attempts Reloaded and/or GoDaddy changed up configurations in November. Before early November, the plugin was basically invisible. While it was present in the dashboard, there was no way to delete it and it never annoyed with marketing messages. About a week ago I had to do some routine updates and content changes for the client and I was immediately locked out. There was also a new Captcha presented. After enteringd proper credentials and the new captcha, the WordFene 2FA request presented, once that was entered, I was locked out with the “Denied for two many attempts, please try again later”.

I run WordFence Premium on client sites. That plugin manages any login attempts and allows me to set 2FA up. WordFence has been working fine for several years, but all of a sudden “Limit Login Attempts Reloaded” has taken over. Even after seven hours of tech support from GoDaddy, the combination of this POS plugin and GoDaddy’s POS Business Managed WordPress hosting, are locking me out.

While I can log in via my client “Hub” (and others can login in via their GoDaddy account), doing so adds five steps.)

As if it can get worse, GoDaddy has installed a free version of this that annoys you with “Buy our Cloud version”. Also, even with the settings relaxed to kick in at 25 bad logins, this plugin still shuts you down (even if you enter proper credentials.)

For an addition fail, the plugin is ignoring settings that are suppose to whitelist a user name.

There also does not appear to be any way to clear history. Speaking of history, on this client’s site the last recorded lockout was on April 2021. According to GoDaddy support, you only get updated logs if you pay for the premium version.

Bad plugin and a really bad execution by GoDaddy.
Suggested move? Fire GoDaddy, then maybe this plugin is worthwhile as a one-trick pony.

• This reply was modified 1 year, 11 months ago by Wudman. Reason: add detail

Glad you have a handle on this. Both our hosting (WPEngine) and WordFence extended efforts to quash this. WooCommerce not so much. I documented the “adventure” in a series of posts on LinkedIn because I knew that what I was seeing could not be the only incident despite WooCommerce saying they had not seen a similar exploit.

The invoices in question were filled out to look real, but a quick search revealed the fake address in Texas. The next attempt had an invoice featuring a fake address in New York. The IP trace showed a similar series of IPs, enough to suggest the same actor.

In my opinion, the biggest issue is that the payment gateways basically open for business after thousands of fraudulent attempts to run what I assume were stolen credit cards. At the minimum, the payment gateways earned fees on fraudulent transactions they should have prevented. One account getting hammered thousands of times in under an hour, for the same transaction, using stolen credit cards, and the gateway leaves the door wide open for more attempts.

Hey 2bearstudio –
Sounds like a carding attack is or was in progress. Be sure to check your failed messages related to any suspect invoices. Watch for similar invoices and if you don’t have a security plugin such as WordFence, get at least the free one installed so as to be able to trace and block what IPs you can identify. To be clear, WordFence did not stop the exploit, but it did give me tools to trace the scumbag and block all associated IPS after the fact. That ability did come in handy later.

The same thing happened to a client site back in September 2021. At that time, the bad actor was able to spoof an invoice so that it recorded an item qty, but didn’t add the price up right. These seemed to be a probe of a WooCommerce defect, but WooCommerce/Automattic didn’t think so.

12 credit card transactions ran successfully out of 5200 attempts. Fortunately for my client, this seemed to be a test of an exploit as the scumbag used a low-priced item. We ended up eating a few chargebacks that tricked, but didn’t loose any product or take a reputation hit.

There was still one dirty deed to be done and that was that Braintree shut down the account AFTER running the stolen credit cards 5200 times and held back the client’s funds for about a week.

Since this site has a pretty robust level of security, I was able to flag the behavior and about a month later, the same IPs started generating a similar attack, but from a different address in a different region. Since I had traced the IP of the original carding attack, I was able to match the new one up to the same scumbag. We did change our gateway, (fired Braintree) and there was a WooCommerce update. One or both stuffed the scumbags ability to pull of the same BS.

Sounds like there is still an exploit. If you are using WordFence, send them an alert. They were more helpful than WooCommerce in every way.

Try to click the damn thing, it should take you to a page and which time you should be able to return and see the nag gone. At least that is what worked for me. If you don’t get linked through, check to see if you get a popup warning.

What worked for me is clicking through once. Then that annoyance went away. I venture WooCommerce was quite aware of the fact they pushed an ad on everyone’s page without a “CLOSE” option.

Thanks for that idea as well. That was one of the rabbit holes I was diving in, but a different plugin. The client is cool with the variable product mod and then a plugin to customize the registration process.

Awesome feedback. Sorry for the delay. I have looked at your membership plugin Igor and the main concern my client had was keeping all the products visible regardless if someone is logged in. Many competitive websites offer registration areas that get the certification questions answered.

As linux4m2 stated, we do have to rely on honesty, but in our case, what really matters is that we have a process that demands an answer which covers our buttocks. The products are educational in nature so there are no threats to mankind if an unqualified user applies the tech. They will just be less capable at interpreting the reports.

I like the variable option as mentioned by linux4me2, but we will still probably add a plugin that allows us to add the qualifying questions to new and existing registrations.

So thanks for these excellent answers. I actually have the page for “WooCommerce Memberships Restrict Content” open and was reading this prior to logging back in. I didn’t see any notices of responses.

I have used this plugin on almost every website without an issue. I just had to pull it because it was causing a redirect back to the login page with the “You need cookies enabled” error.

WP 5.9, fresh install, only two other plugins, YoastSEO and WordFence. Deactivated WordFence and the issue persisted.

While renaming the login URL isn’t a cornerstone of my security strategy, I do appreciate that it does slow down the noob hacker wannabes. In this case, it looks like I was having the same issue as many others.

Yes, the hosting does have a cache, but it is not configurable.

On the positive side, once I deleted the plugin and cleared my cache, I was able to login normally. The downside is that I had to login via my hosting account to clear the cache. So this is a pretty silly issue that will probably irritate zillions of your plugin’s existing and new fans.

Thanks you, Actually, we intended to re-subscribe, since our two subscriptions lapsed 30 Nov 2021 and 2 Dec 2021. That is stated in previous posts. Thanks for letting me know that to get a properly functioning Yoast SEO, one must subscribe to a premium product.

We will just use a different browser or disable Yoast SEO when we need to edit a product page. Yoast used to take care of the basic plugin.

• This reply was modified 2 years, 11 months ago by Wudman.