MV

@tijosh : Good suggestion to look for plugin or these conflicts. Unfortunately, inconclusive. In fact, I have not added or removed any of them from before when WooCommerce Services was working fine.

Can I send you the System Report privately? Does it not contain information that could compromise server security?

The versions are both the latest ones. I tried enabling the jQuery Migrate Helper and that made no difference.

The issue is only with WooCommerce Services under Shipping. The automatic tax calculation is working fine.

What I did was to manually delete those images and re-upload the same image. That triggered a new optimization to run and those error messages got cleared up. I think this issue is resolved for now and I will close the topic as resolved.

I did not apply one of those classes manually but those classes may have been applied by Elementor when I styled the page. How do I find out if that is the case?

I tracked it down to a setting in /opt/bitnami/apps/wordpress/conf/httod-app.conf, which says AllowOverride None. I may have to change it to AllowOverride All in order allow the .htaccess to override the settings in httpd-app.conf. I found the tip from a Bitnami Developer’s suggestion.

But when I tried changing it, I get a server error, which makes me think that that is not the way to solve the issue.

EDIT: The server error was due to some customization that I had added and none of the plugins. I have now set AllowOverride All and the IP blocking is working fine. This is because the default for Apache > 2.3 is None.

There is a potential security risk on setting it to All. But as it has been argued, if someone with malicious intent has access to my root folder then I have many bigger problems on hand.

• This reply was modified 4 years, 6 months ago by MV.
• This reply was modified 4 years, 6 months ago by MV.

Below is the code that I had to insert inside the <Directory> tag:

    <IfVersion < 2.3 >
        Order allow,deny
        Allow from all
        Deny from 47.52.98.110
    </IfVersion>
    <IfVersion >= 2.3>
    <RequireAll>
        Require all granted
        Require not ip 47.52.98.110
    </RequireAll>
    </IfVersion>

I had to follow the instructions here and it worked:
https://docs.bitnami.com/bch/apps/wordpress/troubleshooting/deny-connections-bots-apache/

It seems that your plugin has some issue with Bitnami stacks for WordPress on Amazon Lightsail. That makes me think that most of the edits to .htaccess from your plugin may not be working.

I checked that already. No IP addresses on the whitelist.

I tried as you suggested, but it had no effect. I could not block myself. The .htaccess file had the entry banning my IP, but some other setting is probably overriding it. I even tried restarting my Apache server, but it did not help.

@sean-h : Good point about caching. So many of my headaches in the past were tied to caching issues. I use AWS CloudFront for CDN and that caching can sometimes be aggressive. It is not clear what URL or Cookie needs whitelisting to fix the issue with Site Health.

Having said that, I had the CloudFront CDN enabled until 2 days ago and had no problems. In fact, I checked Site Health right before I updated WooCommerce and it was fine. It broke immediately after updating WooCommerce.

The exact same problem started for me after the latest WooCommerce update. I don’t have any of the plugins that @mikee68 or @sean-h mentioned. Probably something broke with the latest WooCommerce update?

Sorry for the lack of details. The problem resolved itself and I will document here the precise things that I did, although it is mysterious to me why it resolved itself.

Note that every attempt that I describe below was in its own protected window in two different browsers (Chrome’s incognito, Safari’s private window) so that there is no sharing of the cache. I also tried swapping out the browsers with no difference.

First, when it is broken, which happens when the same user visits https://www.thekokuin.com/wp-admin. I am presented first with the option to login with WordPress.com or by providing a username and password. I choose the latter. I am then presented with a screen asking for my “One Time Password (i.e. 2FA)”. When I enter the code generated by Google Authenticator on my phone, I receive a message that says, “Error: The one-time password (TFA code) you entered was incorrect.”

Second, the behavior when things are fine and I can login by visiting https://thekokuin.com/wp-admin. At the login page, I choose to go with username and password instead of WordPress.com. Then, I am asked for the TFA code that I find from my phone’s Google Authenticator and enter. This takes me to the admin screen, as it should.

If I go to a new screen and try to access www. I get the same message that the TFA was incorrect. So, the order in which I try the two did not matter.

Now for what I did next, which appears to have resolved the issue.

To ensure that I am not inducing errors in typing the TFA code, I opened two incognito windows side-by-side (in two different browsers) and tried the two URLs together. So, I used the same TFA code in both of them by being fast enough. Now both of them worked fine and let me in. After this, when I tried each method individually in different browsers (www. or naked domain), both worked fine. The problem appears to have resolved itself!

I have been struggling with the same problem, which persisted even after I followed the steps to set up Webhook accurately. The problem turns out to be that Amazon CloudFront and Stripe don’t play well together. When setting up the CloudFront CDN, you had to provide a direct (non-CDN) access to your page as well. For example, I run https://www.thekokuin.com that is served through CloudFront but https://thekokuin.com (without the www) points to the direct server. You should provide the direct server address in order for webhooks to work properly. Otherwise, CloudFront does not know how to respond. It may be possible to configure CloudFront to deal with the webhook, but I did not bother.

• This reply was modified 4 years, 11 months ago by MV.