Toolset Blocks 1.5 – Build Custom WooCommerce Product and Shop Pages

   Dario

Announcements

April 14, 2021
9

Toolset Blocks 1.5 allows you to assign templates and archives to product categories. Or even assign them conditionally. It also brings Price and On-Sale search fields, a new Stock Management block, full Kadence blocks compatibility, and more.

Highlights from this release:

  • Assign Content Templates conditionally
  • Assign archives to specific taxonomy terms
  • Custom search fields by On-Sale status and Price
  • The new Stock Status block
  • WooCommerce pagination and sorting options for archives
  • Compatibility with Kadence Blocks and theme
  • Compatibility with the Page Builder Framework theme

Watch this video for a quick walkthrough of the top new features in this release.

Easy Assigning of Templates and Archives to Products

Now, when you create an archive or a template, it’s applied. If there is no template or an archive for a particular item, the default WooCommerce templates are used instead.

There is no need to set any additional options on the Toolset → WooCommerce Blocks settings page anymore. Actually, that page became redundant so we removed it.

Use WooCommerce custom fields in templates, Views, archives and forms

WooCommerce adds a number of custom fields related to Products. Until now, to be able to use these fields in Toolset Forms and Views, you had to register them manually.

Now, all these fields are automatically registered by Toolset and you can simply use them in your front-end forms and Views.

You can even see all the fields and their options just like any other group of custom fields. Simply go to the Toolset → Custom Fields page and click the group named WooCommerce.

Improvements to Inline Fields

We greatly improved the Inline Fields feature adding a lot of new options:

  • Backend preview now changes the Inline Field values when you switch the template preview to another post
  • More output options for Date, Taxonomy, and Excerpt fields
  • Display “Post title with a link” and “Author Archive Link”

Improved Text-alignment Controls

Before, Toolset blocks didn’t allow you to disable an already selected text-align option. Now, you can do this and simply disable any text alignment. In this case, the alignment will use the browser defaults. This is especially useful for right-to-left languages.

More Specific CSS Selectors on the Front-end

Sometimes, your theme’s styling can override the styling settings you set in Toolset blocks. There’s now a new option which when enabled adds an ID to the body tag for use by Blocks CSS selectors. If the body tag already has an ID, it uses that one.

Compatibility with Kadence Blocks Plugin and Theme

This release brings full compatibility with both the Kadence Blocks plugin and the Kadence theme.

Now, Kadence blocks feature Toolset’s Dynamic Sources options. This means you just got a bunch of additional blocks to build your dynamic Toolset sites.

And when you build templates and archives, there is now a new Theme Options section. It allows you to tweak certain layout options for each design separately.

We also created a completely new Tutors demo site so you can see different Kadence blocks using Toolset’s Dynamic Sources.

Compatibility with Page Builder Framework theme

We also added full integration with the Page Builder Framework theme. It’s a fast, lightweight theme that provides a lot of customization options.

As it is completely compatible with Gutenberg, it makes perfect sense to make it work great with Toolset.

When you design your archives and Content Template, look under the Theme Options section and you will get a ton of theme options to tweak for each design.

Improvements to Compatibility with the OceanWP theme

Both OceanWP and Toolset made big improvements recently, helping you create rich sites with Gutenberg. OceanWP updated their styling to make the backend editing look the same as the front-end results. It also added support for new Gutenberg features.

Toolset’s support for OceanWP also improved a lot, so that you can control every page on your site:

  • Better mechanism for disabling elements (postmeta, archive titles)
  • Fixed an issue with disabling the pagination on archives
  • Fixed an issue with disabling the sidebar in some scenarios
  • Fixed the styling of some elements

Performance Improvements

In May, Google starts ranking sites by speed.

Toolset 1.5 brings big improvements to resource loading on the front-end. Essentially, Toolset’s impact on your site’s speed is now cut down to a bare minimum.

Next week, we’ll publish a separate, in-depth article about this whole topic.

Full Changelogs

This release brings updates to all Toolset plugins.

Links to full changelogs:

Download and Update

We send out the update notifications in batches, so not everyone will see the update notice at once.

To get this update now, in the WordPress admin go to Plugins → Add New and click the Commercial tab. There, click the Check for updates button in the Toolset section.

