Comments 175 Responses

1. What’s the status of Toolset + Divi 4?

   • Hi Ed, Shane has written me in my support ticket, that the next Divi Update solve the incompatibility. The Toolset Developer has tested the beta version of the new Divi update and it works fine. When it comes, we will test it!!!

     • Cool. Thank you!

       • Has somebody tested the current Divi version (4.0.9) with Toolset?

2. Amir, how are we supposed to implement views on pages that have custom templates, that aren’t using the_content(); anymore?

   • The old functionality is not going away. If you already have it working today, there’s no need for you to change your workflow.

3. Absolutely not interesting. It is only curious when Autommatic buries its stillborn Gutenberg. This is the worst experience of my life. I will never use it under any circumstances.

   • The thing is, I don’t think that Gutenberg is going anywhere. WordPress Core devs are pushing it very hard. So, it’s here to stay. So, Toolset is adapting to WordPress, as I don’t think that WordPress would adapt to Toolset.

     • I can’t think of ANY site in which I do not install and activate the Classic builder. Does this mean that in the future Classic Views will start to lose support and features? I don’t see a point where I will ever develop any sites using Gutenberg. It just won’t happen.

     • Either Gutenberg or WordPress with Gutenberg will leave. It is impossible to do everything against the community. And the community did not need another worst page builder. The community needed a simple editor even easier than TinyMCE (an editor like Medium or Ghost). Instead, Autommatic sculpted a golem. And if there wasn’t competition, we could have reconciled, but at the end of 2019 it looks like a shot at ourselves

   • Whole agree with you 100%! Gutenberg doesn’t even remotely come close to allowing the “design” capabilities I need. In fact, if there were no builders (well developed like Elementor or X Theme) I most likely would ditch WordPress altogether.
     When WP + Gutenberg was in its “integration talk about” stage and even in beta, the uproar was defining and Autommatic basically ignored the overwhelming “No” vote from developers.. and still are.

     • Nicole, we added quite a few features to Blocks to allow detailed design. These features are all available in the recent beta. Could you please tell me which design features you need and are missing?

4. Does it means we’ll have a page builder and no more theme builder?
   And if page builder which theme do you advise to be the best?

   • “Theme building” is going into Gutenberg itself very soon. We’ll all get this feature when it’s implemented in Gutenberg and included in WordPress.

     • Ok good. Do you reccomend some theme(s) to be compatibile for the future?
       I actualy use hello elementor theme

       • We are testing a number of themes now that are promoted as “Gutenberg Friendly”. We’ll have results and recommendations to share in a few days.

5. Thanks so much, I was asking myself about using magnificent page builder or stay with gutemberg !

6. I’m pretty gutted if honest…

   Completely understand why you have had to do this guys and this is absolutely no gripe on you as in order to survive, you have to focus this way. I don’t know if I’m in a minority or not but I genuinely wish drag and drop type builders would not be forced upon us. I hate absolutely everything about them and Gutenberg in my own personal eyes is an abomination (but I fully appreciate many would disagree) I own and manage an agency which looks after in the region of 200 WordPress websites and I have yet to have one client (even after much time spent playing with and learning to use Gutenberg) that have a positive thing to say about it and 99.9% of our clients ask us can we please lose it.

   Anyhow, ramble over.

   Good luck with the launch guys and I hope it all goes well for you ! (please keep us anti blocks folk in mind as we have so many intricate sites built using Types and Views I would disastrous for us to lose the current editors / functionality).

   Much Love

   G

   • Thank you for your feedback. Even if you’re not crazy about D&D editing, I suggest that you give the new Blocks a try. The big benefit is that everything is on the GUI and is visual. There’s a lot less to memorize (like shortcode attributes). There’s no need to refer to documentation all the time and it’s a lot easier to edit a design that you did several months ago.

7. What if we use like creating custom views and don’t use Gutenberg (ie Divi or other builders)

   • Yes! I am using the Toolset instead PHP coding and i am writing html, css and js code. I do not need pagebuilders and blocks, because my designs are nonstandard. Frontend coding + Toolset are wonderful opportunities. But if all new features will be implemented only for blocks – it is very sad. Life for the shortcodes!

   • Hi! Yes, no worries, you will still be able to use the classic Views workflow.

8. Sorry but I think that Toolset doing anything with Guttenberg is just a waste of time and money, very foolish. The Guttenberg block editor is awful. Views was never what you would call friendly or polished but if it has anything to do now with any Guttenberg style blocks then my staff, clients and I will have to look at other options for development. I understand the different reasons for not having such a priority on full integration of other “builders” but truly if you look at the install count and momentum of builders such as Elementor, Divi, Beaver, Thrive, then you see what clients are asking for or what other plugin developers are supporting and what people spend time on with learning curves. I just don’t see anyone willing to spend the time and hassle to learn and use a block editor design that not one person I have ever met or talked with likes. Why do you think the 2 of the most popular plugins are “disable Guttenberg” and “Classic Editor” with millions of installs each. Better builder integration would be my choice but clearly you guys don’t see it that way. For me being a 35 year techie I have no problems using Toolset in any environment and dont need page builders but I would tend to argue that most new employees or clients that see the Toolset interface and docs are easily as confused and as intimidated as a newbie using Guttenberg blocks for the first time. Sadly page-builders are with us to stay and are the future of the development masses and millenials so I would put more effort there with good but transparent integration of existing page builders or frameworks.

   • Out of curiosity, have you tried our recent betas with the Block Editor?

   • You say it well. I did try to use Guttenberg today with Toolset blocks. How complicated… Please adapt your blocks to be used as Elementor widgets, it would be so much easier then having to work with Guttenberg

9. So I stopped using Toolset after you had decided to use other themes. I was a big fan of only Toolset with your Starter Theme. It was fast, stable and had the best page speed scores.

   Think about a closed beta or similar. I will not buy something again, which may change completely afterwards. That was a big disappointment.

   • What features did you use in our Starter theme that are missing in other themes that we recommend today?

   • Barnabas have you tried Oxygen Builder with Toolset?

10. Hi, I am little bit confused. I tried the Toolset Blocks, then it dissapeared and appear again as Views Beta, then Beta 2 with Blocks Archives. Everything is cool.

    BUT! How we manage our views and other things with Bootstrap 4 grids now? In gutenberg block called classic editor, or toolset block fields and text? But why! Old way to build archives and views was good enough. Now it is a bit confusing to make website grids completely with Bootstrap. Or with gutenberg?

    Maybe there should be a toolset block called Bootstrap 4.0 grid. Then everything will change. We need to use the BS4 if we want to make fully responsive designs and create Mobile first layouts. Gutenberg Grid is so hard to make responsive as we need because of lack of CSS helpers like col-1 col-md-3 col-lg-6 etc…

    And for novadays it is a must to build websites at 1st for mobile device and then for Computers. So how will you manage the work with grids?

    • In order to simplify things, we intentionally separated between the existing “Toolset Views” and the new “Toolset Blocks”. If you want to remain with the old workflow, just keep installing the Views plugin and don’t switch to use the new Blocks.

11. I am in the middle of developing a site with Toolset+Avada. The more I use Toolset the more I love it, the opposite for Avada. Would it make sense to switch to Blocks+Guthemberg+a G friendly theme ? can you develop Bootstrap sites with Guthemberg ? what would happen to all my existing views in Blocks ? will they be compatible or need recreating ?

    • Yes, you can use Bootstrap with Gutenberg. Toolset has a setting that allows you to load the Bootstrap CSS (loads BS4). We are not in the final stages of a comprehensive review for “Gutenberg friendly” themes. We’ll publish our results to make it easier for clients to pick themes that will work great with the new Blocks workflow.

12. This is great news, really loving Gutenberg and being able to use Toolset generated blocks is going to be a game changer. Well done!

    • Thanks David. The production release will be pretty close to the last beta that we’ve released. Have you tried it?

      • Hi Amir unfortunately not yet, looking forward to trying it out.

13. Can you still use Views the old way after blocks are implemented

14. I see you can use it the old way…sorry

15. All of my new sites are either Divi or Gutenberg, but I have a few legacy sites that have not yet converted to either. Will this break my views on those sites still using the Classic editor?

    • Not at all. Part of the purpose in splitting between Views and Blocks is to make sure that nothing changes in sites that you build with the existing shortcodes workflow.

16. I have disabled Gutenberg on every site I develop, from the time that WordPress made their unfortunate decision to create it. Needless to say, I’m horrified by the idea of rebranding Toolset Views into Toolset Blocks.

    Not a month goes by without my recommending Toolset to my clients or on Facebook, and I’ve always felt you have the best set of plugins that are currently available to enable a powerful and diverse set of features. I knew you were maintaining compatibility with blocks, and I thought of that as representative of what a flexible development team you have. I never envisioned you making the block stuff into the primary method of implementation…

    To say I’m surprised and disappointed would be a gross understatement. But I suppose I’ll try it out on a new site, because I’m not willing to give up on you.

    • Hi @ChuckGregory – I too installed the Classic Editor on all sites before WP 5. Over the past year Gutenberg has gotten better. It is has a lot of quirks, but has gotten to the point where I prefer it for longer content. So I think it is worth trying Gutenberg again, but give yourself a little time to figure it out.

