How to build advanced sites with Toolset and Divi

   Dario

Announcements

January 10, 2020
57

This tutorial teaches how to combine Divi and Toolset on the same website. We show how to choose the builder to use for different parts of the site.

When you’re using the Divi theme, we recommend using the Divi builder only for static pages and Toolset to build the dynamic elements of the site.

You should not mix Divi and Toolset elements on the same page, to avoid compatibility issues and make sure that what you build now will keep working in the future.

Legacy integration with Divi 3

The Toolset Views plugin features a “legacy” integration with the Divi 3 version that allowed you to design Toolset elements like Views, templates, and archives using the Divi Builder.

For existing sites based on Divi 3, this integration should keep working and we will do everything we can to maintain it in the future. However, don’t update these sites to Divi 4 version because that would likely break your designs.

Please note that this kind of integration is not possible and will not be implemented for Divi 4 version and newer.

How to switch to the Block Editor when using other page builders

If you’re using other page builders like WPBakery, Elementor or Beaver Builder, we recommend the same. Use the page builder for static pages and Toolset for the dynamic content.

Beaver Builder

When creating a new page, click Use Standard Editor.

WPBakery Builder

New pages use the Block Editor by default.

Elementor

New pages use the Block Editor by default.

New to Toolset Blocks?

With Toolset, you can display custom lists, create custom searches, display posts on a map and much more.

Check out the Getting Started Guide to learn how to build your sites visually using blocks.

Still thinking which plugin to use to add custom fields to your site? Check out the article that compares Toolset and ACF when using Elementor.

Feedback? Questions? Suggestions?

Are you using Toolset and Divi together on your sites? Please leave comments with your questions, ideas, and suggestions and we’ll get back to you.

 

