WooCommerce Views 2.7.5 and Types 2.2.17 Make WooCommerce Sites Stable

   Agnes Bury

Announcements

October 31, 2017
14

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.

Types improvements

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.

 

Comments 14 Responses

    • Hello, yes, we are. We will have a hotfix release for CRED before the end of the day, and Types is likely to get one as well. We haven’t seen any other issues in any other Toolset plugins, but in case we find any, there will be addressed with top priority.

      • Hello. I haven’t noticed any issues, but was waiting to upgrade my Toolset components until there was some confirmation that it was okay to do so. Thanks for the update!

  2. When you say “any theme”, does this include the Beaver Builder theme (and the associated Beaver Builder Themer plugin) ?

    • Hi Jean_Francois, some people use the two successfully (please check this video for example). We didn’t get any report about it being broken but our developers have requested the newest version of BB to test it with Toolset to check if there aren’t any glitches.

  3. There are many problems between the CSS of DIVI and Bootstrap.
    But I can not disconnect Bootstrap if I use CRED or grid layout for archive pages.
    This is a serious problem.

  4. Hello,
    I’m still waiting on a date for adding the ability to rotate an uploaded image on the front end. I have seen that CRED 1.9.3 has modified the upload macanism to use the WordPress ajax.
    Does that mean image rotation will be soon integrated in?
    I have been waiting for this function since some months now and have received an anwser from the technical support that this has been accepted in the CRED todo list at that time.
    Just want to have an idea of the potential awalability date if possible, knowing I need it for one of the current projects I’m working on !

    Thanks for your answer
    Regards
    Pat

    • Hi Pat, thanks for the feedback

      Yes, you are right: CRED 1.9.3 added native AJAX upload for file-related fields on CRED forms. It was a first step towards using the WordPress native media upload manager, which includes thinks like metadata and other nice features.

      However, image editing is not included in this native upload manager: it is fired separatedly. Our roadmap goes step by step, and first we will implement the uploader. Only after that we will evaluate how to better integrate the rotation and other editing actions.

      I am sorry if this is not soon enough, but we do need to go step by step.

      Regards.

      • Hi Juan,
        Thanks for your feedback. I can understand that thinks must go step by step but in the same time, I think that it should be feasible to have objectives in terms of implementation.
        Again, to me,this could be a very good improvement to offer this functionality as currently, we all know that image orientation is something difficult to manage in the front end (there is lots of articles on IOS and so on …). In addition, some code seems to be available and the issue is to insert it at the right place in the Toolset CRED plugin.
        I really hope this can be done in a short period of time and that Toolset team will work to offer it in one of the next CRED version.
        Many thanks for all your are doing within Toolset !
        Pat

        • Hi Juan,
          In the meantime before this function is available from Toolset, is it possible to have the following information in order to add my own php code :
          – Where is located the file used for image upload in the Toolset plugin
          – Is there a hook available in order to add some lines to the current code ?

          Thanks for your feedback
          Regards
          Pat

    • This week, we’re planning to release an update for our Google Maps component, which will support “distance search”. This will allow you to create a custom search, based on the distance between results and some point. That point can be an address (like in your example) or the visitor’s location. We’ll announce it on our blog and send a newsletter when it’s ready.