17. Will you still keep the old “Toolset Views” functionality after the new ‘Toolset Blocks’is released ?

    We have sites that are not using the Gutenburg editor, and the old “Toolset Views” is used a lot to query and display CPT contents on the site. After the update will the new ‘Toolset Blocks’ mess up the current ‘Toolset Views’ that I’ve created?

    • Yes. We’ll keep it for a very long time. Many clients have built sites using shortcodes and we’re not going to ask them to edit old sites for the new workflow.

      • Very long time? Is that like 1 year? 5 years? I ask because I have perhaps 30 sites built the old way, so if I ever need to transition I will need a long time prepare and rebuild things.

        • Like I wrote, we have no plans at all to discontinue Views based on shortcodes. We know that many websites, including our own are using it. Like we don’t want to redo our own websites, we will not ask our clients to do the same. If we ever consider making any of it obsolete, it will be for reasons beyond our control (like WordPress deprecating the entire shortcodes mechanism). We have no intention of doing such a change on our own initiative. Does this help?

          • Yep, thanks.

18. This is a very impressive business move which secures your commitment to the WP core direction. It provides opportunities for freelancers and solopreneurs to better leverage your tools and development team to scale their business. On a personal note, it fits perfectly in the direction I am taking with my business.

    I have a couple questions regarding your recommendations for Gutenberg related plugins, or what could be better described as block addons. For example, you have recommended Kadence Blocks for adding columns in one training video.
    Do you see your recommendations of additional block addons as temporary requirements as you expand Toolset Blocks?

    For now, you offer a raw code block that you can add HTML that leverages Toolset support of Bootstrap 4. Do you have plans to further leverage Bootstrap in Toolset Blocks for the purpose of creating custom blocks without block addons (plugins)?

    • Hi, Anthony! That’s a great question. We are still investigating this because there are improvements coming to the Block Editor in core, which could prove helpful for everyone using it. An example would be the ability to set a custom column width with the native Columns block. I don’t think we will (or need to) supplement every type of advanced block out there, but we understand the importance of certain features that are simply needed to create beautiful websites.

      So, in short, if we see there are missing blocks and features that are not coming natively to the Block Editor soon, we will do our best to provide them.

      That being said, are there any specific features/blocks you are missing?

19. As elementor is the 1st page builder in use, i think it should work with total integration with it…

    • Agreed!

      • In my point of view – toolset is betting on the wrong horse… by now elementor is more future than gutenberg….

        • Elementor is just another (very good) WordPress product. Gutenberg IS WordPress, and with the new version this will be more evident…

          • Totally agree! Gutenberg will be used by millions of people all over the world. It is native in WordPress, it is constantly improved. Well done Toolset for the smart move but like others said we also need Toolset Views to stay fir at least 3/5 years so we can gradually convert existing sites. Hope there will be an easy way to do this job.

            • Thanks for the encouraging words. Yes, the current workflow is here to stay and the only reason we see why this may ever go away is if WordPress itself will remove the shortcodes mechanism. There are no plans for this on WordPress and definitely not on our side.

20. Can you provide shortcode access to layouts built with Toolset Blocks so that we can take that shortcode and place it into pages built with builders like Divi? Will a Toolset Block layout display properly if placed inside a Divi page this way?

    For example, let’s say I have a car sales website. I want to add a Toolset Blocks list/grid of featured cars into an otherwise static page built with Divi.

    Please respond promptly, I need to start a project ASAP and am trying to figure out which path to take.

    • Hi Peter,

      I can answer the question regarding blocks and shortcodes and you will be happy to hear that at this point in time things are quite versatile. I have done a fair bit of experimentation with the new block editor/Gutenberg in Divi. As long as the block library is not deactivated (the Disable Gutenberg plugin is the only plugin I know of that can do the disabling) anything you create with the block editor will render in you website on the front end. Experimentally you can actually take the raw html of the content built in the block editor and paste it into the text block (in the text/html tab) of a Divi text module on another page and it will render as was intended when created in blocks. Of course to edit and amend that content you would need to temporarily copy the raw html back to a page using the block editor in html view, hence the reason I said experimental.

      This would extend to a view that you made with blocks that was then added trough the shortcode for it in a Divi text module.

      To clarify the new approach is to build, with blocks, directly on the page where you want it to appear and you can build a grid for that with or without Bootstrap, if I am correct. Inversely you can still go into the views listings and make a view independent of a page as you are used to. You can set up the view in the usual way with pure html/css/js in the template loop or select to build it with either blocks or you chosen builder integration.

      Some additional information. In Divi 4 with the theme builder templates you can set up the template with the new post content module and that will take any block layout you configure on the backend editing of a post/page and render it into the Divi generated template on the front end.

      Some caveats. Elegant Themes still has a bit more work to do regarding full compatibility with the new block editor. They still haven’t implemented align-wide and fullwidth for the many blocks that use this feature. This suggests a tardiness on their part and validates much of the criticism that Amir has mentioned and the reason why Toolset is going the block route for layouts. The new theme builder in Divi 4 hasn’t been fully implemented to pick up custom fields created by third party plugins. And in addition to this a proper rendered preview of sample content based on a user selected post as other builders have succeeded in doing. Advanced Custom Fields have been given priority and do work now. Toolset custom fields, so I have been told will get attention soon.

      To this end I do think that Elegant Themes need to stand back now and address these, and other usability issues not related to Toolset, before creating other bells and whistles features.

      I was kind of hoping that Divi 4 would be a completely new page builder framework, looking much like Divi 3, but built on the block editor foundation, for the sake of computability. You wouldn’t update old Divi 3 sites. Just use it on new sites.

21. Great announcement. To clarify we can continue to use views as normal with manual html, css, and shortcodes? And legacy websites will be unaffected by the new blocks.?

    • Yes, exactly. 🙂

22. With Toolset Blocks, how do we make reusable “views”? With the old way of making views, a view was essentially a standalone piece of code waiting to be inserted into a page… at least that’s how I perceived it. You could of course insert a view into multiple pages if you want and updating that one view would update multiple pages.

    Now from what I’ve seen in the Toolset Blocks beta videos, it looks like “views” are built directly into the page where you want that info. Does this mean you have to repeatedly build views on different pages even if those views do the same thing? How are views made with Toolset Blocks reusable? Clarification would be appreciated.

    • Will Toolset get a Toolset Block Library where we can design and store Toolset Block layouts so they can be reused on many pages with a single (Library)version needed to be edited to update all other occurrences? These Toolset Block Library layouts should be able to be inserted into both Gutenberg pages as well as builder pages like Divi via shortcodes.

      • We’re still not sure how this will work, because it’s “work in progress” in WordPress. There’s a lot of talk about different kinds of block libraries in WordPress Core.

        For the next release, we will not be working on block libraries. Our target major features include:

        1. More “designer friendly” features, including reusable styling
        2. Block-based Views for users and taxonomy
        3. Nested block-based Views

23. I am so glad that I have been long associated with Toolset, since 2012.

    In all these years, so many plugins came in and vanished, very few managed to make its way so long and Toolset is one of them.

    With consistent development and thinking from the end-users point of view, I now see even more potential for the non-coders to develop beautiful dynamic websites.

    I would love to continue building dynamic websites using Toolset Blocks.

    Hats off to the entire team who have been working hard to deliver one of the best experiences to their users.

    • Thanks a lot, Alok!

24. When I think of all the training, branding and hand-holding Toolset has done over the last decade, and all the users, the sites developed … to now, throw them all under the bus and ‘force’ them to develop and work the way ‘you’ want them to … sounds ridiculous. I’d venture more than 50% of people hate G. It should be a plugin option.

    From a marketing standpoint, why do you want 50% of your users now hating Toolset (whatever percent)? Users above have asked some very serious questions of which appear to be ignored. I hope that’s too isn’t the new norm.

    Can users continue using and developing new sites with old Types and Views, as is … no G, no blocks, no terminology changes?

    To me, it sounds like you have two products: Types-Views-Layout plugins AND Types-Blocks plugins? You certainly have the brain-power and personnel to maintain the two options you’ve created.

    In the marketing world, that’s your job. That’s what providing good customer service is. To say, it’s easier for ‘you’ to do it this way, sounds like developers have more influence over marketing and customer service. You should NEVER make things easier for you, at the expense of your THOUSANDS of your existing users/sites.

    • Hi! Actually, yes, you will be able to continue using Views and all existing sites will work perfectly fine. Nothing is going away and we will not force you to use blocks if you don’t want to. But we would certainly recommend at least trying. 🙂