Share Your Feedback

What do you think of the new features? Any thoughts or suggestions?

Let us know in the comments and we’ll reply!

 

Comments 9 Responses

  1. Hi Dario,

    On the performance improvements, do these apply to templates, views and archives of all hues i.e. block or traditional?

    • Hi, Stephen! Yes, we optimized both the block and legacy workflows for templates, Views, and archives. Of course, they are different due to the different way blocks work. In short, we concatenated and minimized the assets that get loaded on the front-end. Previously, they would have been loaded separately, and may not have been minimized versions.

      • Hi Dario,

        I can confirm that I see some improvements across several sites. But, I need to return to WooCommerce Blocks being a little problematic in one instance. I found that it completely broke one of my Divi Theme builder layouts using toolset. From some careful investigations I was able to just turn it off as it seems I don’t need any of its feature on this site. Funnily enough. on another Divi builder theme layout where I am using mixed in blocks, it didn’t cause any issues.

        • Hi, Stephen! Honestly, we can’t tell without taking a deeper look. Could you please create a ticket for this in our support forum so our supporters can see what’s going on there and raise it to developers? Thank you for your questions and feedback! 🙂

  2. Hi Dario!

    I just loaded the new versions, and could see that there has been some work done, indeed one css script is gone (seems now inlined instead of enqueued), and the code is indeed minified (it was in some – but not all – cases already in the older versions).

    I can however not see it loads with file.min.css/file.min.js extensions.
    Does this have a specific reason?
    Not that it would change anything in performance, what makes it “faster” is of course the actual minified code, however it might trigger some doubts when people check the source (head and footer) and do not see the expected “min”, triggering perhaps some doubts wether or not it is truly minified, you know how it goes…

    Also I was able to see that (even if I do not use a single block on my site and explicitly disabled any block feature where possible in Toolset), a whole inline CSS block of Toolset Blocks is loaded (in the head, not enqueued but inlined).
    This may have a plus point as it avoids one query, but it has the big minus point that now we can’t dequeue that style manually (which I do on most sites since they aren’t using block features, at least not on homepages). Another minus point is that inline cannot be “minified” in this sense. Not sure this has any speed effects, however considering that you still load actual CSS files enqueued, such as public/css/views-frontend.css file, I wonder why the inline view_editor_gutenberg_frontend_assets-inline-css style is loaded as well and inlined instead of bundled into the already loaded files?

    Finally I could see that – while mostly minified – some files still break lines inside their code.
    A “truly” minified JS code wouldn’t have line breaks in it. It would be one single line of code, as far I know (but I might be wrong).

    Check for example main.js of Toolset Forms, compared to toolset-common-es-frontend-js. The latter is truly minified, the first features line breaks.

    Can you shed some light in these peculiarities?
    Thanks!!

  3. Hi Dario,

    Pleased to hear about the focus on performance. I think more could be done with images to improve things further, for example choosing the size of a background image of a container (it just pulls through the full size, it would be great to be able to choose thumbnail/medium etc size particularly for grid based views where the size of each loop item is small). Similarly being able to chose the size of the images pulled through for slider thumbnails and the Lightbox separately (e.g. medium for thumbnails, large for Lightbox) – full size images aren’t always necessary for these. I’ve also noticed I get the “Image elements do not have explicit width and height” warning in Lighthouse when using Toolset images.

    If you can solve these along with the hopefully imminent introduction of Openstreetmap maps and better integration of GenerateBlocks – that would solve most of my Toolset bugbears!

    Thanks

    • Hi, Joel! Thanks for the comment! Yes, we are aware of these further optimizations for images and already have planned tasks for them (I don’t have a schedule at this moment though).

      OpenStreetMaps are slated for the next big (1.6) release, so yes, the development will start soon. 😉

      Regarding GenerateBlocks… They recently went out with their own alpha version of displaying dynamic content. We reached out to them about a possible integration with Toolset and it just didn’t work out. That being said, there are no plans on this integration.

      • Thanks Dario. Great news regarding OpenStreetMaps 🙂

        That’s a shame regarding GenerateBlocks – this workaround has helped to some degree so hopefully that will at least continue to work.