Toolset Blocks 1.1.1 – Beautiful Responsive Design Made Easy

   Amir

February 5, 2020

We’re happy to announce Toolset Blocks 1.1.1. This release gives you everything you need to build beautiful and fully responsive designs with Toolset and the WordPress Block Editor.

It’s easiest to explain “responsive design” using an example. Look at our own homepage and how it’s improved with Toolset Blocks 1.1.1.

Control the appearance of any element for different screen sizes

See how the “phone screen” design for our homepage improved with Toolset Blocks 1.1.1:

Desktop design

Old design – phone

New design – phone

The old design used the same font size for the header on both desktop and phone screens. You can see that while the header looks fine on desktop, it looked too large on a phone screen. The new design uses a smaller font size for tablets and even smaller for phones.

How did we achieve it?

Toolset Blocks 1.1.1 allows you to design every element for different screen sizes.

The heading block with settings for desktop screens

The heading block with settings for desktop screens

The heading block with settings for phone screens

The heading block with settings for phone screens

You will see the screen size selector when you edit any block coming from Toolset. Now, you can fully control the appearance of any block for different screen sizes.

Create responsive columns and grids

Columns are a big challenge on narrow screens. While several columns fit nicely on a desktop screen, on phone screens, typically only one column will fit. And since almost every design needs columns, it’s a big deal for responsive design.

Toolset Blocks 1.1.1 offers its own Grid block. You can use it for simple columns and for complex grids.

Grid Block settings
Grid Block settings

What makes Toolset’s Grid block so great?

1) Convenient controls over columns width
Click between any two columns to resize them. Set different column sizes for different screen widths.

2) Accurate setting for column and row gaps
You have full control over the gap (space) between columns and rows.

3) Different column per screen size
On wide screens, place several columns. On tablets fewer and usually, one column is great for phone screens.

4) “Reverse column order” for sensible image positions
This feature allows you to control when “floating” images appear on phones. Reverse the column order for right-floating images to come before the text on phones.

5) Use the Grid block in pages and in Views
The goodies of the Toolset Grid block are also available when you create Views. The new grid layout makes your Views look great on narrow screens.

6) Protects you from losing content when reducing the column count
When you reduce the number of columns, your content automatically shifts.

7) Clean and conflict-free CSS
The Grid block generates dynamic CSS based on your settings. This results in tiny CSS that works perfectly with any theme and other plugins.

8) Auto-adjusts to screen width
Use the screen-width control at the top of the editor to view your design on different screen sizes. The grid shifts automatically as the screen size changes.

You guessed right. The grid above is created with Toolset’s Grid block. View this post on your phone and see how it looks 🙂

Hide elements when they don’t make sense

Many designs use fancy (and pretty large) images. These images often look great on a desktop but don’t contribute much on phones. Toolset Blocks 1.1.1 allows you to hide any element on different screen sizes.

All elements showing

No image on phone screen

You can see that the big image that we’re hiding on the phone is really not needed. The design works better without it (less scroll to get to the point).

To achieve this, you’ll find a “Display” control when editing any element.

The option to hide a Toolset block on screen sizes of your choice

Switch to the target screen size on which you don’t want to show an element and hide it.

But wait. There’s more!

Once you’ve hidden an element, Toolset helps you remember that it’s there, just hidden.

Reminder icon for hidden element

Click on the reminder icon to edit the element’s settings. There, you can quickly unhide it.

Download and Update

We push out Toolset releases gradually. If your sites haven’t received this update yet, give it some time and you’ll see the update in a few days.

To skip the queue and get the update right away, to the Plugins –> Add New page, click the Commercial tab and then click the Check for updates button.

You can also download the plugins manually by going to your Toolset account and clicking Downloads.

Don’t forget to backup your site before updating.

Feedback? Questions? Suggestions?

Are you already using Toolset Blocks to build websites? What do you think about the new responsive features in this release?

Please leave comments with your questions, ideas, and suggestions and we’ll get back to you.

 

