I am seeing a unnecessary stylsheets loaded with Woocomerce Views or Toolset Veiws on the frontend, creating poorer performance of the site. When either are activated, for example, I see the following add on the front end, causing an error:
Hello, can you try these troubleshooting steps?
- Temporarily deactivate all plugins except Types and Views, and activate a default theme like Twenty Twenty
- Test again. If the extra file is no longer enqueued, reactivate your theme and other plugins one by one until the problem returns. Let me know the results of this test.
- If the problem is not resolved, please let me know.
Hi, the problem persists when Toolset WooCommerce Views is active. It's not there if just the other two plugins you mentioned are active. I have left the site with the default theme and just these 3 plugins activated so that you can confirm. Thanks.
I can see the fonts API loaded on your site now. Feel free to reactivate other plugins and your theme, and I will continue investigating locally. Thank you!
Okay I'm escalating this to my second tier team for further investigation. In my local environment I can reproduce the same issue with only Toolset plugins active (not even WooCommerce), so it seems that the problem was recently resolved in Views/Blocks but not in WooCommerce Views. I will keep you posted as I receive more information about the problem. Thanks for the report!
I applied the fix mentioned here: https://toolset.com/errata/toolset-loads-extra-google-fonts-files-on-the-front-end/ so that's probably why I don't have it with just the Views plugin
To clarify, I want to mention that the erratum you linked to was already resolved in the latest Views and Blocks versions. That means the noted patch file is no longer required for Views or Blocks. It's possible that the issue is not apparent with WooCommerce Views active without Views active, so that would seem to indicate the problem is in Views. However, Views (or Blocks) is a dependency for WooCommerce Views. Without it, WooCommerce Views does not function fully. So the problem in WooCommerce Views was not evident during that test with Views deactivated. That would be confusing during a plugin isolation test, since it could seem the problem was in Views if WooCommerce Views was active but Views was deactivated, and the issue was not reproduced.
You would be able to confirm this by deactivating and deleting Views, then reinstalling the latest version. That would remove the patch file you applied before. Then activate only Types and Views, not WooCommerce Views. At this point, the issue should not occur. Then activate WooCommerce Views, and the issue should return. That's what I'm seeing in my tests, if it's not the same in your environment please let me know.
If a similar patch file is made available for the WooCommerce Views plugin, I'll let you know as soon as possible.
So, is there a chance the patch file won't be offered for WooCommerce Views in a timely fashion? It's really bloating up our page load time and impacting SEO. We may need to give us Toolset all together if this is the case.
As far as latest versions, I am a little confused, I only see Toolset Blocks and Woocommerce Blocks, are those latest versions you are referring to? Will they work if we still use the classic editor?
Yes, you can still use the classic editor if you install Toolset Blocks, there is a setting in Toolset > Settings > General that will allow you to display the classic editor instead of the Blocks editor. Toolset Views is still available in the legacy plugins section, but for now, the features in Toolset Blocks and Toolset Views are identical. The only difference so far is that Blocks, by default, has the Block Editor active and Views, by default, has the classic editor active. You can toggle between the two editors in Toolset > Settings in either plugin.
Toolset WooCommerce Views and Toolset WooCommerce Blocks are the same thing, the terminology is confusing because it's listed different ways in different places. However, both names refer to the same plugin.
My team leader is going to try to put together a patch file for your site because the final plugin fix may take a month or more given the current schedule and priorities. I'll let you know when it is available.
Sorry for the inconvenience, our system team is aware of some sporadic 403 errors on the site and is working to resolve the issue. If you cannot access the link in your regular browser, please try a different browser as caching may be part of the problem.
Hi, Nigel's day has ended but I will leave a message for him to take a look when he returns in the morning. I tested the workaround code in my own local environment and it does not seem to solve the problem for me either, so there must be something different in Nigel's environment that is affecting the results. I'll follow up with you tomorrow after I have spoken to Nigel.
