Three Gotchas with Toolset Blocks

Introduction

Updated October 19, 2020 – Although the Toolset team indicated back in July that fixes were in the works, there are still some things to keep in mind, as indicated in the updates below.

Updated July 20, 2020 – As noted inline below, the Toolset team responded positively to this article and many of the issues are being addressed.

Toolset is a powerful suite of plugins that makes it easy to work with custom fields and Custom Post Types. Last December Toolset released its new Blocks plugin, which brings many of the features of its powerful, but aged, Views plugin into the modern Gutenberg editor. This was a big move for Toolset that has a lot of promise.

For a while Toolset chased integrations with popular page builders, which was great for Toolset users because they could use their favorite builder with Toolset to create the single and archive templates. However, maintaining a bunch of integrations was a burden on the Toolset development team, it made Toolset dependent on these other tools and perhaps their schedules, and a change in one of those page builders could break Toolset and everyone would have to scramble for a fix.

Embracing the WordPress block editor is widely seen as a smart long-term decision for Toolset. The belief is that the WordPress core team is going to pour a lot of time and effort into Gutenberg and it will only get better. Also, as users embrace the new Gutenberg editor then the Toolset Blocks solution is seen as integrated into standard WordPress and as doing things the WordPress way. Users won’t have to learn a new UI for working with Toolset and support won’t have to be experts on every page builder. Gutenberg is certainly getting better and more people are comfortable using it.

I recently included Toolset Blocks in my series on Custom Post Types and Page Builders. Overall, I was pleased with the process and workflow. However, since that time I’ve used or tried to use Toolset Blocks on several projects, including one that I wrote about on this site, and I ran into several gotchas or glitches. What I found was that Toolset Blocks is getting better, but depending on your needs, it may not be ready yet.

Gotcha One – Toolset Isn’t Working With Many Third Party Blocks

This is the biggest and most problematic issue I’ve experienced. When you create a Content Template with Toolset Blocks you are currently able to also include core blocks, but not all blocks from popular third parties work. I was under the impression initially that it was possible to use any blocks in your Content Templates and there is no mention in any Toolset documentation about this limitation, but many other blocks don’t work.

Here is an example. I was creating the Content Template for single posts using Toolset Blocks. I added the Social Icons, Table of Contents, and FAQ / Accordion blocks from the Ultimate Addons for Gutenberg plugin to have these features automatically as part of all single posts. I had these features previously using Elementor for the single Post template and now wanted to implement the same thing with Toolset Blocks. Here are some screenshots of what I was trying to achieve. This was the top of the page with the social share icons and the table of contents.

This was the bottom of the page where I had an accordion for the affiliate statement.

Because Tthe style sheets from Ultimate Addons for Gutenberg didn’t load, the blocks were unstyled and I got a result that looked like this.

I had similar results when using the Qubely blocks plugin. This was reported to the Toolset support team and they said they were looking into the issue. A huge advantage of using the Gutenberg editor is to have access to the wealth of Blocks available for adding functionality, making pages more engaging, and attractive. That is, after all, one of the reasons why people use page builders. The inability to use many of the third-party block addons limits the Toolset Blocks solution.

Update – List of Addons that Work and that Don’t

Update 1 (July 14, 2020): The Toolset team has now confirmed that they are working to add compatibility for Ultimate Addons for Gutenberg. They will also provide information for Gutenberg addon developers on how to make their offerings compatible with Toolset.

Update 2 (July 20, 2020): It seems likely that one reason some third-party Gutenberg addons are not working is that they only load their style sheet on pages where their blocks are used, and this is not working if the page layout is controlled by a Toolset content template.

Update 3 (October 19, 2020): Toolset published an official list of Gutenberg addons that work with Toolset. The list below has been updated to mirror that. The active install numbers were also updated.

Supported

• Atomic Blocks – 60,000+ active installs
• Coblocks – 300,000+ active installs
• Kioken Blocks – 4,000+ active installs
• Otter Blocks – 60,000+ active installs

Not Supported

• Advanced Gutenberg – 30,000+ active installs
• Gutentor Blocks – 30,000+ active installs
• GenerateBlocks – 10,000+ active installs
• Getwid – 20,000+ active installs
• Kadence Blocks – 80,000+ active installs
• Qubely – Advanced Gutenberg Blocks – 10,000+ active installs
• Stackable Blocks – 20,000+ active installs
• Ultimate Addons for Gutenberg – 200,000+ active installs
• Ultimate Blocks – 20,000+ active installs