25. Brilliant!

    Thanks for the Gutenberg integration! 🙂 As a web developer, while I’m good with views, having gutenberg blocks opens many possibilities. Especially with so many good Gutenberg add-ons available in the market now

    Can’t wait for your next development

    • Thank you for your support!

26. Hmm, I saw that as something good when you released the Toolset Block plugin… And I’ve tried to use it, but always revert back to the classic editor, as there are always things that I try to do (or edit) that is simply not possible in Toolset Blocks (or the Beta version of Views)…

    So, from what I understand, we will be able to still use that editor in the settings (will just not be the default)… I hope so…

    And I don’t understand that you mention that Views becomes Toolset Blocks, and then that Views will still be updated… If it is renamed, it’s not a separate product… so, how can you update both…?

    Personnally, I would have liked you to keep things separated, as you did when you released the Toolset Blocks plugin… Why not give us the choice by keeping it that way? The only disadvantage is that people who wanted to have Blocks had to install another plugin… not that big of a deal… I don’t think the product is for now mature enough to replace completely Views…

    Often I had to go into code and it messes everything when we do so in Blocks/Gutenberg, so I was switching back to the classic editor (for Views)… Also, you mention other page builders… It’s going to be complex to keep the “old” Views…

    Again, I would really go with the first workflow: KEEP Views, and have a separate Toolset Blocks plugin for those wanting to use it with Blocks… WHY NOT??

    • That’s correct. You can use the old interface. It’s not going anywhere.

      We rebranded Views plugin to Blocks, to emphasize the new features and workflow. The new Blocks plugin will offer, by default, the Block Editor workflow. The old Views plugin remains as it is today with the shortcodes editing. It will remain and will continue to receive maintenance updates (and some features that are not “block related”).

      • Ok, so, if I understand well:
        – Views will stay Views (i.e. we can download Views and it will still be maintained and updated);
        – Toolset Blocks replaces the “old” Toolset Blocks plugin…

        THE difference is that previously, the “Toolset Blocks” required that you install Views first, but with the new one, it “replaces” in the sense that you can install only that (i.e. Views is integrated in it)…

        Is that it?

        • Yes. That’s right. So nothing changes to your workflow for sites that use Views and Layouts and we continue to maintain both plugins.

27. Great decision, can’t wait! I’m actually surprised at the haters on gutenberg still. Been building custom blocks for designers for a while now and the sites we are now able to create the clients are enjoying the process of the Gutenberg editor, it actually makes me laugh when I look back at how bad the standard tinymce was. Client friendly sites CAN be created with Gutenberg now and with the next WP release (mid Nov) filling in a lot of missing features it’s going to move forward. The door is still wide open however for a UI block creator. ACF blocks work great but having to switch between preview and edit view is a client pain point. Oxygen’s Block builder has by far the best user mode, however the block builder can’t be used without using oxygen for your full site. I highly recommend really focusing on the client experience after handing off the site from development. whether that means flagging which aspects of a block can only be edited by an admin account or something, so we can have a dynamic block but a user can override say the background image used on said block.

    • Hi Nick,

      Yes I agree, the new block editor is a funny business. I found I had to keep going back to it and work hard at getting in tune with the way it worked, and research workarounds to replace old workflows. I am at the stage now where nearly everything is addressed.

      I recently build my first block based site, which was simple and didn’t require any Toolset features. I was happily surprised by how good the results were. In terms of how easy it would be for clients to achieve the same design sensibilities (I did hack the base theme quite a bit) I am not sure? But for me I was happy enough.

      In light of that and, how often I see cases where clients initially want to take on running a site but then either get cold feet or, mess things up, I would say that there is always some level of cognitive load that is a barrier for many people tackling a site, whether it be WordPress or SquareSpace. So I concur locking down the UI as much as possible to give client users as frictionless experience as possible is paramount. The tools are there to do this: Toolset Access or Divi Role Editor.

      With Types, when you set up a new custom post type, you can control and customise the backend editor to your liking. In some instance where I only need a small number of custom fields for simple date entry I will often remove the default TinyMCE text area.

      Doing this though will not let you load the block editor as it is engineered to default to the classic editor if the backend isn’t configured to conform to block editor requirements. You don’t even need Classic Editor plugin installed. This just happens.

      To get around this I made a very simple plugin (No UI fir settings) that I can use to selectively remove the block editor area from certain custom post types and move the custom field metaboxes up the screen for data entry. It just uses css to hide the block editor and adds a nice light grey around the metaboxes for clarity. This for me is a solution where I want users to just fill in fields and not start messing with blocks; the design on the front end is handled automatically by pre-made templates.

      The last hold out at the moment is WooCommerce which is yet to blockify for single products and not default to the classic look.

28. Great news, i thik i’s a good idea to make this change!

29. I start to wonder what kind of ‘developer’ Toolset is targeted at. I’m guessing most Toolset users develop for others? Shouldn’t then a basic understanding of web technologies exist, or am I being old-fashioned?

    I’d like to consider myself an Amateur or Advance-amateur developer; I can write CSS and HTML but have used the likes of Toolset to handle PHP and Bootstrap for JS. I never got into Page Builders as Layouts and the other plugins did all that for you. Perhaps Toolset could invest more into promoting how to use its product and education, rather than all that development time going into short-lived associations. The videos are a good start and the shortcode reference pages are extremely useful.

    I still use the old wordflow, and one of the main reasons is that with Layouts, I do not need a theme. Or, more precisely, I can create a theme with just a few files; header.php, footer.php, functions.php, style.css and index.php. That last file only really needs one line of code: the_ddlayout();. With that, Layouts becomes the theme and I am not locked into yet another supplier and the possibility of sites breaking with new releases. I think that’s happening with Divi at the moment? I am really hoping that I’ll be able to replicate this kind of almost-no-theme page design functionality in a future Toolset release that uses Gutenberg Views/Blocks and a decent Bootstrap-like grid system.

    Recently I’ve been playing with Google AMP (Toolset does not play nicely with AMP), however I can create content-only pages like a single map (no header or footer) using the old Layouts workflow in a non-AMP Toolset site, and amp-include them in AMP sites. I don’t think you’ll be able to do this with the new workflow using a theme.

    Gutenberg is getting better and I’m hoping to transition to the new workflow at some stage, however the old way still gives better control and flexibility over responsive layouts for the moment even if it requires a bit of basic CSS and HTML. Sure Gutenberg appears easier with all the switches and toggles but you soon experience the limitations especially if you’re familiar with the basics of HTML and CSS. I’m a little worried that the entire ecosystem is heading toward the Beginner end of the spectrum that boxes you into what you can and cannot do.

    I find myself unwilling to compromise and be ‘dumbed down’ and am considering learning PHP. After my AMP investigations I have been exposed to other development tools beyond WordPress and Toolset that target the middle-ground ‘developer’, and even more basic tools like Atomic Blocks which start to approach Toolset from the Beginner end and are AMP compliant. I’d be worried about the competition coming from that end as you approach them. Even reading this thread I’m being exposed to Oxygen and just saw that I still have an ACF license that I last used in 2015 after switching to Toolset. All this looking around must highlight the concerns existing customers have.

    Depending on the kind of sites you’re producing, I’ve even considered going back to more static versions… even took a look at what Dreamweaver was up to after having last used it at the turn of the century! However, let’s see what happens in the next few months. My wish – replicate the Layouts almost-no-theme required functionality. I’m hoping Gutenberg will make that happen.

    • The old workflows remain. This was part of the subject of this post. We’re offering a new workflow and we gave it a new name, to help distinguish between the two.

30. Sheesh, I had to stop reading all the negative comments.

    I am excited about this news. Kudos on the pivot/rebrand and well-written announcement!

    ~Gutenberg~ The block editor is a huge improvement over shortcode soup. Toolset’s audience/customer base is site builders, not “regular” WP users, and Gutenberg has been very well received by regular, day-to-day users. More advanced users probably like the change less-so because they know how to do something one way and expect it that same way, which is why keeping Views is smart for a while (year or three?), but Blocks is the future and custom development can be done around whatever edge cases it may not natively support (yet), so I’m really happy about this overall.

    Thanks for keeping Toolset current and living up to its name 🙂

    • Thank you for your support. We will keep the backward compatibility with shortcodes for a very long time. There are tens of thousands of websites (including our) already built with shortcodes and we will not ask our clients to update them to Blocks.

      New features will go more into Blocks, but the old shortcodes will continue working.