Comments 57 Responses

  1. Not a good advice to not mix Toolset and Divi. Both are top products, so not mixing them doesn’t provide you with the best results. Both development teams should try harder to make your products compatible.

    • Our advice is based on several years of working with a number of page builders. If your objective it to build sites that look great right now, mixing different tools is a good idea. If you’re aiming to build sites that work for years and don’t break on updates, you should consider our recommendation.

      • Amir, I’m really feeling that perspective sink in now. MANY prior years spent in Divi, Elementor, Beaver, et.al.; and I too embraced the design experiences. However, lately I’m experimenting in a pure Gutenberg blocks environment , and with a variety of Gutenberg-specific addins (definitely Ultimate Addons for Gutenberg ; perhaps CoBlocks??, Kadence??, Atomic??, Stackable??, etc.). With just one Gutenberg addin on top of core, we get the in-built block editor at around the 50 yard line in becoming a “page builder”. We hear industry diplomatic language about “not competing with page builders”, but we ALL know it’s headed down that road. If it means code reliability, stability, and a common learning curve for our clients to inherit, we’d better get on board. Right now, we’re dealing with a home renovation: ugly during demo, but pretty in the end?? Maybe

        • Thanks for the understanding. We are working extra hard to include in Toolset Blocks everything that you’ll need to build complete sites. We know that integrating several sources is always an invitation for trouble. The next release of Blocks will include all the features that you need for responsive design. The next round will catch up on much of the “eye candy” that’s available in popular page builders. Our advantage now is that we only need to build the blocks. We get the page builder “for free” from WordPress, so it’s a lot easier for us to move forward quickly.

      • So basically, your advice is to not build a homepage containing multiple sections with a pagebuilder, if one of the sections contains dynamic data displayed using Toolset?

        For example: in the video a homepage widget is shown with three team members. If we want to make that section dynamic using Toolset we should design the whole homepage with Toolset?

        • Yes, that would be our advice. And yes, there are currently workarounds that allow you to insert a View in that place on the homepage designed using Divi, however, we cannot guarantee that that will stay working in the future. Hence our recommendation.

          • Then I don’t understand the direction Toolset is taking. For instance, I recently created a homepage for a client with some nice animations and a list of upcoming events.

            The homepage design was done in Elementor because it makes adding elements, layout en animations real easy.
            The events were done in Toolset by creating a custom post type and a view to display the items. The view was then inserted into the Elementor homepage using the Toolset View widget.

            I really like this workflow because I can use the BEST OF BOTH tools and it saves me a lot of time. It is also easy for the client to update the final design.

            Without Elementor I would have to do much more work when it comes to layout, styling and animation. Basically, all the time I save because I do not have to hand-code dynamic content now gets lots because I have to hand-code the latter.

        • That’s correct. Experience teaches us that this design may break in the future. You can definitely build this homepage today. It will work and look fine. However, since Toolset doesn’t run QA on Divi’s development versions (we don’t receive it on time) and ET doesn’t run QA on anyone’s development versions, you don’t know when this design will break.

    • Hi Yannis, so, there are more solutions to integrate Toolset and Divi. For dynamic contents generated using Toolset View and Block it is not useful to use the Divi Theme Builder as the main page builder, but now, with the new integration of Divi with the Gutenberg block, we can use Toolset Block and add into it the Module, Row, and Section created with Divi Builder. I have tried this solution using Divi into Toolset Content Template and after adding it into the Toolset View or Block, and it is more more more stable than using the Divi Builder as main page builder. If you don’t need to show dynamic content with customizations, Divi is the best solution to build sites.

  2. Thanks for this tutorial. I agree to Yannis Sintos, you are better of with mixing Divi and Toolset. If you use Divi 4 it’s better to create archive pages and templates for postings or custom post types with the Divi theme builder, that way you keep all variations of pages and archives in one place and you can use every Divi module. It’s easy enough to integrate Toolset shortcodes in a Divi text- oder code-module.

    Another thing: i would love to build a masonry layout with Toolset Blocks, will this be an option anytime soon?

    • Hi, Stefan! Thank you for the comment and suggestions. Actually, we have a ticket for the masonry layout, but it is not scheduled at this moment. This means we will do it, but I cannot give you an estimate on when.

  3. Elegant themes have just released an update where you can load a divi layout in a new gutemberg block. I think this could be the best way to use toolset and the divi builder together.

    • I was about to make the same observation.

      Yes, It looks like you can add Divi module elements as blocks now but I would test first, to be sure to be sure.

      That being said, the template that Dario had at the end of the video looked quite good. The ability to add a few things from Divi will be a bonus, like adding say a contact form that picks up the post title. So, for example Enquire about xProduct and when it is sent the title is in the subject line so the site owner knows which product the enquiry refers to.

    • Yes, it happened to go out exactly on the same time 🙂 Someone from ET also thinks that it’s a good idea to integrate with WordPress rather than keep everything exclusively in Divi builder. We’ll need a bit of time to try the new integration before we can recommend it with Toolset.

  4. If you are editing a template with the block editor, two things:

    There is a blue banner with the following text which you can’t dismiss: You are editing a template. Need help?Learn how to design templates with Toolset.

    You also can’t see the name for the template? Possibly behind that blue banner?

    • Hi, Stephen! You can change the name of the Content Template in the right sidebar. Just switch to the Document tab and in the General section, the first field is for changing the name.

      The blue banner at the top is there on purpose. It’s a reminder of what you are doing with a link to the documentation. We added this because it’s a new product, a new workflow, and we wanted to make sure users don’t get lost.

  5. It looks like the divi block is not available when building Toolset templates with the block editor. That’s a pity. It needs to be added.

    • Yes, the Divi development completed at the same time that we produced our video and published our post. We’ll try it and see how it works. In any case, after too much experience we are pretty sure that it’s a better idea to keep a healthy separation. We’ve already seen great integrations what works right until the next major release. So we recommend to use different tools from different vendors on different pages.

      • Thanks Amir, much appreciated if you can get the Divi block to show up in the block list in templates.

        I can then see if the block works and make a judgement call about using it. If it doesn’t work then fair enough.

        A quick note on shortcodes. My feeling on this is that there has been issue around shortcodes when it comes to Divi. When the first Toolset Divi integration for templates was released a number of years ago, it worked well. You couldn’t directly put field shorcodes into a design like you could in the TinyMCE editors. Instead you are presented with an overlay and then offered the unorthodox curly braces {!{…}!} shordcode which you copy and paste in manually. I think these have been problematic. I find that if I convert these to the conventional square brackets [] that everything works fine.

        Prior to the Toolset Divi integration I build my templates and views exclusively in the html/css/js manner and still do in many instances and always find their inclusion, by regular shortcodes, into Divi layouts reliable. I see that the block editor approach is reasonably reliable as well and I am prepared to see if adding simple elements via the Divi block will work as well. I see no reason not to use say the Divi contact module for a form when it is installed before having to add an extra plugin that doesn’t fit into the styling of a Divi site. My experience of having to use say, Gravity forms or Contact Form 7 is that they are horrendous to style.

  6. I use a font on my static pages that I manually uploaded into Divi. I want to use this font also in the toolset blocks – how can I access it there?

    • Hi, Matthias! Toolset Blocks “Typography” section allows you to add all fonts from the Google Fonts library. If you want to use a custom font you will have to apply custom CSS to the element in question and define your custom font there.

  7. I have been combining Toolset Blocks and Elementor, and I had nothing but troubles doing so.

    I guess that Dario is right when he says that you should not combine page toolset blocks within a page designed in a page builder.

    But this is not a great experience.

    In my case I had to display some custom fields for a specific post, so I created a view and designed the view in toolset blocks.

    I then inserted that view in elementor using the toolset elementor widget.

    Everything looked fine when it was inside elementor, but the rendered page did not look fine. The toolset block styling for container backgrounds was not included, nor was the alignment and text colors of the text fields inside the container.

    Its like the css styles was simply not included when the page was rendered, but inside the elemtor designer everything looked fine.

    So Dario is right that toolset blocks and page builders do not work nice together.

    However the design process of working with toolset blocks is not as great as working with page builders. You can’t drag and drop a container inside another container, and its tough to use the toolset blocks. If you add a background image to a container block then you cant see the + icon inside the container block. The solution is to turn off the background image while you build the layout, and then turn it back on later when you are finished working with the inner blocks of the container.

    I also experienced issues with z-indexes. Somehow a container block which I layerd ontop of another container block with negative margins, was displayed beneeth the upper container and not on top.

    So I believe you end up having to use CSS and custom html anyway if you want to be able to do just a little bit more than the basics with toolset blocks.

    I am sure that toolset blocks will evolve over time, but for now, it is too limiting compared to using page builders, that I believe I have to resolve to the page builders and custom code to return the dynamic data in elementor.

    And its such a shame that you cant combine a pagebulider with toolset blocks. It may not be future proof, but its efficient and time saving to use a page builder. And because of that the page builder is still the best option for now, I think.

    • Hi, Henrik! Thank you for sharing. Yes, our priorities are now to evolve the editing possibilities. The first thing we’re releasing very soon is the responsive control for your designs. This is much-requested and for a reason. After that, we’ll continue to improve the whole experience, based on everyone’s feedback.

      As a side note, practically all members of our Toolset team know what it is to build sites for clients and honestly, we ourselves would always prefer stability and something future-proof over visual effects. Also, in the long run, I think clients prefer this as well. However, that doesn’t mean the modern, fancy design is not important, it is and we do understand that.

      • I am sure that Toolset Blocks will only get better. But for now I really wish that it would play better with the page builders.

        Because if they play well together, then you are able to build your building blocks with Toolset, and incorporate those in the page builders, and when the block editor becomes more mature, you can slowly start to switch away from a page builder.

        Right now its the other way around. Because the blocks may not work well as parts in a page builder, then you are forced to redo your work, or choose the page builder because of the more maturnes.

        Don’t get me wrong, I think you are on the right track, but if I were Toolset. I would make sure that it actually played well with the page builders. I think you will get more fans that way, instead of “forcing” us to take a stand now and don’t mix the tools.

        Out of pure efficiency. We will be forced to choose the page builders as it stands today, I think.

    • I’m having same issues building a new site with Elementor & Toolsets. My main problem is that the toolset template for the single post doesn’t work with the overall site theme. For example, I need to be able to hide the title and make it full width. I have zero page options in the toolset template editor & it seems impossible to get it to match at all the rest of the theme.

      This is extremely frustrating. It’s like trying to design the site twice using two different themes & builders.

      I don’t have as big of an issue with setting up a view with Toolset blocks. It’s adequate for creating a grid view of the loop and I’m fine with it. I believe the best all-around solution would be to create anything you want to display toolset data with using toolset blocks (as this is what toolset is bent on pursuing anyway), BUT allow all of that to be saved as a view that can be triggered with either a shortcode or page builder element. For example, Elementor has an element for a toolset view. This way we can build our site the way we want to using the builder we want. Then we can embed dynamic data within these pages using views. It’s the only realistic solution for continuing to use toolset.

      I know Gutenberg is the least-complicated path forward for toolsets, but we don’t design any sites with Gutenberg. We happen to like Elementor for creating beautiful websites. Others like Divi etc. We can’t simply tell our clients, “hey, let’s not build your site now; let’s just wait around a year or two and see if the blocks editor ever catches up first.” Sorry, the site I’m working ones due in February.

      • What you’re describing is more of a theme issue. The themes that we recommend allow you to hide any element from any page. Can you tell which theme you’re using and which elements you cannot control?

        Our own homepage is currently built exclusively with Gutenberg and Toolset Blocks. It took about 2 hours to implement, once we decided on the appearance. Our homepage lacks right now in its “mobile view”. This is something that we’re handling in the upcoming Toolset release, scheduled for the end of this month. What else critical do you find missing in Toolset Blocks today?

        • I’m using the Hello theme for Elementor. I believe it’s basically a very lightweight theme, leaving most of the heavy-lifting to Elementor. I know within Elementor page builder it’s possible to turn off page title, etc.

          I’ve actually had reasonable success building views and then placing them on a page with the Toolset Views element within an Elementor page. So the search page and other pages where I only need to display a section of dynamic data work fine. What would solve all my problems is if I could skip the single-post template and use a regular page instead. Is there a way to use dynamic links in the view loop that targets a regular page and passes the post attribute so it could still show a single post?

          • Could be that Hello is super tightly coupled to Elementor?

            Views doesn’t do what you’re describing and we can’t add it in the near future.

            What benefits does it offer compared to themes like GP, Astra and OceanWP?

    • Hi, Lisa! Yes, you can use Themify but again, we don’t recommend mixing the content you build with Themify builder and Toolset elements on the same page. Design fancy static pages with Themify’s builder and use Toolset for pages with Views, custom searches and other advanced Toolset features.

    • Hi again, Lisa! Could you please clarify a bit, what you would like to export? Could you please give me a simple example? Thanks!

      • My toolset developer created a page to list for sale items, and also a page for the client to submit the item for sale from the front end. So the entire toolset layout, fields, views, etc, was all custom created and I want to export and reuse this set up on my other sites. They used to use a module to export the entire package/template, etc. But she said it can’t be done anymore due to toolset using Blocks. So hopefully we can soon be able to export all of the toolset work to reuse without rebuilding everything. It is expensive for me to rehire someone each time to rebuild it. I know I can move the entire site with duplicator but I only need to move the toolset part. Thanks!

        • Hi, Lisa! It depends on how your developers created the Toolset features. Did they use the old shortcode-based workflow, or the new one using Toolset Blocks?

          We have the Toolset Module Manager plugin which you can use to export Toolset features (custom post types, fields, taxonomies, forms, etc.). This all works fine and you can use it but there is currently one issue/limitation:
          – Exporting of Views and Archives designed using Toolset Blocks has some problems. We are already aware of this and will fix it, I just can’t tell you when. It won’t be in the next few weeks for sure.

          You can read more about Module Manager in our documentation, here:
          – https://toolset.com/documentation/user-guides/export-import/using-toolset-module-manager/

  10. Reading through the comments above I go back to what I said about shortcodes and, how based on the original html/cs/js interface for templates and views, these have always been the most reliable way to use Toolset and continue to be so from my experience.

    The problem seems to be when we get into page builders and the block editor.

    In retrospect the core of all this lies internally with WordPress. The block editor in and of itself is not that bad. The issue is the the disruptive nature of the Gutenberg project coming to the party too late as a reaction to page builders. So the page builders filled a void for many years and used different methods to get things done. Unfortunately the big issue was using shortcodes for page layout structure when they should only be used judiciously. At some stage in the past the WordPress core team should have preempted all this by realising that a standard framework was needed. They should have started a Gutenberg type project a lot earlier and given third party vendors an API to build on their own UI and features.

    Using this idea of common ground, there is a good chance that Divi elements brought into a block template, through a block, should have a good chance of working as Elegant Themes will get that end of the compatibility working.

    Yes, you can mix and match templating methods, and of course, there will always be a danger of breaking changes. Here is a new one. Make a contact form with a Divi module with the Toolset Divi Builder integration. Don’t assign it to anything. Then drop it into a block template with that templates shrotcode.

    • We already added a task for ourselves to review the new Divi module for Gutenberg. We’ll try it and report our findings.

      Can I pick your brain? You already see that our long-term goal is to allow you to build complete sites with Gutenberg.

      You have a ton of experience with Divi and with Toolset. Which missing features in Gutenberg+Toolset Blocks do you consider show-stoppers?

        • Hi Amir,

          I was about to just write up some feedback but notice on my account login that my subscription is not active. Can you check with accounts? I sent correspondence regarding how there were issues with this in Sep 2019 and how, due to some testing I did for Toolset, I was given a year’s subscription, bringing me up to September 2020.

          • Hi, Stephen! I am checking this with our Accounts Manager. In the meantime, could you please tell me when was the last time you did the testing and who were you in contact with? The last record I have is of you having usability testing session with our ex UX specialist Jakub at the end of October 2018. Anyway, no worries, we will sort this out quickly. Thank you!

            • Hi Dario,

              Thanks for picking this up. I see accounts are looking into rectifying this. Yes, the testing was with Jakub, October 2018.

      • For me, the main Divi features I would like to see in Gutenberg+Toolset Blocks are…

        Responsive design options – ability to set each design parameter according to device (Desktop / Tablet / Mobile – although this could be further improved with custom breakpoints), including background images

        Custom CSS – ability to add custom CSS within each module (again this can be assigned to Desktop / Tablet / Mobile)

        Animation Styles – ability to animate any module

        Links – ability to set any module/row/section as a link

        Hope that helps!

      • Hi Amir just getting back to you with my feedback.

        You asked about missing features in Gutenberg+Toolset Blocks. In essence when you create a page builder and, I’ll include the block editor here, you design with a certain level of features and functionality. This is good for say 80% of use cases but there will always be edge cases. Removing some of the open methods to cover the other 20% is not necessary as it would only add limitations. It’s akin to offering a flavour of Linux with a flashy UI and telling users they can’t use the terminal. So it is more things that might get removed from WordPress that I would be concerned with.

        In terms of the editor itself, if the Classic editor is removed a the end of 2021, I am happy with a complete move to the block editor. I ave even created a rudimentary plugin to remove the block part of the editor to just focus on custom fields. You can see the code here:

        https://sitedesign.vaughanprint.com/toolset-gutenberg-future-dashboard-improvements/

        Apart from my concern regarding Divi and Toolset working together, I would see the removal of shortcodes from WordPress a big showstopper.

        Using the original Toolset method for Templates with html/css/js, my fallback position when Divi or the block editor can’t do what I want. There seems to be a single mindedness to page creation from what I can see with the Gutenberg project and hints that many things will be deprecated, then dropped, in future versions of WordPress. As much as I like both Divi and the block editor they can’t do everything.I want to continue making bespoke layouts, like the following as demonstrated on my homepage:

        https://www.vaughanprint.com/#all-prints

        Here is the code for that:

        https://sitedesign.vaughanprint.com/use-grid-on-toolset-view/

        This was done with the view to remove the Bootstrap dependency from my site.

        The shortcode block was created with hints of shorcodes being dropped in the future, something to do with removing the “mystery meat” from WordPress. I have problems with this on two levels. There will always be a level of mystery meat to platforms such as WordPress no matter how much you dress things up with builders and block editors. That is why many of my clients ask for their sites to be managed for an annual fee, covering site updates and the addition of content. Secondly the shortcode is a very effective way to interpolate values from custom fields into textual content.

        I see the roadmap you have set out for blocks and I do agree that focusing on the responsive aspect of this is more important than features. I will note that currently the block editor doesn’t provide the viewport preview that many page builders or the customiser offer. On top of this, I see the need for an extra breakpoints for the small laptop and tablet in landscape. I alway need to add extra styling for these.

        Back to the hot topic of Divi and Toolset. In many ways the block editor does not match the level of sophistication and accuracy that can be achieved in in edit mode. This is where the level of frustration comes in but I do agree with you, the development and release cycle that Elegant Themes are using is the problem. They need to concentrate on tuning things in many areas to improve the comparability. In their own Theme Builder template they need to extend the dynamic content mechanism to pick up the fields generated by Toolset as they did for ACF. They should also include the insertion for toolset shortcodes in the text module. To top this off the Divi Theme Builder Templates need to render and actual sample posts to be accurate. On the block editor end of things they need to make their block for Divi layouts fully compatible and accessible in all possible area of WordPress development. If they do this then I would expect many Divi Toolset configurations would be possible and reliable. As page builder vendors, third party developers need to converge around the block editor to stay relevant.

        • Thanks for this feedback. What you’re writing is pretty much what we’re planning to offer.

          WordPress itself is planning to get a lot better in full-page editing:
          https://wptavern.com/get-involved-with-block-based-wordpress-theme-experiments

          Right now, it’s a plan.

          The next release of Toolset Blocks will offer:
          1. Full control over the appearance of each element on desktop, tablet and phone
          2. Our own grid with complete control for different screen sizes

          From the example that you’ve showed, our grid will be more than capable to handle it.

          I agree that Divi (and Elementor and other page builders) make the editing nicer today. However, from rebuilding our own sites (toolset.com, wpml.org and reference sites), we already know that a graphics designer can successfully use Gutenberg and Toolset to produce good designs.

          So, our plan going forward is:
          * Make sure that Toolset includes what it needs to build nice sites
          * Stay aligned with WordPress plans for the evolution of Gutenberg (e.g., not develop temporary solutions for what’s coming to Gutenberg anyway)
          * Work with theme developers to make best use of the editor and Toolset’s features

          I hope this makes sense. The next release with the responsive features should go out just at the end of January. Let’s see what remains to be done once this is out 🙂

          • I have just two questions on the above.

            When you say our own grid, is that the same as the Grid css or a new css framework? What is wrong with just the standard Grid css. It avoids adding an extra dependency to our sites.

            I notice there was no mention of shortcodes in your response? Are these going to disappear? I mentioned some use cases that currently the block editor can’t implement without them, unless the Core team come up with a replacement. I am referring to interpolation of field values and the ability to build a complete html/css/js template without being tied to the restraints of the block editor.

            I see that arabsw lists below things that Divi does that you can’t do in the block editor. This is what worries me about where the architecture of the block editor could go terribly wrong at this early stage, by adding every bell and whistle that page builders have now. I would prefer, and the ball is firmly in the builders court, if this level of deign functionality stayed initially with specific builders and that the responsibility to make their offerings compatible with the block editor.

            It will take many iterations of the block editor and many years before it matures to some level of maturity. As I said before one the big issue of the block editor is the philosophy behind it, claiming not to be about layout/page building and all about content creation. It’s all a bit ambiguous while the internal layout elements, Group, Columns, Cover are a bit light weight, while third party vendors are charging in with different levels on quality and features. I can’t put my finger on any one particular thing, but I can foresee many pitfalls in the future.

            • Toolset will have its own very simple grid system (CSS). We chose this option for a number of reasons. It will have zero conflicts with other plugins and themes. It will not break when WP changes its CSS. It allows us to implement the responsive grid with all the features that it needs to have (column width, hiding columns, etc.). It’s already implemented and works very nicely in our tests. We’ll be updating our own website to use it next week.

              We don’t control the shortcodes mechanism in WordPress. Toolset will not deprecate its own shortcodes. If WordPress removes the entire shortcodes engine, it’s out of our control. By the time that WP does this, Toolset will have no dependency on shortcodes. There is no work in WordPress core about removing shortcodes. I believe that before someone will propose any deprecation, he/she will have to submit a plan for a better alternative. We also use shortcodes as you describe and we have no good alternative for it.

              Toolset will not be implementing a 1:1 copy of Divi in the Block Editor. This is not our objective and we don’t think that it’s what clients need.

  11. Forcing developers to choose between using a Page Builder or Toolset is a terrible outcome.

    The builder functionality of Toolset is so far behind that of Builders like Divi that I will move away for Toolset long before changing the page builder I use. Building static pages with a Builder and dynamic content with Toolset blocks will result in a very inconsistently looking website.

    The true benefit of Toolset was it’s ability to pull content into pages built via Divi templates – what they call their “legacy” functionality.

    This must be achievable – ACF works nicely with Divi 4 theme builder and dynamic content – so the issue is not to do with Divi but Toolset.

    Page Builder compatibility needs to be the absolute top priority for Toolset.

    • We’re not forcing. We’re recommending and we’re doing so based on significant experience. Our priority is to help you build sites that look good now and don’t break ever in the future. Like with anything in life, you know that mixing different vendors on the same project is always an invitation for trouble.

      If you get EVERYTHING that you need from Divi, I would recommend that you use just Divi for this project. Divi has been around for a while, it has great design and a good community. However, if your project needs features that are in Toolset, it’s our recommendation not to mix between Toolset and page builders on the same page. There are ways to mix Toolset and Divi today. They work. Today.

      Divi has integration with ACF. Today. ACF and Divi are coming from two different vendors. Do you think that Elliot runs full QA for ACF ahead of Divi updates? If not, how do you tell that ACF and Divi updates will not break this compatibility?

  12. Hi,

    The main Divi features I would like to see in Gutenberg+Toolset Blocks are:

    1.Create a row and resize columns using mouse drag to achieve the desired layout.

    2.Create responsive designs to control the entire responsiveness by defining the breakpoint for small screens also hide blocks on different devices.

    3.full control over the typography so we can choose the font, apply font weight, font transform, set font size, line height, letter spacing in px, em, and percentage on the basis of the devices.

    4.Apply padding and margin to columns and set column background with single color, image, and gradient. Give column border, apply border-radius, and animate columns.

    5.Share blocks across websites with design library feature or the default Import/Export tool in WordPress, which we can re-use Toolset blocks across other websites.

    6.Custom CSS and Built-in animation.

    7.Blocks for client area.

    Thanks,

  13. Just wondering when we can expect the new release with all the responsive updates and new grid? Thanks!

    • Hi, Peter! Actually, the release is almost ready. We’re doing final tests and if all goes well, we hope to release it this week. 🙂

  14. I am also a little bit scared about the direction this is going. Before the whole blocks thing a was very very happy how i could built sites with elementor and views, forms, shortcodes from toolset. I built very advanced sites just with that.
    I bought toolset not about the possibility to style my sites, but to use it as a backbone without having to write php.
    As a lot of members mentioned. They don‘t use Blocks or Gutenberg because there are so many great page builders that offer much more features in building modern pages.
    I can understand that toolset wants to ride the Gutenberg wave and is trying to get more from the cake and will be more like a page builder.
    But the power of toolset was always to be the backbone under the hood and not the frontend styling.
    Now you are trying to change it and instead of improving your features to be that backbone under the hood you are going to focus on the frontend.
    So toolset wants to be more like a page builder but what does the big page builders like elementor with over 4.000.000 installs prevents to be more like the old toolset and be the backbone?
    You should not ignore that and focus your work on a good implementation with page builders and be still the great tool i have bought to be the backbone of my sites.
    So yes i am scared of using toolset for my future projects because i don’t know how long you will support the old views plugin with its shortcodes.

    • Hi, Steffen! Thank you for your comment, I understand your concerns but would also like to offer a sincere bit of assurance. Most importantly, you shouldn’t be afraid of us removing support for the old shortcodes-based workflow in Views. There are no plans to remove that. Of course, if you’re using that workflow in combination with other page builders, we cannot guarantee the same for their part, their plugins. But the Views shortcode-based workflow is not going away and we are actively maintaining and supporting it.

      And the second part is what we already shared many times, we cannot keep running after page builders and force them to integrate with Toolset, or hack their plugins just for the old integration to keep working. That’s not a sustainable model for us, or anyone else for that matter.

      We are still completely confident that Toolset can be the perfect backbone for your projects as you call it. But the “page builder” we chose is the WordPress one – Block Editor. It’s native, built by the WP community, it’s here to stay and will only get better with time. It’s already really good and we now build our own sites with it in combination with Toolset.

      And for Toolset, the plan is to keep the steady rhythm of adding important features to Toolset Blocks workflow. So far, it’s going great and we are sure it will benefit everyone.