Peter

Actually, it was Microsoft that gave me the exact url. When I clicked to “Report that the site does not contain threats”, that was the url Microsoft showed as causing the issue.

It was that simple!

If you’re trying this on the website I indicated above, you’re not going to get the message any more.

After my request, Microsoft removed the warning within 1 day. We’re running a business and couldn’t have that message showing up to our customers!

My point was that it was triggered by the gif in your plugin for some reason, and you may want to check if any of your other clients were getting this issue showing up.

In IE11, the address bar reported “Unsafe Website”. Clicking on that dropped down a screen that had a More information dropdown.
https://az648995.vo.msecnd.net/win/2015/12/smartscreen-2.png

Clicking on that gave me an option to:
“Report that this site does not contain threats”

Clicking on that gave me another page where I could click on:
“I am the owner or representative of this…”
https://www.sevenforums.com/attachments/tutorials/142261d1299491317-internet-explorer-smartscreen-filter-report-unsafe-website-report_safe.jpg

The following screen let me fill out all the information.

However, the first few times I clicked on the warning, it didn’t give me the option for “I am the owner or representative of this website…” option. I had to click a few times on “Report that…”

Not sure how to get those backticks in there.

wp_options and option_name are supposed to be enclosed in backticks for the proper SQL command

Yes, it doesn’t look like that update ever fixed anything. Our tables still fill up with those garbage values.

Every week we have to go in and clear them out.

In case somebody needs it, here’s the SQL command to clear them out:

DELETE FROM wp_options WHERE option_name LIKE (‘_yith_ywraq_session_%’)

NOTE: You’ll need to change wp_options to whatever that TABLE name is if you’re using a different prefix

Not a www.remarpro.com plugin, but isn’t this what you’re looking for:

https://codecanyon.net/item/vbulletin-connector/4126499

or this variation:

https://codecanyon.net/item/vbulletin-latest-threads-wordpress-plugin-/10176117

Excellent. Thank you. Looking forward to it.

I just checked one of our other sites and it had the same problem the _options table was filled with over 300,000 lines of _yith_ywraq_session values. The database was HUGE.

Is this problem going to get fixed?

I ran an SQL query to clear the values out, but they keep coming back. Your code should really clean up after itself! A simple wp-cron job would do the trick.

If this doesn’t get fixed this plugin is getting uninstalled and we will definitely NOT be purchasing the premium version!

Yes, it does. Here are the files that show up on the Drop-ins tab:

advanced-cache.php Advanced caching plugin.
db.php Custom database class.
install.php Custom install script.
object-cache.php External object cache.

I’ve triple checked this on the site and everything is in place on the live site from what I can tell. We have no dev/staging set up at the moment. It’s a mystery…

OK, well, I thought I’d post my results here after a completely crazy journey this past week.

After our discussions here, and after some further testing, it turned out that the problem wasn’t related to any type of caching issues, because it continued to exhibit the same problems (even though it looked at first like this was causing the problems).

Being at the end of my rope, I decided to hire an Elancer to have a look and see if they could find the problem. Well, after a few days of trying different things I think we have found what the original problem was.

At first it looked like there was an issue with the products missing a custom field “total_sales” meta data, that Woocommerce seems to use/create if you click on “Update” for a product (without changing anything else about the product). So I created that field for all the products and filled it with the default value of “0”. However, on further extensive testing, it turned out that didn’t have anything to do with it.

Next, it looked like there was a problem with the “Tax class” field which appeared to be set to Standard for all the products. However, it somehow wasn’t “assigned” to the product. I used the “Woocommerce CSV Import” plugin by Mensonides (using the purchased Add-ons) to import all of our products from a CSV and I had set one of the field headers “tax_class” and filled all of the products with the value “standard”. This appears to have been my mistake. I should have left the field empty, because the document mentions that you can use the field IF you have any additional tax classes (but doesn’t mention to keep it blank if you don’t). Somehow if you fill this field on the import it completely messes up the tax calculation and the tax won’t get calculated on the product (tax on shippoing still works, though because that’s a separate calculation.

I could fix the problem by going into each product individually and clicking on “Update” and that would get the tax calculating properly on the product by somehow setting the proper association. However, I fixed the whole database of products by using the “Woocommerce Advanced Bulk Edit” by George Iron and resetting the Tax Class field for all products. I’ve been doing some more extensive testing and this seems to have fixed the problem now.

This has been a very time-consuming and difficult task to pinpoint what the problem was and I sure hope this doesn’t happen to anyone else. Hopefully this can help someone if they run into the same problem!

Bottom line is if you’re using the “Woocommerce CSV Import” plugin by Mensonides, make sure to leave the “tax_class” header field out unless you’ve set up some additional tax classes.

OK, I think you may be right. I’m using W3 Total cache and I remember excluding those pages from the caching during setup. However, they have put a notice that as of WC 1.4.2+, that it sets the DONOTCACHEPAGE for those pages.

We did recently change hosts and they have another optimized caching plugin for their setup that was installed at the time. I didn’t think to check to exclude the cart, checkout and account pages at the time. I’ve excluded them now.

I’m going to do some more testing because right now the tax is showing properly in Chrome, but not Firefox… argggh.

Anyways, I’ll continue pursuing this avenue and see if that fixes it and let you know tomorrow.

So I tried the catchall line and it didn’t change anything at all. It still only calculates the tax on the Shipping. It completely ignores the tax calculation on the product.

Any other ideas?

I’ll try the catch all line tomorrow.

I had a quick look at the usermeta table and the fields shipping_postcode / shipping_state / shipping_country are all populated with the proper data. I didn’t see a “shipping_zip” field though. Is that what it’s supposed to be?

Thanks for your help so far… to be continued tomorrow.

I turned the geolocation off for now.

I don’t think that setting has anything to do when the customer is logged in with their account and an address is set up, though. We don’t have guest checkouts enabled, so the address that shows up in the cart should be the address that is used for the tax calculation. Somehow, the system does not seem to be identifying the zip code of the customer properly or something. The tax does get calculated properly on the shipping (we’re using the WooCommerce Table Rate Shipping plugin – I’ve disabled it and it still doesn’t calculate the tax on the Product).

I’ve tried disabling some other plugins that MAY have something to do with the checkout, but nothing has changed as far as the Product tax calculation goes – it just doesn’t do it.

The tax rate does vary by zip in WA – it’s a pretty large list with 698 entries!