31. I created a view using the new Views/blocks editor in a content template, using a custom image, caption and rating (really like the star rating block) in a RFG (repeatable fields group). It worked great to create a bootstrap 4 grid and adding some bootstrap card css. However, I had difficulty with adding the lightbox effect. I understand that the Toolbox built-in lightbox works easily with repeating image fields but that is not my case with the RFG. Although the toolset image block for my custom image field (in the RFG) showed a link option with lightbox as a choice, that did not work (I was surprised to see the option actually since I assumed that the built-in Toolbox lightbox was for repeating image fields only).

    All in all, being a non-PHP developer, I enjoy using the new blocks editor. I find it a bit tricky dragging blocks around to move them to the right container (maybe that is still being fine-tuned? or maybe that is a Gutenberg issue), and also selecting blocks could be a bit easier I think to find and click on them (maybe bigger labels for containers, loops etc), but if we can have all the power of the current Views which I have used for 5 years in the new blocks approach I am definitely a fan. For example, I think integrating light boxes (I enqueued baguetteBox easily in the classic editor) should be easier in the new blocks. (This may simply be a matter of having better documentation, I’m not sure…).

    Also as I mentioned in another post, an ability to ‘collapse’ a block in the editor would be great as some of them get quite big and once they are ‘working’ I kind of like them ‘out of my way’ but still in the right spot if you see what I mean. (take a look at how Stacks (similar to blocks) work in Rapidweaver – the blocks are really easy to move around, collapse, hide, even put ‘notes’ blocks on the page to document what is happening. Kind of a nice blend of classic with block editing – I suppose you could allow a note on each block as well…)

    Many thanks for a fantastic product which continues to strive to support the WordPress platform. I moved from Drupal to WordPress because of Toolset. It’s been a great ride the last 5 years!

    • Here is a reference to a video about stacks blocks in Rapidweaver: https://www.youtube.com/watch?v=Fq7i0qS7npk. – it seems to be a bit more polished to move blocks around and also see the labels and ‘collapse’ (look at 1:40 for a few seconds to get a feel for it…). Although I realize this may be more about Gutenberg than Toolset – I’m not quite sure where one product stops and the other begins…

    • Thank you for your support and understanding. We are doing our absolute very best to make Toolset useful and convenient.

      I agree that the Gutenberg interface takes getting used to. There’s plenty to improve, but it gets better with every release of Gutenberg. If you compare Gutenberg today to Gutenberg 12 months back, you’ll see that it improves nicely. Right now, it’s not perfect, but it’s very usable.

      Collapsible sections are also a feature for Gutenberg. They have many features on their plate, so we don’t know when specific features will arrive.

      Could you please create a support ticket about integrating with Lightbox? I’m sure that our supporters can help you find a solution.

      • I logged a ticket about integrating with Lightbox and Minesh suggested sticking with the classic views editor. He said that is why it is being kept around is to handle things like this (Lightbox for RFG images)? I noticed the same problem as well that peterR-3 below on Nov 11th did in his point 8 about using the Lightbox link on an image block only shows the first image in an RFG gallery. I assumed it was not supposed to work with RFG images but maybe it’s a bug? If not a bug, perhaps a note in the help text of the image block to say it is not meant for RFG’s would be helpful. Many thanks.

        • Looks like we’re a bit behind on training for our supporters. Can you paste here the link to the support ticket? I’ll move it to a developer who worked on this feature. The whole purpose of the beta is to get feedback from clients and see what we’re missing. Not to inform clients that it’s not possible.

          • https://toolset.com/forums/topic/creating-gallery-with-lightbox-in-new-views-beta-editor-using-rfg/ – thanks Amir, really appreciate all the work the dev team is doing here.

            • Thanks. Christian who’s developing this functionality will see what’s the best way to accomplish what you need and join the thread.

32. Good Lord, I HATE Blocks. HATE HATE HATE. Yeah I’m a 8R, so sue me. Amir, would you be so kind as to PLEASE CONFIRM (there are comments above which I find hard to decipher in total) that we don’t NEED to use Blocks. I’m fine with creating CSS and HTML – you know, the, erm, basics.

    • LOL, “H8R.”

    • Hi! You don’t need to use blocks if you don’t want to, you can continue using Views as you did so far. Thanks!

33. I use Toolset along with Elementor. I love Elementor but recently took a long hard look at the WAY I use Toolset and Elementor together.
    For the most part, I’ve used Elementor for my header, footer, and navigation. Almost everything else is done with Toolset & Bootstrap 4.

    The Elementor and Toolset combo isn’t all sunshine and roses either. Having to set an Elementor template as the default for everything and having my site break if Toolset is set to the default for a template or archive is so lame. Using a Toolset Form with Elementor is also a pain in the arse.

    I’m still not going to jump into Gutenberg with both feet right now, but that time is getting closer. Once everything comes together, I can totally see myself making the switch to a basic Bootstrap 4 theme, Gutenberg, and Toolset.

34. Now, this really sucks. Huge disappointment. If I remember correctly, the Blocks thing was supposed to remain separated from Views – optional. I gave several chances to Gutenberg, the concept might seem interesting, but doing simple things and creating posts takes 3-5 times longer in Gutenberg. It might be great for some people, but I simply don’t need it and I don’t like it.

    The last thing that I need is Gutenberg-related bloat in Views… and new potential compatibility issues. I don’t need “design features” in Views, I have CSS for “design features”. Views was excellent the way it was. For crying out loud, facepalm.

    • Can you explain the problem? This blog post describes how we keep the old Views, with the shortcodes editing, and continue to release maintenance updates. How does this not support your existing workflow?

    • Hi Thomas,

      Just a heads up, According to Matthew Mullenweg Gutenberg is WordPress moving forward. Eventually, it will completely transition over and the classic editor won’t be an option.

      Block editing features will also be integrated into the Header, Footer, and Archives.

      Reference: https://ma.tt/2018/12/state-of-the-word-2018/
      (50min into the video)

35. I prefer sticking with my usual workflow, and just popping the views shortcode in whatever builder my client wants. Will I still be able to do so?

    • Yes, definitely.

36. WE just purchased Toolset two days ago and we were starting to implement the old Views/Layouts into our new sites. Should we put a stop to this now – or continue development?

    The video preview of the new Blocks plugin looks great, but I don’t want to continue to develop in the old Views plugin (and with Layouts) if this new Blocks plugin is on the way and will make all this obsolete. This will delay our production which is not good, but if using the new Blocks is the future, then we will have to work this delay into our plan.

    How long before the new Blocks is available? Can we use a beta version now until it is released?

37. Also wanted to ask, will this new Blocks plugin allow us to still construct/design/create custom WP archive pages (eg. archive.php or category.php) containing Custom Types and Custom Fields?

    • The new Blocks allows to build Views, templates and archives. For new designs, you can already use it. You can access this via the recent Views beta:
      https://toolset.com/2019/10/design-great-archive-pages-using-the-new-views-beta/

      It would be a good idea to use the new workflow. By the time you’re done building the site, this version will be in production and no longer in beta.

      • Thank you Amir for your prompt reply. I am excited for our new relationship with Toolset. I also wanted to give you and Toolset a big shout out. I have been php coding our sites ever since using WP and my themes were always custom. Our flagship sites have been around since 1998 (when I coded them statically by hand using HTML) and I understand change is hard. All this backlash against Gutenberg is understandable to a degree, but I felt the same way when WP brought in the theme editor front end stuff as well. I’ve never liked shortcodes per se. I applaud you and your team for recognizing that the future includes a stable version of Gutenberg and for adapting your product to be easier to use in this case. Please keep up the good work and the good support – and please always help us keep our sites as fast loading as possible. Cheers.

        • Thanks 🙂

38. There’s A LOT of unanswered questions here and I hope someone gets to them.
    My question is…if you don’t recommend using layouts will we still be able to assign a design (layout) or content template to a CPT?
    This is essential and I’m assuming you haven’t messed with this critical feature. How will this be handled going forward?
    I also have absolutely NO interest in Guttenberg. I use Beaver Builder…far superior.
    Please reply to more questions…

    • We haven’t disabled the existing workflow and the existing plugins and we’re not going to. You can continue maintaining old sites AND building new sites with Layouts and Views.

      The new Blocks plugin doesn’t work with Layouts because the two plugins compete over the same things. You don’t have to use it.

39. Hi Amir, When do you guys plan to release new version about Woocommerce production? I am waiting for the new release about Woocommerce to build my new project. Thanks!

    • Hi, Jeffrey! If you are referring to blocks version, the upcoming production release of Toolset Blocks will have the basic WooCommerce blocks. They will be quite simple in this release, but we will definitely expand them more and soon.

40. HI Amir – I build plugins are for a living and I understand the logic of having to choose your battles and deciding to support Gutenberg, as far I see and based on the WordPress road map will is not going anywhere and will improve overtime. That being said Toolset should provide a basic Gutenberg starter theme that works well with your solutions, I think this is inevitability as you will have more control(when WP add menu nav blocks, widget blocks etc you can easily update the theme for customers) and it will prevent folks like me from wasting time searching and testing other themes that maybe bloated in most of the cases.

41. Will you maintain the compatiblity between Divi and Toolset?

    • Yes, we’re doing our best. ET test already received a list of the critical issues between Toolset and Divi4 and they are going to include fixes for them in their upcoming version (we were told). Anything that we can handle on our side, we do without delay.

