Toolset Blocks 1.6.2 – Compatibility with WordPress 5.9

   Dario

Announcements

January 25, 2022
22

WordPress 5.9 takes the first step towards Full Site Editing. It includes a new editor (in beta), which lets you edit visually the templates for posts and pages. Read about all the new things in WordPress 5.9 and what this release means for your Toolset-powered websites.

Full Site Editing – What It Is and How It Works

Full Site Editing aims to allow users to natively design their whole site, from the header to the footer, using Gutenberg (blocks) editor.

WordPress 5.9 is the first version that includes Full Site Editing. It’s still limited and intended mainly for experimentation, but it already shows the direction in which WordPress is going and hints at the future potential.

Watch the following video for a quick walkthrough of Full Site Editing in WordPress 5.9.

To be able to use Full Site Editing, you must use a block theme. Block themes are built for the very purpose of allowing you to design everything using blocks. We recommend that you give it a try with the new Twenty Twenty-Two theme.

When you activate a block theme, the Appearance menu is completely different and features only the Theme and Editor pages. Clicking on the Editor (beta) takes you to the Full Site Editing mode.

Full Site Editing mode in WordPress 5.9

As everything works within the block (Gutenberg) editor, you use blocks for everything.

Click on the WordPress logo in the top-left corner and you can access your theme’s Templates and Template Parts. You can edit any of the default templates and even create new ones by clicking the Add New button in the top-right corner.

Other WordPress 5.9 Features

Besides Full Site Editing, WordPress 5.9 introduces a number of other features.

New Twenty Twenty Two Theme

WordPress 5.9 introduces a completely new theme called Twenty Twenty-Two. Of course, it’s a block theme that takes full advantage of the new Full Site Editing feature.

The theme looks minimalistic and is great for testing Full Site Editing.

WordPress 5.9 introduces the new default Twenty Twenty-Two theme

Language Switcher On the Login Screen

WordPress 5.9 also introduces a new language switcher to the login and registration screens. Essentially, it allows you to change the language on these screens. This feature is great for people who build sites in a language other than English (but only one language).

New native language switcher for the login and registration pages

If you build multilingual websites, WPML already has you covered with WordPress 5.9, Full Site Editing, and the new language switcher.

Bundle of New Core Blocks

WordPress 5.9 also introduces a number of new theme blocks like Navigation, Template Part, Header, Footer, Post Author, and more.

Toolset’s Compatibility with WordPress 5.9

Full Site Editing mode in WordPress 5.9 is still a beta product. We haven’t integrated dynamic sources to it, because we think that it’s not yet really usable for building custom sites. As FSE becomes more complete (like, when it will have support for custom types) you will see full Toolset integration.

You can currently use Toolset blocks inside the Full Site Editor but only as regular blocks. All features related to Dynamic Sources and custom types do not work.

Our Plan for Full Site Editing

From the moment that Gutenberg (aka Block Editor) was announced, we decided to switch Toolset to it. Using the default, built-in editor makes sense. It was a huge project but today, all Toolset features that a typical Toolset client needs can be used visually, from the block editor.

We plan on adding support for Full Site Editing. However, as the whole project is in the early stages, we will first wait for custom types support to be added to the Gutenberg plugin. All new features are first introduced and polished within this plugin before they’re introduced to the WordPress core. 

Then, we’ll make sure you can use Toolset blocks, with Dynamic Sources from within Full Site Editing. This will of course include the much-beloved View blocks as well.

What Does Full Site Editing Mean for Existing Sites?

There is actually nothing to worry about when it comes to existing sites. They all use the “old” type of WordPress themes and they will keep working just as before.

Download and Update

We send out the update notifications in batches so not everyone will see the update notice immediately.

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

Are You Excited About Full Site Editing?

What are your thoughts on Full Site Editing finally reaching the WordPress core? Did you already try it on a test site? Are you excited about the long-term possibilities and impact FSE might bring to WordPress?

Let us know in the comments, we’d love to discuss this interesting topic with you!

 