Comments 72 Responses

  1. Cool, it was about time. Now I can rely on less gutenberg extensions to handle this part.
    Thanks! I’m heading to a test right away!

      • Okay, here is my first feedback on this.

        I like the new way of visually building views, however I see a general flaw here, since if I go the Blocks extension way the Toolset back-end will not allow me to separately edit my views anymore, as with the Views extension.

        This is because the back-end sub-menu where we can see and edit our views is gone with the Blocks extension.

        I find it odd having to create my views in a sandbox page where I will play with a view until I like it, and then implement on a live page.

        Also since the Views submenu is gone, there is practically no way I can delete a View from the database. I will be doomed to have my list of all my test views with me until the end of my project.

        So please return us the Views submenu (Toolset>Views) where we can see a list of all our existing views. Where we can also edit and create those views. Or at least give us a way to delate the odd ones.

        I realise this will require having a dummy sandbox page with Gutemberg editor for creating and managing views. But hey that isn’t that bad. You can call it the Views Editor page.

        • Hi Diyan,

          There is a solution, and Dario or other support can correct me if I am wrong. Disable Toolset Blocks and Install the latest version of Views. Basically it is Views as we know with all the block goodness tacked on.

        • Hi, Diyan and Stephen!

          First, please don’t do what Stephen suggested, there is really no need to uninstall Toolset Blocks and install Toolset Views. 🙂

          On a site where you have Toolset Blocks installed, to see all “legacy” Toolset admin pages, simply go to the Toolset → Settings page and scroll to the “Editing experience” section. There, select the option to “Show both the legacy and Blocks interface option…”.

          You will now be able to go to the Toolset → Views page and see a list of all the Views in your site. You can delete any of the Views there and you can click to edit them, but in this case, you are taken to the page where you originally created them and can edit them there.

            • It’s cool, there are always multiple ways of achieving the same thing but I needed to share the best one with you! 🙂 Thank you both!

          • Hi Dario, What happens if the page where the block was created its deleted? I cannot edit never more?
            What about blocks that suddenly appears with a message: “This block contains unexpected or invalid content” Resolve or convert to html buttons appears. Both of them converts the tootlset code to a wrong one and i have to recreate the column? And what about big images sizes appearing when blocks is installed? Are these things corrected in these 1.1 update? thanks

  2. Are the breakpoints for mobile, tablet, desktop fixed or can they be changed by some mechanism? Is there inheritance of rules (e.g. mobile first)?

    • It appears you can change the 2 breakpoints between mobile/tablet/desktop by going to… Toolset > Settings > General … then scroll to bottom of page. Would be nice if there was 1 or 2 extra breakpoints.

      • Exactly as Peter suggested, the breakpoint options are available on the Toolset Settings page. Peter, I will mention your suggestion to the team. Thanks!

        • I’ll second the need for more breakpoints (phone, tablet portrait ~768-1024px, tablet landscape ~1024-1240px, desktop ~1240-1440px, desktop XL.
          The ideal perhaps would be to just have a repeating set of two columns with label and an arbitrary media query.

  3. Looks good. I haven’t had time to test yet but I trust the block editor width shrinks down automatically as you use the tablet and mobile viewports.

    What is the fourth icon after the desktop icon in the top tool bar? What does it do?

    One viewport which is my ch needed for responsive design is one for tablet in landscape. I would even push it as far to suggest one for small/medium laptop viewports. Too many time I have to roll some extra css for these in the theme or child theme style sheet.

    • Hi, Stephen! Yes, the editor width changes according to the screen size you select.

      The fourth icon is to select whether you want the editor width to shrink as you select smaller screen sizes or not. For example, you might want to edit the design for the phones, but you prefer the editor width to stay full. In this case, click this fourth icon to disable it. As you do that, all design tweaks for the phones will still be visible (changes to fonts, margins, column numbers, etc.) but the editor will stay in the full width.

      Try it out and I’m sure you’ll immediately see what I mean.

      I will share your suggestion about the landscape tablet viewport, but as with every other feature requests, it will depend on how requested this is.

      Thanks a lot for your comments!

      • Hi Dario,

        Just doing a bit of testing and one edge case is where in Divi, if you have customised the the styling to accommodate sections to span the full width of the browser window, the grid will automatically go wide 100%. In Kadence rows which I have used in previous testing, under Structure Settings you can set a content width so that the inner content sticks to a main content width intended.

        I suppose applying a class to the grids and then setting widths for each breakpoint is a workaround.

        • Hi, Stephen! Could you please clarify, when you say “the grid will automatically go wide 100%” do you mean that:
          1. You are talking about the new Toolset Grid block?
          2. You don’t want the Grid block to automatically go 100% wide?

          If this is the case, can’t you simply insert the Toolset Grid block into a Toolset Container block and then for the Container block, expand the “Inner Content” section and set the “Max-Width” option to whatever width you want your Grid to have?

          • Aha! That’s the way to do it. There are so many new elements in the form of blocks to play with that it is hard to keep track of them all at this early stage. And tis is better than the Kadence row which doesn’t seem to cover responsiveness in all areas.

            One thing I do notice, and I see this as a block editor issue in general, is dragging elements into others in a nested manner. It is impossible in many instances. So dragging my grid into the container, it either ends above or below the container. I find I often have to start over with my nested elements in the layout.

            • Great, I am glad it helped! 🙂 Yes, I believe that’s related to the Block Editor. From what I remember they are aware of these dragging/nesting issues and I’m sure we’ll see a fix for them, hopefully soon.

            • Hey Stephen and Dario. I too noticed that it’s difficult or impossible to drag blocks into an empty TS Container. However, if you first create any new block inside the Container, such as an empty text block, you’ll then be able to drag whatever you want into the container. Afterwards simply delete the empty block. No need to start over/recreate any elements.

              Speaking of dragging and nesting, I really want to be able to drag and nest blocks via the block selector drop-down at the top of the screen. I assume Toolset can’t control that. So Dario, could Toolset get a feature similar in style to the block selector, but where we could drag and nest blocks up and down anywhere in the block tree structure? This would be very helpful when layouts get complicated or very long.

            • Hi Dario… I figured out this would be the way to do it – so I inserted my grid inside a Container Block and set the Inner Content ‘Max Width’ value – but it seems to have no effect. The grid still resizes to the full screen width. Any ideas? I will explore further…

  4. 😁

    Just spotted. You used a screenshot image of a site (pottery) I built in one of the article images.

    Nice one 😎✌️

  5. Critical error installing the plugin through commercial section or through downloading and uploading through 🙁 been waiting for a long time for this update

  6. Sounds good. Does this make the grid/responsive layouts aspect of using Bootstrap 4.0 redundant?

    I am in the planning stages of upgrading from Bootstrap 3.0/Layouts/Views to Bootstrap 4.0/Blocks. Now it seems it may just be Blocks without the need for Bootstrap?

    • Hi, Gavin! Well, for new sites, yes, it does make Bootstrap redundant because you can build and layout everything using the new Toolset Grid block and the Grid options for your Views.

      However, on existing sites, the already-built Views do not get automatically converted to the new grids. So if you have such Bootstrap-based elements on existing sites, you need to keep Bootstrap, or convert them all to the new grid system.

  7. Got a critical error while uploading on a fresh WordPress website. Please look into the issue.

    Thanks for the update and much-needed features though.

  8. This update looks pretty great!

    Couple issues I’ve found while testing…

    1) On a couple of test pages where I had built grid views with blocks using the previous version of TS Blocks, I received an error when first editing those pages after updating TS Blocks to 1.1. The error was in a block and read “This block contains unexpected or invalid content. [ Resolve ] [ Convert to HTML ]”. This error had an option similar to “Attempt to recover this block” which worked. Just wanted to mention this in case anyone else is reporting this.

    2) Right now I was trying to add a box shadow to a TS Container while in the tablet responsive mode. I enabled the box shadow option by clicking the toggle, but when attempting to change any of its settings the box shadow properties box would close and the toggle would revert to disabled. I was eventually able to make changes by first changing the responsive option from tablet to desktop. Once I was able to make changes, I set the horizontal shadow position to 0 but right afterwards I attempted to change the shadow opacity by sliding the opacity slider to the left but whenever I do this the horizontal shadow position changes itself to -4. When I attempt to fix the horizontal position by changing it back to 0, the shadow opacity resets itself darker!

    There are definitely some glitches with the box shadow UI.

    • Hi, Peter! Thanks a lot for reporting this. For the first issue, are you still able to replicate this on your site? If so, I would kindly ask you to report this in our support forum, so our supporters can take a look and debug it and then forward the info to our developers. These errors usually happen in certain rare scenarios and are usually hard to replicate. However, access to a site where this can be replicated usually results in finding the root cause.

      Regarding the second issue. I will report this first thing in the morning and we will test it, thanks for the detailed description. Yes, it could be a bug in the Box Shadow UI but our testers need to test, replicate, and confirm.

      Thank you!

      • Hi Dario. Unfortunately I’ve already deleted the pages that produced errors. Luckily they were only test pages as I was waiting for this grid update before doing any real work with Toolset on new projects.

        As for number 2, I no longer experienced the problems when building on a new/clean page. Previously I was building on a page that also contained a grid-view built with the previous version of TS Blocks so maybe there was some sort of conflict between the two versions being on the same page. To test Divi’s new Gutenberg block feature, I had also inserted a Divi module via blocks on the same page, so maybe it caused a problem too. So at the moment maybe don’t waste your time looking into the problems mentioned. If they occur again when building new pages/posts, I’ll be sure to let yas know.

        • Thanks for the quick follow-up, Peter! OK, that additional information helps a lot. I’ll do a quick test just to make sure it doesn’t happen with the usual workflow. 🙂

  9. Error Details
    =============
    An error of type E_ERROR was caused in line 101 of the file
    …..plugins/toolset-blocks/vendor/toolset/common-es/php/bootstrap.php. Error message: Uncaught Error: Call to undefined method ToolsetCommonEs\Rest\API::apply_script_data() in /….toolset-blocks/vendor/toolset/common-es/php/bootstrap.php:101
    Stack trace:
    #0 ….wp-includes/class-wp-hook.php(288): {closure}(”)
    #1 ….wp-includes/class-wp-hook.php(312): WP_Hook->apply_filters(NULL, Array)
    #2 ….wp-includes/plugin.php(478): WP_Hook->do_action(Array)
    #3 ….wp-settings.php(523): do_action(‘init’)
    #4 ….wp-config.php(110): require_once(‘/nas/content/li…’)
    #5 ….wp-load.php(37): require_once(‘/nas/content/li…’)
    #6 ….admin.php(34): require_once(‘/nas/content/li…’)
    #7 ….plugins.php(10): require_once(‘/nas/content/li…’)
    #8 {main}
    thrown

    • Hello Suzan, thanks for reporting it. It has to do with the Toolset WooCommerce Views plugin. The patch is on the way. Will keep you posted.

        • Thank you Suzan. A few minute ago I just sent you an email with the link to the new zip. The official patch will be released tomorrow. If you don’t want to wait, please use the one I sent.

  10. Problems holding the different values for Desktop, Tablet and Phone. I tried a Toolset Heading block and tried to do H2 for Desktop, H3 for Tablet and H4 for phone. It just kept changing the values I had entered in the different scenarios. Nice idea but it doesn’t stick? I tried a few other blocks too but same issue. (New Classic view and then Edit loop in Block editor).

    • Hi, I am not sure what’s happening and in order to take a better look, we’ll need to access or duplicate your site probably. Please report that in our support forum so we can help you fox.

    • Ok, now I see that you can’t change the H2 tags etc for device, but you can change the typography settings. That works! However, I notice that (on Single Field Block):

      1. for Style (B, I, U) that if I set Desktop to U-underline, I can’t turn it off for Tablet or Mobile (if it is activated on Desktop).
      2. can’t enter values for Font Weight?
      3. Font Size allows changes by device but the Size eg. Small doesn’t change just the pixel size is changed (so it works but just doesn’t update the Textual size descriptor between devices)

      • Hi, Martin!

        Actually, we put that limitation there on purpose. You see, for SEO purposes it would be a bad thing to have different HTML markups for different screen sizes. Trust me, you don’t want to do that. 🙂

        When it scans sites, Google pays a lot of attention to the markup and sites should actually have the same HTML markup for all screen sizes. On the other hand, it’s perfectly fine and expected that dimensions and spacing of elements change for different screens.

        So, it’s not a bug but something we didn’t allow because it would be bad for your sites.

        • Sounds great! Thanks. (still minor issues with the some of the typography settings as I mentioned but otherwise fantastic)

        • Dario –

          In this case, I assume by “markup” you are referring to B|I|U only, and not to font size/weight? It wasn’t crystal clear to me.

          • Hi, Jeff! Actually, I meant the HTML markup. For example, if you have an H2 heading on a desktop and you want it to be smaller on mobile phones, it wouldn’t be a good idea to change it to an H3 heading. Instead, you leave it as H2 but use the Typography options to change its font size.

            In other words, changes to font sizes, spacing, padding, colors, etc. are all perfectly fine as long as the HTML element stays the same.

  11. How about the header and footer. Formerly Layout allowed us to create headers and footers so easily. Can we do that with Blocks?

    • Hi, Mike! Sorry for missing your comment. For the time being, you can design the content part of your websites using Toolset Blocks and the WordPress Block Editor. Everything else comes from the theme.

      However, this is coming to WordPress and the core team is already working on this feature for the Block Editor. They call it “full site editing”, so if you google that, you will find many articles.

      When this gets into core, you will be able to use blocks, including Toolset Blocks, to design every single part of your site.

  12. Nice work Toolset team! I’m testing it right now.
    One question: how do I set background position on the image block? I’d like to set it fixed.

      • Hi Dario. In fact I meant the background-position css property. For example, what if I want to set the background to fixed?

        • Hi Roberto, this is Amit here, from the Toolset Support team, we’d be happy to help you with this CSS issue, but the best way to be able to do that is by reporting that in our support forum. Can you please do that?

            • Perfect! The best approach is to use already built-in solutions inside Tooslet., and it seems like this is exactly what you have done. If you need anything else please let us know.

  13. I have been using Toolset (“Types/Views”) for several sites for nearly five years. I now need to start a simple site project immediately and want to use Toolset Blocks for it. This new responsive Blocks release sounds great. But, I don’t understand if I need to download Blocks separately or download the latest Views. The Views version I currently have (3.0.2) does support Toolset Blocks.

    So, it seems I do not need to worry about downloading Toolset Blocks – correct?

    What Views version supports this latest Blocks 1.1.1 with responsive support?

    Thanks,
    Jeff
    –––––––

    • You’re correct. Views and Blocks are basically the same plugin. They only expose different GUI by default, which you can change in Toolset->Settings. We created the Blocks version so that people who are building new sites or are new to Toolset don’t need to decide between two workflows and don’t see a complex user interface.

      • Ah, thanks Amir.
        That makes great sense.
        Blocks looks fantastic so far! Nice job. I will be starting a new project tonight using Blocks and I am intrigued and excited.
        I built two sites last year, one with Elementor, and one with Brizy. I much preferred Brizy, but I was missing my Types & Views! And Toolset Forms is soooo much quicker to build a form with all the extras than either of those two others.
        Really looking forward to Toolset Blocks.

        Jeff Safire
        –––––––––

  14. I am starting a new very simple no-frills directory/membership site, and plan to use Toolset Blocks for the first time. My client doesn’t want any fancy stuff at all, for now. So, I am not sure what to use for a “light” theme. I was thinking of using the Toolset Starter Theme, but I see it is now gone. Should I just use the basic WP 2019/2020 theme and modify away, or is there something better (but simple) to start with?

    Thanks,
    Jeff
    ———————

  15. All of the sites I’m designing at the moment don’t use the new Gutenberg blocks editor. I install the Classic Editor and haven’t made the switch yet. Am I better to continue using Views for these websites? I’m guessing that Blocks only works with the new editor running? PS – We will be updating our workflow to use Gutenberg blocks eventually so I’m very excited about your new Block plug-in.

    • Yes, if you’re using TinyMCE you can stay with Views and shortcodes. Give it a try. We were hesitant at first and now we’re super happy with the results.

      For example, today we noticed that on a phone, we should remove the main image on the homepage. This way, the new videos that we added (today) will be move visible. With Toolset Blocks (and Gutenberg) this change took 30 seconds. Would have taken 1/2 day if we had to edit the site’s CSS file, QA and upload it manually.

    • Hi, Joshua! Yes, Toolset Blocks works only inside the new WordPress Block Editor. On the sites where you are still using the Classic Editor it makes sense to stay with Views.

      I suggest creating a test site and trying to build something nice using Toolset Blocks. I am sure you will be pleasantly surprised. And if you need any help, our supporters will be there for you! 🙂

      • Thanks for replying and confirming so quickly, Amir and Dario. Toolset Blocks sounds great so I’ll certainly be giving it a go on a test site. 🙂

Leave a Reply  

Please leave here comments about this page only.
For technical support and feature suggestions, head to our forum. We are waiting there!

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>