42. Seeing all the efforts you must have spent to piggyback on multiple page builders and the so well loved Gutenberg, I wonder if it wouldn’t have been more efficient to invest into just improving and extending the building of search forms, views and content templates?

    • We’re very happy with the result of our Gutenberg integration. From your testing of the last beta, what are you missing or finding inconvenient?

43. Hi Amir,

    I think this is a fantastic development and a step in the right direction. With this development it makes building light, fast, dynamic Toolset based sites a possibility without having to sacrifice design or use a page builder.

    My questions are as follows:
    1. Is it possible to migrate our existing Views to the new Toolset Blocks? If so what is the easiest way to do this?
    2. Is it possible to use Views and Blocks together within the same site or will it cause a conflict.
    3. Your blog post mentions that we can maintain our existing workflows but I imagine if Toolset is investing in this new Blocks plugin the idea is to eventually deprecate Views? If this is the case do you have a timeline of when this would happen?
    4. Will new features and updates continue to be applied to Views? I ask this to determine if a significant investment of time should be invested in migrating our existing views from the old views to the new Toolset Blocks.

    I’m looking forward to jumping in and working with Toolset Blocks!

    Thanks,
    Andrew

    • 1. It’s really difficult to migrate existing Views to blocks. When we all created Views until now, we used shortcodes. These shortcodes don’t map into blocks in any visual way. On our sites, we are leaving existing functionality with the old Views and we’re using Blocks for new stuff. When we do “migrate” existing Views and archives, we actually rebuild them.

      2. Yes, that’s possible. You’ll be able to enable the new functionality in the Views plugin and selectively choose which elements to build with shortcodes and which with Blocks. We branched Blocks into a separate plugin, but this is more for branding and communication purposes. You can still access Blocks from Views plugin.

      3. There are so many sites (including our own) using shortcodes that I don’t see us ever removing the functionality. More realistically would be to keep the old code but add new features to the Blocks part.

      4. Depends on the features. Features that are entirely backend will appear for both old and new functionality, as they are using the same code. Features that have anything to do with the GUI will most likely go to the new Blocks only.

      There’s really no point in migrating old Views. I suggest to rebuild Views, templates and archives only when it’s time for a redesign. Then, it’s just a lot easier to re-implement with Blocks.

      I hope that this makes sense.

      • Your #2 above: Do we have the choice of ‘not’ downloading the Blocks plugin when upgrading Types & Views?

        • By default, when you download Views, you will not have the Blocks functionality enabled.

44. Hello Amir,

    I understand that you focus on Gutenberg as WP is evolving that way…. and read several times you can still use the old views… / old way…. and that word “old” is already giving me goose bumps… Does this mean from now on, only the Toolset Block will be enriched? The development of Toolset Views died with the birth of Toolset Block?

    RIP Views… or do you still add functionality to the “old” way / views too?

    I’m building very advanced websites with the combination of Divi and Toolset. Full blown sector and market information portals. Multinational Job opportunity sites for Employer branding…
    Using toolset shortcodes to populate Divi Templates… so the back-end users only need to fill out simple content fields (title, content, custom fields, images etc)…and everything will look consistently on the front-end…

    It would be a huge loss for the more custom project developers amongst us…

    • Like I said, the existing functionality in Views is not going anywhere. I’ll write when there are new features that we add to Blocks or to the shortcodes version.

      • Sounds great Amir, I was just afraid that there would not be any continued development on views … such as new features.

        Will there be developed also a blocks content custom field in types?

        As from what I know when using Gutenburg and a custom wysiwyg field… that will be displayed in gutenberg as an old fashioned tinymce fields.

        • Hi Herre,
          If you use blocks in your post body/content and then you display the content in your Content Template/Archive/Views using the Single Filed block set up to point to Standard Field -> Post Content, it will work. I wonder why one would need more than one “field” like this? I’d need to better understand your use case. Can you elaborate, please?

          As from what I know when using Gutenburg and a custom wysiwyg field… that will be displayed in gutenberg as an old fashioned tinymce fields.

          Yes, that’s correct. To handle this in Toolset blocks you can use the Fields and Text block and insert your WYSIWYG-based field.

          • Hi Agnes,
            This is due to the fact we work for a lot of websites with fully defined page structure. Thats also why i am not that fond of Gutenberg, but i also know that if this will be the new standard i need to go with the flow.

            For example we do create a lot of platforms where the page/post structure needs to be pre-defined e.g.:

            Header image
            Title
            Content block 1
            Image 1 image 2
            Content block 2
            download 1
            optional CTA …

            Above is just a simple example i just could come up with.
            At this moment, i even rather use WYSIWYG or even plain multiple lines / text fields (depending on the type of page / post). So at this moment that works out of the box with toolset and Gutenberg already (turning of the content part for a port type i can add 2 text editors). But in the nea2 future who knows content block 1 & 2 could be Gutenberg, offering the users a new way of writing their content.

            It’s just a question for me also to get into a new flow of working… i’m one of those guys who stayed away from Gutenberg because of using a builder driven framework already. I simply think its confusing for our users to understand 2 different types of builders… so i’m more trying to define a new direction… stepping aboard on the gutenberg train or not etc.

            So thats why i was wondering if there will be an Gutenberg content field type in the future too… i still a lost soul in the world of making the most suitable choice that will work for out type of projects and users.

45. As a Lifetime User, this is a welcome move. We have increasingly become frustrated with the integration of Toolset and Elementor, finding that we had to patch with plugin after plugin to accomplish the dynamic capabilities of Toolset through Elementor’s front end. Though Gutenberg is not nearly as robust as Elementor or Beaver Builder with regard to design features, we honestly only use a small fraction of all their bells and whistles anyway, and find most of their offering superfluous and simply window dressing. The real power and capabilities of a forward thinking website come from Toolset … not by making graphics rotate and spin. Looking forward to the this new direction and shedding any and all dependence on other page builders … which seem like temporary solutions at best. I do think GeneratePress will be one of the Themes we stick with. StudioPress has also been good for us.

    Other Theme suggestions?

    Another question: We are seeing that the Kadence plugin will be needed for now to achieve some styling and design elements, especially when it comes to column counts and widths. Unfortunately there is no integration between Kadence and Toolset, from what we can tell. Do you see Toolset Blocks/Views adopting most of what Kadence currently offers or will you wait for Gutenberg to catch up?

    • This is basically our reason behind this massive development. We want to offer the full power of Toolset with a visual builder.

      We’re reviewing a number of themes now and will have a nice set of recommendations for “best Gutenberg-ready themes”. This is coming very soon.

    • I didn’t notice the 2nd part of your question. Toolset should work find with Kadence columns. I heard about some issues, but these should all be solvable. Gutenberg’s columns are improving, but the whole ideas of using blocks is that it’s all completely compatible “out of the box”. I’ll check with our compatibility team what they know about conflicts with Kadence CSS or JS.

      • Thanks Amir. Something I noticed as we work with 3.0 is it would be nice to assign a template to specific pages or posts, not just all of them. This is something that seems to be rather common now amongst most page builders where I can identify which particular pages/posts should and should not have a template applied.

        • This is doable today. In the post editor, you can choose which template this post uses.

46. This is a welcome development for me and I should start testing it right away.
    BTW, where’s the link to download the “Toolset Blocks” plugin? My account is only showing the old Toolset Views.

    • Yes, we haven’t made the naming split yet. Until we release the production version, please go to Downloads, switch to Betas and download Views beta. This now includes the Blocks functionality.

47. I am really worried about flexibility offered by Toolset Views to manipulate are going to disappear with this change. We will stuck with Blocks default capability alone. You were supposed to incorporate new technologies. Not to discard the old one.

    • While I’m kind of excited with the focus moved to blocks, I share the worry about limited capabilities / flexibility with Blocks compared to regular views.

      Above is confirmed that converting a regular view to a block view is not possible. Is it possible the other way around? Then a view can be build initially in blocks, to convert it later to a regular view if custom code is needed that’s not possible with blocks. Or would custom code have to be added using the gutenberg code editor?

      I’m really worried to build a view using blocks to meet its limits at some point and having to rebuild the whole thing using a regular view.

      Amir, can you clarify this please?

      • The other way around isn’t possible as well. Once you build a View with Blocks, it doesn’t map 1:1 to shortcodes. The reason is, Blocks already have a great number of visual attributes that shortcodes don’t have. You probably noticed in our betas that there is a huge list of styling options for Blocks. There features don’t exist for shortcodes.

        I don’t think that you should be worried about the flexibility. Give it a try, build something and you’ll see. If you’re missing important structure or design features, let us know.

        It’s a big leap and requires some faith. What I can tell you is that we’ve already used this product to rebuild a good part of our website and it’s looking way better than what we achieved before using Photoshop->CSS/HTML. When you design right in the visual editor, you limit yourself to realistic designs and they come out much better.

        Give it a try and let us know?

    • I understand that it sounds worrying now, but it shouldn’t be. Views with shortcodes isn’t going away. It’s here to stay and will continue receiving updates. Blocks give you a different design workflow.

      I think that it will be less worrying after you give it a try. In any case, if you try Blocks and you don’t like it, you can always continue designing with shortcodes. But if you don’t try it, how can you tell what’s better for you?