Gotcha Two – Toolset Styles Are Too Widely Targeted

Update (October 19, 2020): There have been several updates and this has still not been corrected.

Update (July 20, 2020): The Toolset team has confirmed this will be fixed in the next update.

The Toolset style rules are applied too broadly on the front-end of the site. There may be several such issues, here is one for example. The style sheet file:

wp-content/plugins/toolset-blocks/vendor/toolset/blocks/public/css/style.css?ver=1.2.3 

contains this CSS:

.entry .entry-content .tb-field a{text-decoration:none}

When you add the post body via a single text field block into a Content Template, that style rule gets applied to all of the links in the post content. According to my theme, links in the content are set to be underlined, but this CSS overrides it. It is possible to override the Toolset override with custom CSS but this is an example where the Toolset styles need to be adjusted to be more specific. I submitted this issue as a Toolset feature and got a reply from the person who reviewed it that it should be addressed.

Gotcha Three – Switching Between the Classic and Block Editors Has Problems

In the Classic Editor WordPress automatically added paragraph tags to content. When you create a Content Template using Toolset Blocks for old content created in the Classic Editor, and then add the post body via a Toolset Blocks Single Text Field block , those paragraph separators may not be present and all of your content will be one long paragraph. When you create content using the Gutenberg editor then it is displayed correctly. Here is a screenshot of the post content being added using a Toolset block.

This isn’t just old content, however, it is applied to content created in the Classic editor, old or new. Here is some content I created in the Classic editor. Note the paragraph breaks.

And here is the content rendered in a Content Template created using Toolset Blocks. Note that there are no paragraph breaks.

I discovered this about 4 months ago and reported it to Toolset support. After some back and and forth, they told me that it would not be fixed. As a work-around, instead of using the Single Field block to output the Post Content in the Content Template, I could insert a Classic block and then add the post content with this shortcode:

[wpv-post-body view_template="None"]

It was good to know that option was there, but using a shortcode defeated the purpose of moving from Views to Blocks. I suggested they add a checkbox to handle these cases as I imagined that a number of people would face a similar issue. After some back and and forth, they told me that it would not be fixed. Now, however, it is listed as a known issue, so perhaps it will be addressed in the future.

Update: Toolset has confirmed that they will try to find a solution for this issue.

For what it is worth, I found a plugin that converted Classic Editor blocks to regular blocks. It is called “Bulk Block Converter,” but by default it only works on Posts. Since my content was for a Custom Post Type, I hacked the plugin so it would also process my Custom Post Type records. Not an ideal solution.

Discussion and Conclusions

Contacting Support

I have always found Toolset support to be well trained and helpful. They are not always the quickest to reply but I have generally been happy with support. Toolset made some changes and now you have to sign in to view the support forums. Also, for some time now when you go to create a support ticket you see a notice that tells you how many support requests you have submitted and approximately how much time support has spent helping you over the last 30 days.

The notice is a very clever practice. It makes you aware of how much you have used support. I know I am self-policing (which is the point), but seeing that notice is a disincentive for me to contact support, even when I am trying to relay possible bugs or issues. For that reason I don’t bother reporting anything minor.

Documentation and Views in Legacy Mode

The Toolset team seems to frequently be changing the documentation links. I think they are responding to the feedback that sometimes Toolset is difficult for new users. Now, they have removed almost all of the old documentation and have replaced it with courses that highlight different Toolset features. This is what you see when you click the Documentation link.

When you click the big “Documentation Search” button you now go to a page to search the course content.

There are still reference links, but a lot of the help docs that relate to the Views plugin have been removed. The Toolset team wants to push people to use the new Toolset Blocks methods, but this seems a bit aggressive as there are advanced features of Toolset Views that are not yet available when using blocks. I tried the search and the old docs are still found, but you may have to do some digging and know what you are looking for. Views is now listed as “legacy” alongside Layouts and the Module Manager. Personally, I would have liked to have Toolset Blocks at parity with the Views features and outstanding issues before marking Toolset Views as “Legacy.”

Final Words

One of the things I really like about the Toolset team is that they are constantly iterating and making the products better. I appreciate that the team responded to this article and hope it can address the issues.

Toolset Blocks is still pretty new and perhaps deserves some time to grow. However, I hope they continue to provide support for “Classic Views” until Toolset Blocks are working well and have the features that make Toolset a go-to solution. Toolset has a bright future, but there are currently some bumps in the road.