designsimply

It sounds to me like it might be a problem specifically related to the status of your payments for shipping labels, possibly involving refunds. It could also be a problem based on an account or database change. If you haven’t already, you might check the WPAdmin > WooCommerce > Settings > Shipping > WooCommerce Shipping section in your dashboard and verify the credit card on file there is the correct one and that it is not having any problems with new charges or recent refunds.

When you say you downgraded the plugin, do you mean you installed an older version of the plugin (do you know which version?) or do you mean that you deleted the plugin and then re-installed it? Are you using the latest version of the plugin now?

To get further help, I would recommend contacting the support team directly at https://woocommerce.com/my-account/create-a-ticket/?form=ticket and include a copy of the status report from WP Admin > WooCommerce > Settings > Status and, if possible, a screenshot of the error (including a view of the console errors if you can get that) and as much information as possible that you can provide about any recent changes you’ve made to your site or any refund requests you have made for shipping labels. For example, have you made any recent changes to the database for your site or did you move from a staging server to a live server recently? Did you request one shipping label refund and it went through but you continue to receive an error about that refund? Or did you make several refund requests recently by chance? Did you request a refund but then change the card you’re using for shipping labels afterward? Anything like that would be helpful for them to know.

Hmm, 🤔 a 5.8 update may or may not have been the thing that solved this—but I don’t want to go back and re-test in an older version unless I have to 😁 thanks for the follow-up note!

I tried a super quick test and couldn’t get the same problem to happen (video: https://cloudup.com/cPhlpNSq528).

It’s strange that the error from your console log says, “Uncaught TypeError: Cannot read property ‘not_selected’ of null” if you did indeed select the suggested address.

When you were testing, was the suggested address definitely selected similar to what you can see in this screenshot from my test? https://cldup.com/Z0DnjCymWJ.png

If it was, the only thing I can really think of right now would be to try toggling the selection—meaning select the Address entered and then the Suggested address again to try to get that selection to be seen. Also make sure any selections on the previous tab are correct. If that doesn’t help then hopefully the plugin developers can have a look to see if they can spot anything I missed. It’s really cool that you included the console log btw!

Oh, one more thought if that above suggestion doesn’t help, do you have any browser extensions or add-ons installed by chance? I saw that you did test in Firefox too, so the chances are pretty slim that a browser extension or add-on is the culprit but it’s not outside the realm of possibility.

Testing note: I used the following versions of things in my test: WordPress 5.8, Jetpack 9.1.1, WooCommerce 5.5.1, WooCommerce Shipping & Tax 1.25.17, Chrome 91.0.4472.114 on macOS 10.15.6.

👋 hi! Thanks for including the settings images, it was nice to be able to see those.

In the documentation at https://docs.woocommerce.com/document/woocommerce-shipping-and-tax/woocommerce-tax/#section-4 it says: “If your store is based in the United States, you only need to collect sales tax from customers in locations where you have a “tax nexus,” which typically means a physical presence. WooCommerce Services uses your store address (WooCommerce > Settings > General) as your “tax nexus”.”

And that matches with what I see in the “Settings Log.JPG” file you provided. If you look at the lines that mention the API call (i.e. taxjar/v2/taxes), you will see there are two related calls in the log. The first example with timestamp 07-20-2021 @ 15:25:45 mentions from_state=AZ and to_state=PA. The second example with timestamp 07-20-2021 @ 15:32:23 mentions from_state=AZ and to_state=IL. Based on your settings with your tax nexus located in AZ, the orders from the other states will not be charged tax because you are not located in those states. This is the default, and unless you have a physical presence in those other states as well then normally you do not need to charge tax for them. With the plugin, it is possible add a tax rate for other states in addition to using automated taxes to charge customers from that state tax as well, however, before you setup anything like that I would recommend contacting a certified accountant to ask if there’s any reason you would need to charge tax for orders you are shipping to other states such as PA and IL.

👋 I got a bit curious about this and decided to test it, and it worked in my test. I setup my store in the USA though. I noticed that the API used for tax calculations is supported in 30 countries, including some in Scandinavia, but you should check the list for your country specifically. You can find the list of supported countries at https://developers.taxjar.com/api/reference/#countries

Okay! Backing up just a little (and for reference), in my test I used the following versions of things:

• WordPress 5.8
• Jetpack 9.9.1
• WooCommerce 5.5.1
• WooCommerce Shipping & Tax 1.25.17
• No other plugins!

In my test, I followed the setup and configuration guide at https://docs.woocommerce.com/document/woocommerce-shipping-and-tax/woocommerce-tax/ and I feel you should also double check those settings. In addition, make sure the products you want to have taxes calculated for have “Tax status” = “Taxable” in the Product data > General section (just below the description area when editing a product). I had mine set to “None” at first (mine was a test site don’t forget) and of course the tax won’t calculate for a product if its tax status is set to none. If you’re in contact with the WooCommerce support team, hopefully you are since it was mentioned in the previous comment, you’re probably already checking up on those things but if you haven’t started troubleshooting with them yet then do have a look at the troubleshooting section in the setup guide (linked earlier in this paragraph) because there’s also a helpful instruction there for how to turn on logs for the taxes and those details may come in handy when working with the support team.

Best of luck and please message back here if you are able to resolve the issue so I know how it turned out!

I tested with Edge 18 and found that columns in the editor in the columns block were using word-break: break-word; (not break-all) and that the wrapping worked normally in the editor and on the front-end.

Tested with Edge 18 on Windows 10 via browserstack.com on a site running WordPress 5.2.3 and Twenty Nineteen 1.4: https://cloudup.com/cL48OulNg5V

Could you test with Twenty Nineteen v1.4+? It would also be good to note your WordPress version as well as IE and Windows versions. Maybe not having the latest version of one of those is the difference compared to my test?

Several performance updates have been made to Gutenberg in recent releases, so the first thing to check would be that you have updated to the latest version of WordPress (currently 5.0.3) and that you have uninstalled the plugin (which is now only needed if you are working on development of future features).

I noticed you mentioned working in a table. If you’re still having trouble even after updating WordPress, could you note approximately how many rows and columns your table has?

Don´t know what widgets have to do with it.

Sorry that wasn’t clear! I was trying to say that widgets are first and adding block capabilities for comments isn’t planned yet but that the work on widgets may help pave the way for that.

I mean some filters, nothing fancy and via GUI. As it is possible now, via filters.

Could you make a plugin that does that?