mrwweb

Thanks, @adamdunnage. As long as this is a known issue, I’m happy just waiting for a fix. Appreciate the quick reply.

Thanks for checking and the clarifications @d0153. I have to say that I think user testing would likely show that people want to see more event context on small screens, so maybe that’ll change in the future! We did find a way to override the behavior, so we’re all set.

Thanks for all these tips, @lovingbro! I believe I’ve run through every step you’ve suggested that we can follow, and here’s what we found. In short, we still have the problem and there doesn’t appear to be a way to reset the WP.com/WC.com connection.

1. Update the WooCommerce Tax plugin

Completed. Did not resolve issue

2. Reconnect your site to WooCommerce dot com from WooCommerce, Settings, Advanced, WooCommerce.com

We do not have a disconnect or reconnect button on that screen. Here is all we see. It seems like the site doesn’t have a way to manage the currently active connection.

We tried connecting on the WooCommerce > Extensions page, but that did not help. Note: the documentation link you shared recommends that path and not the WC > Settings > Advanced > WooCommerce.com path.

3. Clear the WooCommerce.com caches, then refresh service data

Did not work.

I also tried clicking the “Test WooCommerce.com connection” button which reported: “ERROR: Your site has a problem connecting to the WooCommerce Tax API. Please make sure your WordPress.com connection is working.”

4. Confirm automated taxes is enabled and store address is complete

Confirmed. The store has consistently been charging sales tax for some transactions, but there are some within our tax nexus state on taxable products that are not being taxed.

5. Check that nothing is blocking the REST request Security or firewall tools can block calls to the WooCommerce services. Ensure you can visit https, yoursite.com/wp-json in a browser without a block page.

The site uses the Sucuri firewall, but I can see the request to the tax service endpoint is not blocked (it returns a 500 and not a 403).

We can go to {oursite}.com/wp-json/

Copy any recent entries from WooCommerce, Status, Logs where the source is WooCommerce Tax, and paste

There are lots and lots of entries. Here’s the last three. There seems to only be the one error.

Hi @d0153 ,

Thanks for the response. I appreciate the need to prioritize! One thing I will say is that font-end markup churn always impacts folks developing with The Events Calendar (often your biggest promoters), and so it would be good to sort this out sooner than later, especially if it’s going to get reverted and or changed.

For the future, I would encourage getting a more complete accessibility audit done by someone who can interpret errors and recommend appropriate fixes, and then making a batch of template changes all at the same time. (I have more I’d recommend!)

@sucuri1 Thanks for the quick response and confirming that what I was seeing was, in fact, intended.

This setup is strange enough that I assumed this must have been a bug. Dark mode is a highly personal user preference to the point that it can be both improve and worsen the accessibility of an interface depending on the person (some folks need bright high contrast while others can have symptoms triggered by bright lights).

If there’s a big need to show the status of the firewall, it would be fabulous to create some kind of clearly, prominent, piece of user interface.

As it stands now, this was extremely confusing—I can’t overstate how confusing it was—and doesn’t align with any expectation I have of how interfaces and user preferences work. It’s fine to present it as an option, but even then, I would mostly expect that it match the entire WordPress interface which is always in light mode.

Thanks for your support, @shahzeenfarooq.

When viewing a product details page that has a cross-sell:

• The woocommerce/cart-cross-sells-block (the one with the Column block icon) still only shows a heading.
• The woocommerce/cart-cross-sells-products-block shows the cross-sell product.

It had never occurred to me that the cross-sell block in the cart would be contextual to the product page and not the cart contents, given that it’s always been possible to show cross-sells on the /cart/ page.

Inspecting the code, I fear that the current behavior may be intended:

data-__private-preview-state='{“isPreview”:true,”previewMessage”:”Actual products will vary depending on the page being viewed.”}’

However, I hope the development team might reconsider and make the cross-sell block contextual to the cart contents which strikes me as much more useful and likely to work.

In our case, we never expose the individual product detail pages, so this block currently has no value to us.

If this is the intended behavior of the block, and tips, pointers, and suggestions for a path forward on cart-based cross-sells would be greatly appreciated.

@rizaardiyanto @stevejburge I appreciate this is a tricky request. I was mostly curious if the error log tripped any recognition of similar issues or some troubleshooting tips you might have.

FWIW, I both recognize it’s hard for you to test a paid plugin and you can’t guarantee compatibility with everything. I did clarify with the #forums Slack that this thread doesn’t violate the paid support guidelines, but I understand if you’re just not willing to take this one on.

If you are, any ideas or tips would be greatly appreciated. I feel like I’ve seen similar array-to-string issues pop up with this plugin in the past, but I can’t remember the details.

Hi @rizaardiyanto. I’m not quite sure I understand. I’m using the free version of PublishPress Authors hosted in the plugin repository.