48. Will my Lifetime subscription still be good?

    • Yes. We are not making any changes to the accounts system.

49. Hi,
    How can we integrate blocks into Oxygen Builder?

    • I’m not sure. But now that Gutenberg is a part of WordPress, I expect that page builders will start offering ways to insert Gutenberg blocks into their designs. This will allow you to use Toolset’s blocks in the page builder. Again, I don’t know if this exists, but I’d be surprised if the authors of page builders don’t have it in their plans already.

50. Usally i´m the “read-and-not-comment” guy. But after reading so much comments here about how terrible Gutenberg is i feel the need to say a few words.

    I´m using toolset for a few month now. And even i´m still impressed what is possible with the toolset tools for me as a non coder it was difficult from time to time to get to the point where i wanted to come to.

    I never used Gutenberg before the Toolset Integration. I´m using other PageBuilders like Elementor or WP Bakery. But i´ve tried the combination Toolset and Gutenberg since the first beta and i really like it after i understand how Gutenberg works. I´m really exited about what is coming next. For me it makes absolutly sense for toolset to concentrate on one builder which is integrated in WordPress.

    So thank you guys for your great tools and i wish you all the best.

    • Thanks you for your support. Our devs are working extra hard these days completing this version and it’s great to hear nice feedback!

51. Hi Amir,

    This is Ryan at 3200 Creative. I’ve been working 100% in Gutenberg throughout the year.

    So far everything you’ve done with the Gutenberg Blocks for Toolset have been Awesome. Genuinely the best transition I’ve seen from any company.

    Keep up the good work and I trust your team’s perspective/plan!

    • Thanks a lot Ryan. I know that you care about every pixel in the sites that you build, so coming from you, this means a lot! I’m glad to hear that Gutenberg works well for you and that you like the direction Toolset is going.

52. Hello,
    If I…
    “Go to the Toolset -> Settings page and select the Block Editor option in the Editor to use for Content Templates section”
    where previously it’s been set to “classic” will this mess everything up? And can I go back to “classic” if I need to?
    Thanks.

    • When you switch between Classic Editor to Gutenberg, you can do that per item (View, Archive, Template). You can try it per item and this will not affect the rest of your site.

53. I’m primarily a Divi user and have never created a page using the Block Editor so I was pretty nervous about Toolset integrating with it instead of Divi. As I’m starting a new site, I figured now was the time to give the Block Editor a good try for elements that require Toolset’s abilities. Although I still plan on using Divi for all static elements and was nervous about how well the two would work together, I have been very pleasantly surprised! Although I’ve only played with the basics so far… creating Block Views in-page, creating Block Views via the traditional View builder and creating a Block based single-page template… I’m happy to say that almost everything seems to be working well and I have been able to get Block Views to work in Divi which is something I was afraid wouldn’t work.

    Here are some of my observations so far. I will reply with more as I progress through more tests and the new site itself:

    1 — OTG needs to communicate better about how Toolset’s Block Editor integration actually works with non-Block Editor themes like Divi. From what I was reading, I thought all Toolset Block Views had to be built inside the page they’ll be used in. This made me think I wouldn’t be able to add a View to a page designed with Divi. It hadn’t been made clear that in the traditional View builder, there’s an option to design that View with the Block Editor separately from any page. This was an important piece of information as it allows us to build a view with the Block Editor yet still be able to include that View into a Divi page via the Shortcode builder. This hasn’t really been mentioned and even when I asked questions in the comments about if there’d be a way to bring a Block View made with Toolset into Divi, nobody from OTG mentioned the above feature as a solution.

    2 — FEATURE PARITY. ALL blocks should have the same features, style or otherwise, wherever technically feasible. For example the Image block has Hover Styles, but other blocks like Heading, Single Field and Container do not. This is poorly designed as I’d far more often like to Scale an entire Container rather than just an Image. Don’t limit our design freedom by arbitrarily adding features to some Blocks and not others. You don’t know what we want to build, so give us all the freedom you can. Again, add ALL design or other options to ALL blocks where technically feasible.

    3 — HOVER STYLES FOR ALL SETTINGS, not just a select few. For example I’d like to maybe grow the Box Shadow for a Container on hover. This is of course not possible as you you don’t have Hover Styles for Containers and even for Images the Hover Styles are very limited and doesn’t include Box Shadow.

    4 — RESPONSIVE OPTIONS. All settings in all blocks need to have responsive options for Desktop, Tablet and Mobile.. more options would be even better but at least those three. Ideally we could set the breakpoints inside Toolset options to make them match our theme’s breakpoints etc. PLEASE look at how Divi handles Hover settings and Responsive settings. They are grouped nicely and work well. (although Divi doesn’t allow us to customize breakpoints)

    5 — EQUAL HEIGHT COLUMNS / CONTAINERS / BLOCKS. When displaying posts etc in a grid or multiple posts in a single row, it looks much better if the Columns / Containers around each post are the same height. This can be done with flexbox I believe but it doesn’t appear to be used in Toolset. Using min-height is not an acceptable solution as some Containers / Columns may have a lot of content and others very little which means with min-height we are simply guessing at how much space a Container needs which could either lead to a bunch of empty space or not enough. ALSO, why don’t Containers have a % option for height/min-height?

    6 — INDEPENDENT VERTICAL ALIGNMENT OF BLOCKS. The ability to independently vertically align a block within another block or Container. Done with flexbox I believe. For example, align an image to the top edge of its Container and a Button to the bottom edge regardless of how much content is between them. A common layout when displaying a post grid is for each post to have an image, title, excerpt and button. Depending on the length of the title and excerpt, the button will be at different height for each post. This doesn’t look very attractive. Assuming each post has an equal height container as mentioned above, it’d be much better if we could align buttons to the bottom of each Container even if that leaves an empty space between it and the content above it. Of course keeping in mind feature parity, this vertical alignment option should be available to all blocks.

    7 — MAKE ALL SLIDES EQUAL HEIGHT. When creating sliders using the Pagination setting “Pagination enabled with automatic AJAX transition”, there needs to be an option to equalize the height of each slide by taking the height from the tallest. As it stands now, page content below the slider jumps up and down depending on the height of the current slide. This of course makes for a poor visitor experience. I don’t know how Divi does it, but I know that they somehow can equalize the height of slides in their slider modules.

    8 — LIGHTBOX BUG(S). I built an in-post Block View. Each post in the View has an image and for testing purposes I wanted each image to open in a lightbox. I enabled the lightbox option and saw 3 possible issues:

    – Even though the slider says it’s displaying “image 1 of 3”, when you click to go through those images only a single image is displayed, the first image returned by the View.
    – The lightbox overlay appears beneath the Divi header. I looked to see of the lightbox feature has a z-index option but it doesn’t.
    – The image displayed by the lightbox doesn’t appear to be centred on the page, it seems higher up.

    You can see the issues by clicking the images on this page:
    https://dev.authenticcustoms.com/test-block-layout/vision-articles

    I’ll post more observations as I further explore Toolset’s new features. In the mean time, please keep adding more and more styling options. Become the Divi of Block Builders!! 😀

    • Thank you very much Peter for the detailed feedback. This is exactly what we were hoping to receive from our clients, so that we can improve Toolset.

      Our developers will review all your suggestions shortly. I’ll reply here, but more importantly, we’ll add tasks to our development planning. Keep the feedback coming. We appreciate it very much!