Comments 22 Responses

  1. I am still not sure how FSE will go because all these years people have been either using page / theme builders or theme’s in-built features that allow the users to customize the site.

    For me Beaver Builder & Beaver Themer has worked like a charm, and it has been super easy to customize the site (headers, footers, singular, archive, 404 templates etc.) with just a few mouse clicks.

    Besides, GeneratePress Premium elements also caters to FSE in one way or the another and users can easily design header, footers & other templates using elements.

    In my case, if I am building a non-dynamic website, then I only use Beaver Builder & Beaver Themer. But if I am designing a dynamic website, then I use Beaver Builder, Beaver Themer & Toolset.

    The only reason why I still prefer to build websites using page builders is because they are extremely easy, and page builder add-ons add even more modules one would need to design the website.

    So everything is still a suspense as to how simple or complex FSE is going to be., considering the average users are end-users who are looking for an easy & visual way to design their website.

    • Hi, Alok! Thanks for sharing your thoughts. Yes, that’s a good point, at this moment, nobody really knows how deep they will go with FSE or how long it will take.

  2. Really don’t like where this is going. I don’t like Gutenberg and I will not like the full site option either. On the other hand, I love Toolset classic (Types & Views) and coding the loops & queries to integrate it into Divi and Oxygen websites. I wish that the Toolset team would keep updating it with new features instead of the Gutenberg focus. Other plugins (ACF, Metabox, etc) are evolving fast without focussing 100% on Gutenberg. Hope Toolset will not forget us 😉 Anyway, good work as always guys.

    • Hi, Gille! We didn’t forget you, it’s just impossible to develop two such complex workflows while the platform is going in a completely different (and not really charted/predictable) way. Thank you for your support!

  3. I’m in complete agreement with Gille. I’d go even further as I prefer to use a bespoke theme.

    I am a strong advocate of separation of concerns. Posts including CPT should only contain raw (i.e. unformated) content. All styling should be iñ css files. All page structure in PHP HTML through non-block toolset and/or theme templates.

    I build sites for clients. Clients may say they want to be able to make changes but most are unwilling to learn WordPress. I end up doing the updates for them. I’m tired of overriding defaults. Better off bypassing WordPress and handcoding from my own starter code.

    • Hi, Rick! From what I know, the ability to “lock” templates and template parts has already been raised with the core development team but there’s no way of knowing when or how they will tackle this. But I agree, for any work with clients, I would say this is a must to have.

  4. I’m glad to see you post about this topic. Full Site Editing already supports Custom Post Types. It is available in 5.9. Feel free to reach out to me if you have any questions about how to create the single and archive templates for Custom Post Types using FSE.

    • Hi, David! Do you mean the workflow where you need to go into the theme (or create a child one) and create an HTML template file for the custom post type you need? Or did I miss something and you can actually add templates for custom post types from the WordPress admin?

      Because to be honest, if a user needs to mess with the theme files, I wouldn’t count this as an “available feature”. I mean, the whole feature is called Full Site Editing and promises to do everything from the admin. 🙂

  5. Unlike some people above, I have no problem with Toolset focusing on Blocks. It may be a rough transition for some, but blocks are undeniably the future of WordPress(for anything but the most advanced use cases). Although I am often a little critical of OTGS’s decisions to lean on other block builders for design tools instead of continuing to build their own fully featured block solution, I do give them credit for moving quickly to adopt the block builder.

    For the past 7 or so years, I’ve been using Divi(and Toolset) alone to build sites, or more recently a combination of blocks and Divi. I just now though completed my first all-block site using GeneratePress(just because I already owned a lifetime license I’ve never used. If I were paying for a new theme now, I’d probably look more into blocksy etc.) as the theme and blocks from GenerateBlocks, Stackable and Toolset. There were definitely some frustrating pain points that made the project take longer than hoped and would have been easier in a traditional page builder…

    – Lack of feature parity between blocks. Every block collection(GB, Stackable, Toolset) for example has some sort of a Container block, but each container block has different features and styling options making it a pain to figure out which one is needed to accomplish the design you want… or often what combination of these blocks. Toolset container lets you set transparent gradient background colours, Stackable doesn’t. But Stackable containers offer nice advanced features like setting position, overflow and display but Toolset doesn’t. Advanced page builders like Divi win here because virtually every module has the exact same options.

    – Block incompatibility. Whether with other blocks or the GeneratePress theme, I occasionally noticed some blocks would lose their styling when displayed on the site’s front end. I didn’t have time to report these issues to find their root cause.

    – Bugs. I found several bugs with Toolset blocks. 1 has been fixed, at least 2 others are awaiting fixes.

    – Moving or inserting blocks in the WP block builder is horrendous!!! So often it’s near impossible to drag-and-drop a block to where it’s needed. Thankfully this problem should be resolved or greatly reduced now that we’ll be able to drag-and-drop blocks directly in the block list view in 5.9!

    That being said, there are major pluses when using blocks instead of a page builder…

    . More design freedom. You aren’t locked into the settings/design options your builder provides. When it comes to dynamic data, it’s certainly easier to display data in whatever way you want using blocks than with a page builder with limited options.

    – The block builder loads, saves etc far more quickly than the Divi builder and overall feels more light weight and responsive.

    – And most important of all, pages built with blocks(and GeneratePress) load far faster on the front end than pages built with Divi.

    As much as I believe blocks are the future of WordPress, I of course want to see the old method maintained. There are times when you truly want to make something custom or complex and blocks just aren’t up to the job yet.

    But I was hoping to see more in this Toolset update though. It’s been almost 7 months since the last significant release and there doesn’t appear to be anything new in this one.

    • Hi, Peter, thank you for your comment, it’s a very good summary of all the pros and cons of using either blocks or page builders. Personally, I would expect page builders to start focusing on performance and I believe some of them already are. Block editor is really fast in the backend and front-end, so this is a nice challenge for page builders. Also, I agree completely that with blocks, it’s really awesome that you can use and combine any block bundles you want. So, the main variable seems to be time – how long will it take for the FSE to mature into a usable product. Let’s see. But it does look promising!

      Regarding your last bit, are there any specific Toolset features you’re missing or waiting for at the moment?

  6. It would have been nice to have Toolset 100% ready for FSE but really…..I both understand and respect your decision to hold off a bit.
    I guess if FSE was a finished product things would be different but it’s not and will go through some changes that would cause the Toolset Devs extra work and lost time.
    I’m sure going to play with the FSE stuff but there’s no way I’m going to build a live site with it yet 🙂

    • Hi, Darryl! Yes, it’s not only about the fact that FSE will go through some changes (actually, I would assume it will go through a lot of it), the thing is, native support for things like custom fields is simply not there at all. So, there is nothing to work with. Sure, you can come up with your own custom solution but as you said, it would end up being lost development time the moment a native API is introduced for this.

      I think Matt Mullenweg was very correct at the last State Of The Word when he said that the success of this project depends very much on the theme adoption rate for FSE. I hope we soon see a lot of new and existing themes going the FSE route because that might be a real driver of development.

  7. Hi Dario, I’m not able to reply to your comment. Yes, you create an empty HTML file following the the theme template hierarchy rules. Creating an empty HTML doesn’t seem harder than some other things that users do with WordPress or Toolset.

    • Hi, David, thanks for a quick reply! Personally, creating an empty HTML file is really easy. However, for all the non-developers out there even this can be a major inconvenience. From the usability point of view, I would say that the worse part is there is no hint about this anywhere in the interface. There is no way anyone would know from the GUI what to do. But it’s really the early days and I’m sure they can implement this soon, it shouldn’t be that hard, I presume.

  8. It is funny to see how behind is WordPress about full site editing. I have been into this topic since Oxygen Builder was released and to see it as a great innovation in what for me has been a routine job since 2018, makes me laugh.

    Anyway, seriously speaking, I would really love to get Oxygen and Toolset fully integrated. Unfortunately, they are not there yet… I can’t build a Toolset Blocks archive if I use Oxygen.

    I know that with Oxygen I can build the archives, but in some specific situations I would love to use Toolset instead and that is not possible. The only workaround is to build a View with Toolset Blocks and use an archive, but it is not exactly the same thing.

    I hope both Oxygen and Toolset will address this problem one day.
    I appreciate how Toolset Blocks is evolving and still love the old-fashioned shortcodes way too.

    • Thanks, Roberto! Well, I believe everyone approaches the same thing (i.e. building a site) with a stance that their solution is the best one out there. “Mine is lightest”, “mine is the most featureful”, “mine is the easiest to use”, etc. But I think Full Site Editing is exciting in a way that it will force more innovation in the long run (for both the core and 3rd-party developers). So, while page builders are way more powerful now, it’s interesting to see how the whole Full Site Editing project will evolve. Let’s see!

  9. Hi Dario,
    I didn’t want to mean that my workflow is the best… the best workflow is very subjective, what is best for me can be worst for somebody else.

    We use the tools we find most useful for us.
    By the way, I was expecting a comment from you regarding the Toolset Oxygen integration that will be perfect once we can decide which tool we can use to build WordPress archive…

    • Hi, Roberto! Sorry for not being clear enough, I meant that all plugin authors believe their solution is the best one. 🙂 And I mean, that’s natural, that’s why you do it, because you believe in it. 🙂

      About Toolset Oxygen integration… I don’t remember seeing many requests for this. Did you raise this with the Oxygen developers? Doing such integrations is a challenge and expensive for both sides and both sides need to be interested in such integration. So, unless we hear more “noise” about this, especially if it comes from their team, honestly, I doubt anything will happen.

  10. Just wanted to send a quick note of appreciation for both writing this post and doing what you can to adopt FSE features.

    >However, as the whole project is in the early stages, we will first wait for custom types support to be added to the Gutenberg plugin.

    I’d love to hear more about blockers you all might have for adoption. Feel free to DM me on Make Slack at @annezazu to chat about feedback you have as you go too. Otherwise, look forward to seeing things shared in GitHub 🙂

  11. Hi Dario. For whatever reason I don’t think the comments will let me reply directly to you. Also the toolset site is running a little sluggish don’t ya think?

    Anyway, what I most want to see from Toolset is progress on turning Toolset blocks into a complete one-stop styling solution. I’m not asking for contact form blocks or call-to-action blocks etc, I just want all possible CSS styling options to be available in all Toolset blocks so we can design quickly and easily without having to mix and match blocks from your competition just to get access to a certain styling option.

    Below is a list of some improvements I’m looking for. I quickly threw it together and it is in no way complete or probably accurate haha. I want to stress that ALL styling options should be available in ALL blocks where CSS/HTML allows. Why can we apply a gradient background to a container, but not a grid cell or a button?? Why are there hover settings for images, but not for containers or headings?? I really dislike when developers arbitrarily give options to one block or tool yet not to other ones where the option could be just as useful to users. So I again want to stress that ALL styling options, existing or new, should be made available in ALL blocks.

    – All font size options should allow us to select the units px, em, rem. (Currently just px?)

    – All styling options in all blocks should have hover options.

    – Box shadow settings should allow the “Inset” property value so that shadows can be displayed inwards.

    – CSS Filters – hure, saturation, brightness, blur etc.

    – All blocks should have hover styles, not just images. Although if you give us hover options for all settings on all blocks and CSS Transforms below, we can make our own hover styles…

    – CSS Transforms – scale, translate, rotate, skew, origin etc.

    – Hover Transitions – Duration, delay, speed curve.

    – Horizontal and Vertical Overflow – auto, visible, scroll, hidden, etc.

    – Position Settings – Relative, absolute, fixed, sticky, etc plus offsets top, right, bottom, left etc.

    – Z-index

    – Background Videos

    – Image/Shape Dividers – Top and bottom of every container, grid, grid cell etc. Multiple overlapping top shapes, multiple overlapping bottom shapes.

    – Width, max-width, min-width settings (currently only max-width setting available)

    – Height, max-height, min-height settings (currently only min-height setting available)

    – Reset/Clear to default value button for ALL options.

    – Grid, fit cells to content. Allow grids/cells to shrink to better fit their content and prevent uneven spacing around content.

    – Option on each block to display all inner blocks vertically(above one another) or horizontally(beside one another).

    – Option on each block to align contents/blocks vertically – Top, middle, bottom. Currently only available with a container(?) and notably missing from grids/grid cells.

    – Ability to vertically align one or more blocks to the top of a container, grid cell etc, and one or more blocks to the bottom of the same container, grid cell etc.

    – In Toolset settings, the ability to choose if all block panels should collapse when clicking on another one. For example close the open Typography panel when clicking on the Style Settings panel, then close the Style Settings panel when clicking on the Advanced panel etc. Reduces the amount of scrolling needed when making changes.

    That’s all I have time for at the moment.

    But this is why I’m a little disappointed in this update. 7 months go by and there are no noticeable improvements to Toolset blocks. And no, I don’t really want to mix and match blocks from your competition just for styling options and deal with the bugs that come with. If your competition is the solution to Toolset’s shortcomings, why don’t I just start paying for their product instead of yours? I of course don’t want to do that. I’ve been happy with Toolset for years. But I don’t want to see Toolset fall behind and lean on others while they continue to add features that were once almost exclusively handled by Toolset.

    Anyhoo, thanks for reading!

    • Hi, Peter! Thank you for taking the time to compile such a comprehensive list. I would just like to add something on this topic. This list is what you would like to see us implement. And while it’s really a good one (I really like it), each user has priorities of their own. For example, there are a lot of clients who wouldn’t care too much about what you suggest, they would be like “OK, that’s nice I guess” but on the other hand, they would be ecstatic if we implemented something like OpenStreet maps in Toolset Maps. So, it’s exactly like what they teach in the first class of Economics – “wishes and ideas are limitless but resources are very limited”. 🙂

      That being said, I just forwarded your great suggestions to our development team. Thanks!