VAR

Nice, what a speedy fix.

Yep, tested and works fine now!

Thanks for checking! I will test it again.

Thanks for your response. Yes, I already checked that and rebooted redis last time. Seems to have come back but I rebooted redis, and additionally OLS, earlier today and waiting if the error still persists.

Okay great! I will raise the questions there! Thanks.

I have the Pro.

Okay so it seems like I need to exhaust and test everything, which functionalities broke or not when I enable htaccess root/wp-admin/plugin. So that means adding exceptions to plugin htaccess and skip rules in root htaccess?

Also regarding the 403, I actually tested it several times, and nothing was logged in the Security log except for login attempts by bots. I believe there was even a quick summary of the logged errors so there was no 403 there. I wouldn’t have known about it if Facebook did not email about the product XML feed not being accessible.

Also, does using BPS completely lock the root htaccess? I mean, if I change some settings in Litespeed (that translates to addition or removal of some htaccess rules), does that get reflected in the root htaccess as well?

Thanks!

I’m still waiting for an update from them and currently just using an older version. I refused to use their latest update as the last working version for me without the CSS issues is version 3.0.9.

Hoping that this gets sorted out as the issue seems to be really appearing not only for me.

The issue above occurred for version 4.1.0 and Yes I always clear the cache and purge CDN (in fact, several times) especially when issues tend to occur. Added/removed items from the cart as well as per the screenshot shared above. I reverted to 3.0.9 because that was the last working version for me without the CSS issues. I have seen that an update was posted (v4.1.1) today but no mention of CSS fixes so I guess I will wait for a while.
Thank you!

Thanks, that worked perfectly!

Thank you so much, that worked perfectly!

I have just installed it in the live site plugins folder just so it can locate the JS file it needs. Seems to be working now. Thanks!

It seems to load that JS file in the live WordPress installation where the plugin is not installed yet. I have only installed this plugin in a staging site installed within the main WordPress installation folder.

Thanks for your response.

Yes, there is a 404 error. It says failed to load resource /woocommerce-product-price-based-on-countries/assets/js/ajax-geolocation.min.js?ver=2.0.15

Please advise a workaround. Thanks!

Hi Eli,

Thanks for your response.

If my scan time and progress look normal and as intended because of the number of files, then I’m fine with that. There are no cache files or compressed files included in the scan, I have just a large Woocommerce site with several plugins which could be the reason maybe (?). I think most of the time is spent on the plugins folder and I have seen gotmls can take several minutes scanning a certain file as I was observing it from last time, is this normal?

Yes, the plugin was not really using so much of the resources, and often times just utilize 1 CPU core (I’m on a 6-core VPS). That’s why I’m not sure why it slows down my site as I was visiting it in a different browser with a VPN while the scan is in progress.

I’m sorry for the confusion but I did not mean it created downtimes, I mean I am using site24x7 for Real User Monitoring and I set a warning when my site loads in over 15 seconds which it does when I do the scan. Could be okay if it’s just a brief scan time but would be hurtful, especially it’s an ecom site, for a scan time of 5-6 hours.

They did not ‘reject’ the meta description as it’s correct and as intended, I just want the results count to be completely eliminated as that doesn’t have something to do with their “interpretation” of the site and in fact dynamic. If it’s possible with the majority of the Woocommerce sites (or other shop platforms such as Shopify), then I probably just have to tweak something and probably need some guidance from Rank Math.

And as for my other concern regarding showing the updated date instead of the original published date, I know it’s possible because that’s what the majority of the blogs are trying to show in SERPs.

Thanks for your response John and thanks for the tip on not needing the escape character.

Just for your reference, this was how the column with long regex URLs looked before the v4.9:
https://i.imgur.com/c9Nsv5I.png

Cheers!