WooCommerce Views 2.7.5 and Types 2.2.17 Make WooCommerce Sites Stable
In this release, we practically rewrote WooCommerce Views, making it solid and fully compatible with all of the themes that we recommend. Now, you can build custom WooCommerce sites with Toolset, without having to worry about theme conflicts.
The highlight of this update is the major update to WooCommerce Views. Since the project started, both Views and WooCommerce plugins received significant updates, leaving the integration plugin – WooCommerce Views – behind. We did a full update for WooCommerce Views, resolving all issues and future-proofing it for the next round of updates.
Much of the compatibility problems were between Divi theme and WooCommerce Views. When using Divi Builder to design your single WooCommerce product pages and the main Shop page, there was an issue with inserting certain fields. The fields insertion into modules was unreliable; sometimes they would appear correctly, sometimes they wouldn’t appear at all. Now it’s all tested together and working.
Besides the stability improvements of WooCommerce Views, we also included a number of other stability improvements in Types. See the details below.
Protection against conflicts with reserved names in WordPress
We were missing some WordPress reserved words being blocked when adding a custom post type. For example, if a new post type was added with the “title” keyword (which is a reserved word), Types would allow this but then the user would end up with a 404 error page when displaying posts based on that post type on the front-end.
As of now, you won’t be able to create post types with reserved names.
Fixed the issue with adding conditions for custom fields
When you tried to set conditions on single fields in Toolset Types and the Toolset Views 2.5 (the recent version) was active, Types wouldn’t allow you to add the condition and you would end up with an error in the error console.
The issue is fixed and now your conditions for your custom fields are being saved.
Fixed the formatting issue on WYSIWYG fields inside Content Templates
When adding text that splits over multiple lines to a WYSIWYG field in the visual mode (both in Content Templates and in Layouts), the line breaks were not preserved when rendering the field. After saving the post and viewing it on the front end, the WYSIWYG text appeared in the same line.
The issues is fixed in Toolset Types by running the standard filters for the WYSIWYG field.