54. Hello again. Little more feedback…

    9 — RESPONSIVE COLUMN WRAPPING/STACKING. When using “Native WordPress Columns” to build a Block View, columns don’t stack until near mobile! When using multiple columns, they all get VERY squished before stacking into a single column. This makes multi-column layouts greater than 2 or 3 unusable. YIKES! We need to be able to choose the breakpoints at which columns stack and the number of columns we want for each breakpoint. I believe Kadence has this ability. I know you want to wait for WordPress to release features, but wordpress development moves too slow for stuff like this. Hmmm, this is kind of a showstopper.

    View this page here and narrow your browser window to see the columns get unacceptably squished:
    https://dev.authenticcustoms.com/test-block-layout/column-wrap-test

    10 — UNWANTED MARGIN ON IMAGES WHEN MULTI-COLUMN LAYOUTS STACK TO A SINGLE COLUMN. Looking at the layout in the above link when your browser is at max width and displaying 4 columns, you’ll see that the images have no margins on Top, Right and Left. When you narrow your browser until the columns stack into a single column, the images suddenly get a 40px margin both left and right sides.

    11 — BLUE STATUS BAR CAUSES EDITOR TO JUMP. When working in the Block Editor, there is a blue status bar that repeatedly appears and disappears. It reads “Processing server request. Please wait.” This causes the editor to jump around a lot and makes for an unpleasant experience. I’m not sure but I believe this bar is related to Toolset. Could you move these status messages into a snackbar notice or something else that doesn’t cause the page to jump?

    12 — REMEMBER CUSTOM IMAGE SIZES. Would it be possible for the Image Block to show all custom image sizes being used in existing Views? Odds are if I use a custom image size in one View that I’ll likely use the same size in another view. This would just be a handy feature. In the size selection menu, maybe place a “Custom Sizes” divider between WordPress’ built in sizes and the custom sizes.

    13 — BORDER RADIUS ONLY HAS PIXEL OPTION. It should also have a % option for styling elements of unknown size. For ALL options in ALL blocks, please provide all size options available in CSS for that element. Again, please don’t arbitrarily decide for us what sizing method we should use.

    14 — UNWANTED GAP WHEN USING BORDER. When you view the following page, you’ll see that there is no gap between the images and the box shadow above them. The box shadow hugs each image on three sides as you’d expect:
    https://dev.authenticcustoms.com/test-block-layout/vision-articles

    On the following page however, you can see that as soon as a border is applied to the Container that an unwanted 30px gap appears above the image:
    https://dev.authenticcustoms.com/test-block-layout/column-wrap-test

    15 — INLINE BUTTONS. There’s no option to display Buttons or other Blocks inline so that 2 or more can appear side-by-side.

    16 — NO GRADIENT OPTION FOR BUTTONS. Again feature parity. Please add gradients(or any other styling option) to ALL Blocks where technically feasible.

    17 — ALL BLOCKS NEED HORIZONTAL AND VERTICAL OVERFLOW OPTIONS. When trying to add a border radius to all 4 corners of the containers on the following page, you can see that the images inside the containers escape thereby covering up the border radius:
    https://dev.authenticcustoms.com/test-block-layout/border-radius

    In a case like this, we need to be able to add overflow:hidden to the container so that the image is properly cropped. Of course there are other benefits to overflow options such as being able to turn a Block with a lot of text into a scrollable div.

    18 — BORDER RADIUS CAUSES GAP TOO. Same as mentioned in #14. Border radius, even without the other border properties, causes the same gap.

    19 — ADD MISSING HEIGHT, MAX-HEIGHT, WIDTH, MIN-WIDTH SETTINGS. Please add these to all blocks. Height and max-height are especially useful for working with overflow options mentioned in #17.

    20 — CSS CLASSES AREN’T ALWAYS SAVED. Just a slight usability issue. After typing a class name into the CSS Classes field in the Advanced section, if you immediately click elsewhere without hitting enter or typing a space etc, such as when going to the Update button, the class name won’t be saved. Also a little mention on consistency… It seems for most Blocks that IDs and Classes are entered in the Advanced section, but on some like the Container Block, IDs and Classes are entered in the ID & Classes section. Shouldn’t those options be in the same section for all Blocks?

    One last mention that when adding new features or Blocks, please go all the way and add all the css styling options possible, don’t pick and choose what you think are the minimum options needed. If you take Block styling seriously, there really is an opportunity for Toolset to become one of the biggest Block builders. I look forward to the day I can drop Divi entirely.

    Thanks and keep up the good work.

    • Oops, I think #18 only occurs after applying overflow: hidden to the same container as the radius.

    • Thanks again. I’m adding to our list of features to review for the next version. In the next few days our devs are 100% focused on completing this first release. The next release is all about “beautiful designs”, so this input is extremely helpful and comes at the right time.

55. Hi Peter,

    Also thanks for the detailed report. On number 7 and equal slides, I have had that issue on one of my sites whereby if there is a lag in loading one of the slides the section underneath will slide up temporarily until the slide actually loads:

    https://www.vaughanprint.com

    I have requested that Elegant Themes extend the Fullwidth Post Slider to accommodate custom post types with related categories so that it can be used instead.

56. On number 4: Responsive sizes, I agree, there are oversights across the board both with WordPress in general and Divi. In the WordPress customiser the three breakpoints desktop, tablet portrait and mobile options can be selected to see a preview. In the new block editor I see blocks such as Kadence use the same icon selections to set for each of these breakpoints but disappointingly don’t adjust the editor to reflect these in preview.

    I think somebody somewhere has suggested that this is something that may be implemented at some stage. Wether this gets done is hard to know. As we know, Gutenberg does not want to be a page builder, and more wishy washily is meant for content creation. Pity it can’t be more confident about itself because it has potential.

    The other thing that is lacking when it comes to responsive styling is a breakpoint for small laptop and tablet in landscape mode. It is the the one breakpoint area where I have to implement my own solutions when using Divi and WordPress in general. I see that Oxygen Builder does cater for these breakpoints.

    I see that you mention dropping Divi. I feel your pain. I was hopping the Divi 4 would be a complete re-write based on the new block editor, to maintain some level of compatibility. Much of that though would have been helped if some things had been done by the Gutenberg team where they provided the foundation in the block editor for section/row/column structure. Page builder could then hook in on top of this with their own bells and whistles (Alas my suggestions fell on deaf ears). Bye Bye Divi shortcodes… hello comment tags? Not sure which I prefer. Apparently Brizy is able to do page builder wizardry in pure html markup.

57. One more…

    21 — HIGH SERVER LOAD EVEN WHEN IDLE. Today I went to view some of the websites on my server but couldn’t reach them or my cPanel/WHM. I contacted my host because I thought my server was down. Turns out they banned my IP because I was sending a lot of traffic and causing a high server load. They shared with me some logs and it looks like Toolset was probably the culprit.

    Because I’ve been experimenting with Toolset’s new integration, I had 4 browser tabs open, each on a different WordPress post editor screen. Even though these tabs were sitting idle as I hadn’t used them since yesterday, one or more of them were still sending a lot of traffic to the server:

    
MY.IP.ADDRESS - - [13/Nov/2019:10:33:32 -0500] "GET /wp-json/toolset-dynamic-sources/v1/dynamic-sources?post-type=test&preview-post-id=711&_locale=user HTTP/2.0" 403 94 "https://dev.domain.com/wp-admin/post.php?post=35&action=edit" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
MY.IP.ADDRESS - - [13/Nov/2019:10:33:32 -0500] "GET /wp-json/toolset-dynamic-sources/v1/dynamic-sources?post-type=test&preview-post-id=711&_locale=user HTTP/2.0" 403 94 "https://dev.domain.com/wp-admin/post.php?post=35&action=edit" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
MY.IP.ADDRESS - - [13/Nov/2019:10:33:32 -0500] "GET /wp-json/toolset-dynamic-sources/v1/dynamic-sources?post-type=test&preview-post-id=711&_locale=user HTTP/2.0" 403 94 "https://dev.domain.com/wp-admin/post.php?post=35&action=edit" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
MY.IP.ADDRESS - - [13/Nov/2019:10:33:32 -0500] "GET /wp-json/toolset-dynamic-sources/v1/dynamic-sources?post-type=test&preview-post-id=711&_locale=user HTTP/2.0" 403 94 "https://dev.domain.com/wp-admin/post.php?post=35&action=edit" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
MY.IP.ADDRESS - - [13/Nov/2019:10:33:41 -0500] "GET /wp-json/toolset-dynamic-sources/v1/dynamic-sources?post-type=test&preview-post-id=711&_locale=user HTTP/2.0" 403 94 "https://dev.domain.com/wp-admin/post.php?post=35&action=edit" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
MY.IP.ADDRESS - - [13/Nov/2019:10:33:32 -0500] "GET /wp-json/toolset-dynamic-sources/v1/dynamic-sources?post-type=test&preview-post-id=711&_locale=user HTTP/2.0" 403 94 "https://dev.domain.com/wp-admin/post.php?post=35&action=edit" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
MY.IP.ADDRESS - - [13/Nov/2019:10:33:32 -0500] "GET /wp-json/toolset-dynamic-sources/v1/dynamic-sources?post-type=test&preview-post-id=711&_locale=user HTTP/2.0" 403 94 "https://dev.domain.com/wp-admin/post.php?post=35&action=edit" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
MY.IP.ADDRESS - - [13/Nov/2019:10:33:32 -0500] "GET /wp-json/toolset-dynamic-sources/v1/dynamic-sources?post-type=test&preview-post-id=711&_locale=user HTTP/2.0" 403 94 "https://dev.domain.com/wp-admin/post.php?post=35&action=edit" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
MY.IP.ADDRESS - - [13/Nov/2019:10:33:32 -0500] "GET /wp-json/toolset-dynamic-sources/v1/dynamic-sources?post-type=test&preview-post-id=711&_locale=user HTTP/2.0" 403 94 "https://dev.domain.com/wp-admin/post.php?post=35&action=edit" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
MY.IP.ADDRESS - - [13/Nov/2019:10:33:32 -0500] "GET /wp-json/toolset-dynamic-sources/v1/dynamic-sources?post-type=test&preview-post-id=711&_locale=user HTTP/2.0" 403 94 "https://dev.domain.com/wp-admin/post.php?post=35&action=edit" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"
MY.IP.ADDRESS - - [13/Nov/2019:10:33:32 -0500] "GET /wp-json/toolset-dynamic-sources/v1/dynamic-sources?post-type=test&preview-post-id=711&_locale=user HTTP/2.0" 403 94 "https://dev.domain.com/wp-admin/post.php?post=35&action=edit" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:70.0) Gecko/20100101 Firefox/70.0"


    Once I closed those 4 browser tabs containing editor screens, my server’s load dropped from 14.0 to 0.1. I’m hoping this traffic is a bug or glitch and not how Toolset is intended to run. I would think that if a block editor screen is idle, Toolset shouldn’t be communicating much with the server.

    • Thanks for the report. I forwarded to our devs and we’ll check what’s happening (and fix).

    • Thanks for the report.

      Yes, these are the polling (status check) calls that Toolset does to check what’s changed in the content in the database.

      Today, Toolset does a call every 30 seconds from each browser. We’ll optimize these calls (in the next release) so that they take minimal server resources and we’ll see if we can pause these refreshes for windows that don’t have focus.

