artsgirl

That did it! Thank you so much for your quick response and your excellent plugins!

Okay, here is one for example: from 1400 S Jefferson St in Chicago (60607), to 501 N Charles St in Belleville, IL (62220).

According to several sources (including TaxJar’s own calculator at https://www.taxjar.com/sales-tax-calculator) this should be 8.1%. This includes 6.25% for IL state, 0.75% for the city of Belleville, and 1.1% for the district.

What is showing in the plugin, and in the TaxJar API demo you linked, is that that same Chicago/Cook country jurisdiction is being applied incorrectly, for a total 10.25% rate.

Belleville is on the complete opposite diagonal end of Illinois from Chicago/Cook County, and there is no way it should be subject to that tax jurisdiction – this is clearly an error in the TaxJar API which, from my hours of spot testing yesterday, seems to be affecting the entire state of Illinois.

As much as downstate Illinois likes to claim that we here in Chicago are imposing our will upon them, I guarantee you that the entire state is not subject to Chicago and Cook County sales tax rates. ??

As a follow up to this: If I go to the “Standard rates” section under the Tax tab in the WooCommerce dashboard, I can see all the Illinois zip codes I’ve tested, the rate that is being applied, and the tax name. All of them come up as “US-IL-COOK COUNTY-CHICAGO : COOK COUNTY Tax” with a rate of 10.25%.

I stumbled across this thread for the same reason as everyone else here – because your product description promises that free users below 1000 will have the logo removed, and yet that is not happening. I was hoping to find help and support for a bug, but instead I find that the advertising is deceptive. Really wish I would have had the truth before I spent an hour getting this all set up and tested. Now I need to do all that work over again with another provider, one who honors their word.

Working on a site just now, I experienced a further bit of this. I was on the Dashboard, no updates showing as available anywhere. Scheduled a post for later this week, and when I processed the scheduling, the page refresh now showed 16 updates available on both the admin bar and the notification beside Plugins in the menu. I clicked Plugins in the menu, and sure enough, in the list of plugins it showed 16 individual plugins with “An update is available for [such-and-such plugin].” I didn’t want to update them one by one – and wasn’t entirely convinced there were suddenly 16 updates available – so I clicked on the Updates menu item beneath Dashboard. On that page, it now showed zero updates – and the admin bar and menu notification had also cleared out. Returning to the Plugins page confirmed that everything was up to date.

I have been experiencing this recently as well, on all of the couple dozen sites I manage for clients and myself. And as @thefazz said, I too have been managing WordPress sites for years and started with all the obvious steps like clearing caches, looking for stray .maintenance files, etc. None of the fixes that have resolved this in the past are working now.

There definitely seems to be something going on related to a recent update, but we moved last week so I haven’t been as available as I would normally be to track and notate every nuance. What I do know is that I log in every day or two to all of my sites to run all available updates, and for the past couple weeks or so, this issue is occurring on all of them, where the admin bar shows available updates (sometimes as many as 16!!) which do not match the number actually available.

Just wanted to reassure you, @thefazz, that you’re not losing your mind and you’re not missing something obvious. This is definitely a genuine issue caused by some recent update. It’s very unlikely to be related to a specific plugin, because all my sites have different combinations of plugins and yet it’s happening universally.

Now that we’re moved and I’m back at work full time, I’ll try to track it more accurately and get more details for troubleshooting.

Oh, and you also have to get the plugin to regenerate things once you’ve made that change. After you change that bit of the code and saved it in _admin.css, then go back to the plugin, change one of the colors, and save it. This seems to rewrite whatever is screwing up the checkboxes.

Yes, I was just coming to report this as well. Digging into the files that get generated, in _admin.scss there is the following code:

input[type=checkbox]:checked::before {
content: url(“data:image/svg+xml;utf8,%3Csvg%20xmlns%3D%27http%3A%2F%2Fwww.w3.org%2F2000%2Fsvg%27%20viewBox%3D%270%200%2020%2020%27%3E%3Cpath%20d%3D%27M14.83%204.89l1.34.94-5.81%208.38H9.02L5.78%209.67l1.34-1.25%202.57%202.4z%27%20fill%3D%27#{url-friendly-colour($form-checked)}%27%2F%3E%3C%2Fsvg%3E”);
}

Comparing this to the old developer version from GitHub I’ve been using on previous sites, that same section of code in the _admin.scss is:

input[type=checkbox]:checked:before {
color: $form-checked;
}

If I replace the longer version above with this shorter version, then the checkboxes are visible in the Dashboard again.

I don’t write plugins and my php knowledge is shaky at best, so I can’t tell where or how this new version is being generated – but hopefully this gives the devs enough info to fix this.

The plugin has come a long way! My only remaining complaint is that there doesn’t seem to be a way to limit access by site (unless I’m just not seeing it). I have all my clients add my same Google account as the Analytics and Search Console manager, and with the Analytify plugin I could set it so XYZ account only had access XYZ’s Analytics – but with Site Kit it seems that all web properties tied to my Google account can be accessed from the WordPress dashboard. For most of my clients I’m the only one with WordPress dashboard access, but I can’t use this plugin yet for clients who have access to this themselves.

I will take a look this week sometime! It turns out my support notification emails were going to spam, so the ticket had been closed by the time I realized you were responding there, but I’m really hopefully this plugin will play nice with others in the long run. ??

Yes, because you are not tax advisers, you might want to stay away from that part. We only have nexus in Indiana, and we do have a certificate to collect tax in Indiana. PRINTFUL, however, has nexus in 37 states, and as a drop shipper, we collect the tax which we then pass right along to Printful, because Printful is the one remitting the tax. As explained here and here.

This is why your plugin is so problematic for us. When we ship things from our OWN store, which we fulfill ourselves, we are only required to collect and remit tax in Indiana, as that is where we have nexus. But your plugin is mistakenly forcing us to collect tax on OUR products, based on PRINTFUL’s nexus. This is forcing us to illegally collect tax in states where we are neither required nor licensed to do so.

I think the solution here is “find an alternative to Printful”.

Then could you please tell me where to find the tax tables your plugin is using? I know those are subject to change and it will be on us to stay current with that, but literally our only option right now is to set those tables up ourselves. We HAVE to be able to charge tax properly, and right now we can’t do that – your plugin hijacks the entire cart and applies tax on our own products as well as the ones fulfilled by Printful. That can’t happen, and so we’ll need to manage that ourselves. Your plugin is getting those rates from somewhere, and quite frankly I don’t feel like digging through your code to figure out where. Is it an API you’re accessing? A table I can download? Whatever it is, please point me to it (or have your developers do so) so I can set them up as my own tax tables directly in WooCommerce.

Please explain these technical limitations to me. If you have the logic in your code to apply shipping on a per-product level, then you have the logic to apply tax in the same way. Just because you haven’t done it that way doesn’t mean you can’t. The logic is exactly the same. If product = Printful then apply tax. If product ≠ Printful then rely on WooCommerce tax table. That is very easy logic, and logic which you are obviously already applying to shipping. Please have your integration team respond directly, because I need a clear answer as to why this logic has “technical limitations”. Our entire online store is at a standstill due to this.

There has to be a better answer than this. We have nexus in one state – Indiana. We can’t be expected to keep track of Printful’s 37 states and all their various tax requirements manually. (And I am a tax professional, by the way.)

It’s absolutely bad programming on your part for your plugin to hijack the entire store instead of applying only to Printful products. You obviously already have a way to separate Printful versus non-Printful items in the cart, because shipping rules get applied separately to the Printful versus non-Printful items in the cart. Simply extend this logic to the application of tax as well.

Hello, I am still waiting for a reply to this.