58. When are you going to publish the toolset blocks?

59. Yes When are you going to publish the toolset blocks/views? When do you expect it to be a stable release

    • We had a bit of a delay compared to our original plan. This week we ran into a few compatibility problems and we’re handling them. We should be able to release the production version next week.

      • Hi Amir… So any day now? 🙂

60. When will you publish the post about the Gutenberg and Toolset Blocks friendly themes?

    • We’re getting it ready. Actually, we tested many themes and we encountered more compatibility issues (with Gutenberg) than we expected. For now, the themes that we’ll be able to recommend for Gutenberg designs are:
      * Astra
      * OceanWP
      * GeneratePress
      * Page Builders Framework – https://wordpress.org/themes/page-builder-framework/

      • Thanks Amir! 🙂
        I appreciate that you took the time to give the names of the themes without waiting for the post publishing.
        It would be interesting to have also a post about those unexpected compatibility issues that you encountered. It could give improvement ideas to lots of people.

        • Sure. We tested a few things:

          1. The themes doesn’t hard-code elements in templates. Especially: you can disable featured images in single-post templates, you can control titles for templates and archives, you can control pagination in archives (optional).
          2. The theme supports the Gutenberg “full width” control.
          3. The theme includes front-end and back-end styles that allows you to see how your design will appear, when you’re in the editor.

          Not so many requirements. Unfortunately, many themes that are branded as “for Gutenberg” fail on many of these requirements. Without all of them, it’s really difficult to build complete sites with the theme+Gutenberg (with or without Toolset).

          We are working with many theme authors now to apply improvements to their themes, based on our test results. I hope that they will be interested.

          • Great work!
            That’s good that you work with these authors to help them improve their themes. +1
            They should be interested! It’s 100% their own interest.
            I appreciate a lot what you try to implement with Toolset Blocks. It could be the first good reason for me to begin to use Gutenberg. 🙂

          • Hi Amir,
            Any idea on the Beaver Theme? Thanks!

            • We haven’t tested BB Theme as a base theme for Gutenberg designs.

      • Hi Amir,

        Testing Page Builders Framework and so far so good. Gets good performance score on GTMetrix and seems to get better results working with the Divi Builder plugin then the Divi theme directly. I even have Brizy loaded, many of the Toolset plugins and WooCommerce installed as well. Perceptually it feel fast as well.

        I have a few more tests to carry out. For example, I am using the free version so have to resort to customisations for things like fixed header. How easy this is to do will inform my appraisal of the theme. Plus I want to test how effective it is using the block editor.

61. Did you tested with Elementor Pro?

    • Not yet. If I get a chance I will. As I noted the theme feels fast but is even better if you don’t add things like page builders. Adding the Divi builder nearly doubled the page size from around 250KB to just over 400kb and that with the plugin activated and just a plain page. I recently built a site with just the block editor and Kadence blocks. The site was fairly simple but I was able to achieve some level of design sophistication. It was a fairly smooth build and a good experience using just blocks.

      What I did like was the way that updating is asynchronous in the block editor. In contrast to say using the Divi builder on the back end which has to reload the dashboard on every save/update. That starts to become a bit of a drag so I think using Divi on the front end only is the way to go. That being said I am very tempted to use the block editor again in future projects, maybe use Divi or, one of the other builders for particular pages.

62. Off topic, but did toolset.com’s font size/colour/family just change? Text seems smaller, lighter and just harder to read today. (I have poorer vision)

63. You have my sympathies. About a year ago, I decided to move away from Divi because the updates were breaking my sites too much, and I didn’t much like the way the UI was developing. I looked at Gutenberg briefly and decided it was too immature and clunky. The serious contenders were Beaver Builder and Elementor Pro, and I spent quite a while trying both. I found the Elementor framework to be more intuitive than Beaver Builder, with much more HowTo support on YouTube. I took a liking to the BB support people, but sadly that didn’t outweigh the tougher learning curve compared with Elementor.

    Where Elementor Pro fell down was on convenience, support and compatibility. They have the worst licensing model: annual per site, cranky terms, and not open source. The support was amongst the worst I have experienced. Arrogant and unhelpful when I reported an actual bug. They gave me no sense they cared about fixing it. So it was a surprise when next update it was actually fixed. By then I had deleted Elementor Pro and was using free elementor with Astra Theme, Astra Pro, Ultimate Addons for Elementor (and Anywhere Elementor). All on a lifetime unlimited licence, and fantastic support. The compatibilty piece was around the difference between mainstream plugin support for Woocommerce product pages straight from Astra, versus a WC template made with Elementor Pro. With Elementor Pro, I could design a template more precisely as I wanted it, but no other plugins seemed to work with it.

    So while I think Elementor is the best layout framework, I would absolutely not want to have to rely on them for co-development or support. After about 8 mostly happy years with Divi, I’m afraid I’d say the same for them too. As for Gutenberg, I can see the attraction of a transparent development platform from Toolset’s PoV, and for developers who value bug-free stability without intervention over design features and convenience, Blocks will be the way forward. But I still won’t touch it with a bargepole.

64. Hi @Amir,
    Anything new?

65. I can’t find the Blocks plugin in my user account. I’ve looked in ‘stable’ and ‘beta’ and I can only find the ‘Views Beta’.

    • @zayneU, as far as I know (I am only a Toolset customer, nothing official in this answer), the Blocks plugin is not yet available as such. But the Blocks features should be included in the “beta” version of Views plugin.
      On november 20, Amir wrote somewhere above “We had a bit of a delay compared to our original plan. This week we ran into a few compatibility problems and we’re handling them. We should be able to release the production version next week.”
      As we are now a bit later, I hope we will very probably be able to test the “Production” version of the Blocks plugin very soon. 🙂

      • The “next week” was 2 weeks ago 😉

        • I know.
          This is why I asked on December 3 to Amir, “anything new? “. :-)))
          Since we are now December 9, every hope is allowed! 🙂

          • Yes. This project has taken us a lot longer than we estimated. It’s all done today and going out tomorrow morning.

            • Great news!
              How operational and tested is it?
              Should we expect many bugs?
              Can we really use it in production today?

            • We finally released Toolset Blocks 1.0. This release took longer than we planned (and promised) because we ran it through very extensive testing.

              The new version is already running on both toolset.com and wpml.org.

              We already rebuilt much of our own site with blocks. You can see the results on our new homepage (visible when you’re logged-out of Toolset.com).

              On WPML site, we recreated the Translation Services listing using Toolset Blocks:
              https://wpml.org/translation-service/

              There’s zero “custom CSS” or HTML work on both (Toolset homepage and WPML). It’s all done with Blocks now from within the WordPress GUI.

              I hope that you will not run into trouble. If so, our supporters are fully trained on the new product and we’ll do our very best to resolve things quickly.

66. Thanks @Amir for this very complete news.
    It’s good to know that you have tested it on your own websites. 🙂
    Now, let’s build something!

67. Very understandable move – but:
    On our one Toolset site I’ve been using BB for most layouts but Toolset for search/result pages.
    It SEEMS that Toolset Blocks will be a good option to design those Toolset pages better.
    Will I run into any issues using Toolset Blocks and BB together?
    At least I believe I should use TB and BB on different (kinds of content) pages?
    Any more details on this, please?

    • Sure. You can create some pages with Toolset and the rest with BB. Have a look at this tutorial:
      https://toolset.com/2019/12/using-toolset-blocks-on-existing-toolset-sites/