Toolset 1.6.6 – Compatibility with WordPress 6.2 and Other Fixes

   Kathy Banach

Announcements

March 28, 2023
15

We just rolled out Toolset 1.6.6 to ensure seamless compatibility with the latest WordPress 6.2 version. It includes updates for all major Toolset plugins.

As with all major releases, our team has been closely monitoring the development of WordPress 6.2. Our priority is to ensure compatibility with new features and make sure there are no breaking changes.

Some days after the original release, we found a critical issue with Toolset Maps blocks preview on the backend when running WordPress 6.2. We fixed and released this as Toolset Maps 2.1.1 which is now the Maps version you should use on sites powered by WordPress 6.2.

We also found some minor issues in our other Toolset plugins and addressed them in the following hotfix releases:

  • Toolset Blocks 1.6.7
  • Toolset Views 3.6.7
  • Toolset Forms 2.6.16

On top of that, this release improves Toolset’s compatibility with PHP 8.x and introduces some fixes and enhancements to Toolset Types 3.4.19 and other Toolset plugins. 

What’s New in WordPress 6.2

With WordPress 6.2, the Site Editor (aka Full Site Editing) is finally coming out of the beta, with a lot of usability improvements. Here are the top new features and improvements:

  • Site Editor Interface – Improved interface with a Template and Template Part selection upon entry.
  • Block Styles Settings and Styles –  Separation of settings into two tabs for better organization.
  • Style Book – New feature offering previews and customization of core block styles.
  • Sticky Positioned Blocks – Position blocks like Navigation Bars to stick to the top of the screen.
  • Navigation Block with List View – Improved navigation block editing with access to List View.
  • Openverse Integration – Access and insert Creative Commons licensed media from Openverse.

Of course, there are many other improvements across the board.

Fixes and Improvements

Toolset Types 3.4.19

The main improvements in Types include:

  • Adjustments to some deprecations occurring on WordPress 6.2.
  • Improved compatibility with PHP 8.x.

See the full changelog for Toolset Types 3.4.19.

Toolset Blocks 1.6.7 and Toolset Views 3.6.7

Following the release of Blocks 1.6.6 and Views 1.6.6, we discovered some minor issues. We fixed and released them in Toolset Blocks 1.6.7 and Toolset Views 3.6.7.

Here’s what we included in the Blocks 1.6.7/Views 1.6.7 hotfix release:

  • Fixed an issue with inline Fields in WordPress 6.2.
  • Fixed an issue with the Button block styles.
  • Fixed an issue which caused a reset of the WPML language inside some View loops.

See the full changelog for Toolset Blocks 1.6.7 and Toolset Views 3.6.7.

The Blocks 1.6.6/Views 1.6.6 release covered:

  • Adjustments to some deprecations happening on WordPress 6.2.
  • Compatibility with Stackable – Page Builder Gutenberg Blocks on versions 3.x.
  • Improved compatibility with PHP 8.x.
  • Better compatibility with WPML-powered sites.
  • Restored compatibility with The Events Calendar on versions above 6.x, and the WP Bakery page builder on versions above 6.8.
  • Improved compatibility with theme settings.
  • Added an option to disable the themes options integration
  • Multiple bugfixes

See the full changelog for Toolset Blocks 1.6.6/Views 3.6.6.

Toolset Maps 2.1.1

We originally included Toolset Maps 2.1 version in this joint Toolset release. However, a critical issue was found some days later that breaks the backend preview of existing and new Map blocks on websites running WordPress 6.2. We immediately fixed and released this as Toolset Maps 2.1.1 which is now the Maps version you should use on sites powered by WordPress 6.2. 

See the full changelog for Toolset Maps 2.1.1 and Toolset Maps 2.1.

Other Toolset Plugins

Check out the changelogs to see all updates for other Toolset plugins:

Download and Update

We release Toolset updates gradually, so you may not see this update in the admin right away.

Want the latest update without waiting? Go to Plugins → Add New and click the Commercial tab. Then, click the Check for updates button, select the plugins you want, and click to update them.

If you still don’t see the updates available, please try again later. It can take up to 24 hours for the updates to propagate to all Toolset-powered websites. 

Feedback? Questions?

Feel free to share your feedback or ask any questions in the comments section below! We’ll be happy to reply.

 

Comments 15 Responses

    • Hi, Kostas! Sorry for that. I updated all links to changelogs and they should work now. Thanks for letting us know about it!

  2. Hi Dario,

    Great to see continued development of Toolset after last years hiatus.

    Just one thing though, and this has been rehashed here many times before. The emphasis around developing Toolset exclusively around the block editor is being done to the detriment of other uses cases for Toolset and WordPress as a whole.

    I sent feedback a wile ago about this and how Toolset is ignoring many opportunities to satisfy a lot of customers who don’t and will probably never use the block editor for views. These are probably a fair proportion of users who can quite easily built templates and views using the older HTML/CSS/JS interface, and to greater effect where the block editor has limitations.

    That aside, another use case is having just custom fields in the editor interface for users to fill and have the frontend template apply a layout template around this. This, without the fuss of the block editor inserter, which only confuses novice users who just need to enter the appropriate content in fields.

    The Gutenberg team just don’t get this concept of separation of content from layout and as a whole the option to have an interface just for data entry. I include Toolset in this oversight as in the older Toolset Types setup there was always an option to disable different parts of the editor interface like the main WYSIWYG text area. I do have a rudimentary plugin that crudely removes the block editor via CSS but shouldn’t have to resort to this.

    Conflating content with layout seems to be the novel idea that in the minds of many Gutenberg fans has a novel attraction. It has its place for one off page design but starts getting cumbersome for many other scenarios. Trust me all of the clients I work with generally do not want to work in any shape or form on the back end of their sites, which is why they employ me to put up the content on their site. Where they must administer content, the simplest interface is what is required. Presenting them with the block editor is a non runner as they run a mile with the intimidation of it all.

    One last thing before concluding. The block editor in itself doesn’t do responsive effectively enough to be useful to any serious web designer and by dint of this makes Toolset’s, Kadence’s or anybody else’s attempt a cobbled affair. They really don’t match up very well.

    Toolset needs to go back to grass roots on all this and look at how professionals have been using its plugins over the years. By all means the block editors its place in WordPress but it shouldn’t be the be-all and end-all of everything.

    • Me as one of the earliest block editor adopter can not agree.
      Yes, it has it’s own limitations which are being cured over time, but the idea of sticking to the core way of doing things has it’s advantages over any other third party editor. I often hear how not good enough it is, however to all the “not good enough points” there has always been a way around, one just needs to find it out. Even while it was still in it’s early stages of development I took the risk of migrating my process to it, and now it’s been years and my websites continue to run and evolve just fine.

      As per your question on turning off the block editor(and I assume you need to do this on CPT’s) – just tick off the “Editor” checkbox on the CPT’s “Sections to display when editing” option pane, and you’re good to go. You can’t do that on WP’s native post types, but that’s being easily worked around by creating a dedicated CPT.

      I believe Toolset developers are on the right track of following the way WP core evolves, even if that includes a “pause and look around” period(a wise move in my eyes). That was a good time to fix some existing bugs.

      Remember – there is always a way around things, you just need to look for it.
      For instance – I have provided my clients with fail/fool-proof method of editing the content on the website without risking messing up the layout. Just create a “Content” CPT (no editor – just custom fields) where they can input their content in a safe and user-friendly environment and pull the contents of the custom fields into the actual pages by using the Dynamic Content option. Create a custom role that lets users access only the “Content” CPT and give them all the freedom in the world to touch up the content of whatever part an actual page they like. Including replacement the contents of image galleries and rearranging the order(and editing the content) of list items in unordered lists by utilising repeating fields. Yes they can not touch the layout but they are never meant to do this as they are not web designers. Just make sure you provide an explanation for the content of each custom field to what part of the specific page it corresponds and that makes it as easy as pie for users to update the contents of their pages. Much easier and fail/fool-proof than anything else!

      • DiyanK , it is patently clear that for you the block editor is a good fit for the way you work. But, there are far more users of WordPress who do not want to use the block editor. I am personally in the middle on this one. I do use the block editor for post content and it works brilliantly for that and I have used block views and templates for rudimentary layouts. .Where it doesn’t for me is with template layouts and for setting up custom post types specifically for data entry. This was the point I made above.

        Yes, you can tick that box in types to hide the default WYSIWYG text area but when you do this the interface reverts to the Classic editor. Now there are two things here. First of all WordPress/Toolset will have to eventually address this in the future once the Classic editor is abandoned completely in favour of the new way of doing things. Secondly, with the block editor saving is done asynchronously which is a very big improvement over the Classic editor which reloads in the browser. That was never a very good user experience for anybody… so yes, block editor interface on the back end of post, sans the blocks/inserter/ etc. and just custom fields.

        Think about it. Why hasn’t Automattic, which owns WooCommerce, updated the products backend interface from the classic look to the new Gutenberg look? Maybe it’s a design quandary they can’t get their heads around yet because the Gutenberg team have decided that this isn’t a priority?

        Regarding those of us who still do work on bespoke layouts for templates and views, the standard HTML/CSS/JS interface is still fully open and more flexible and for those of us proficient in using it faster to work with.

        • Just one note – the Gutenberg team doesn’t decide to do anything without Automattic. So, Automattic isn’t waiting for the Gutenberg team, Automattic is running the Gutenberg team. 🙂

          • Thanks Dario,

            You make it sound like a chicken and egg situation, but I know what you mean.

        • Allow me not to agree again buddy. Turning off the Editor checkbox does not return the Classic editor. It hides any content editor and leaves only the custom fields. You need to have that CPT set to use the Block Editor in the Editor(required) radio button setting, and then have the Editor (Content input box for writing.) checkbox turned off. Here’s an example of how it looks: https://www.dropbox.com/s/jtqu86qvwlyy0kx/Screenshot%202023-03-30%20at%204.16.12.png?dl=0

          • Yes, the screenshot is of the classic editor UI with the main content area turned off. To clarify, I am looking for something like this in the block editor UI as well, for two reasons. A. the performance of the block editor is superior when saving and updating because it does so asynchronously without a browser refresh. B. At some stage it is inevitable the the classic UI will be marked deprecated and then removed. We will need some UI do to all the things we have been able to do with the old classic UI. This includes my data entry set up and things like an interface to load all the info for a Woo product.

            I just wish there was a bit more attention paid to things like this within the Gutenberg team. It would bring more trust and confidence in the what is happening with the Gutenberg project.

    • Hi, Stephen! Thank you for your comment. I will share it with the team. I would only add that as someone who has produced websites for clients in the past, I know what you mean. The way I’ve seen it is, different clients and projects require different tools. For some of the ones I worked with in the past, Block Editor would be just fine. For others, similar to what you described, not so much. In the past, I approached this as any other work – there are right tools for every job. So, I didn’t look, but I presume there are multiple solutions out there for hiding/removing the Block Editor from the GUI. However, even if you have the old Classic WP editor, in some cases, you’d want to remove it, right? So, if I cannot change the general situation, I see two options: a) Adjust my workflow and stay with the current tool, b) Find a tool more appropriate for such clients.

      • Thanks Dario,

        Thanks for the feedback.

        There aren’t any solutions for removing the block editor from the GUI. I have a very rudimentary plugin that I made for my own projects but wouldn’t share as it is something that needs to be fixed occasionally to counter the vagaries of what the Gutenberg team are doing with their development of the the block editor. Also I am not a plugin developer so wouldn’t offer my solution for public consumption.

        I suspect that because the development of the block editor is such a moveable feast that this is not a feature that Toolset would want to dabble with either. It’s a pity that the Gutenberg project is so focused on the origins of WordPress as a blogging platform and don’t cater for edge cases like data entry for inventories that use a prescribed set of custom fields. Maybe these frustrations will be addressed given time.

  3. I bought Toolset just before the post about pausing support. I had done my research and settled on Toolset, but had to shift to MetaBox for certainty with a new project.

    Gone are the days for me of coding custom posts, templates etc and styling them by hand.

    I have watched the updates keep coming which is great as it has reassured me of continued support, so have purchased Toolset again for a new project. (without realising you have a discount for referring clients) The reasons remain the same. It has the best interface and capabilities for most jobs.

    I am happy to hand over a site to a client who is pretty useful using Word as they generally have the ability with a bit of training and help to be happy in the backend.

    That said Toolset in the backend is much more usable for those clients, and the one thing they do not want is to ever see code.

    Here is the thing. Clients who have never seen the old editor are non-plussed by it if you show it to them.

    Even with the changes that have been pretty continuous with the new editor, they just take it on board as an improvement.

    While you can now do a lot of what Toolset does in the new editor, creating post types, taxonomies, managing dynamic data and inputting data seems to me to be the strengths of Toolset.

    I know that in the new editor the answer is supposed to be to create custom blocks for inputting data, but that does not cover creating custom posts and taxonomies in a good interface, and fields are very easy for users to use.

    I think the demand for Toolset will grow exponentially with the growth of the new editor. The opportunity is certainly there, That is why I really encourage On the Go to restart further work other than compatibility fixes .

    Would you be able to post about the road ahead now 6.2 is about to be released? The new editor’s pathway and capabilities are pretty well defined now.

    • Hi, Mark, thanks a lot for your comment and thoughts. To answer your question: when we decided to pause adding new features, the prospects around what Block Editor is and will be were quite unclear and discouraging. At the moment, it looks like things are more stable, with a bit clearer path forward. Because of this, we will look at the whole picture again soon and reassess the situation based on the current situation and developments. We will update everyone once we do that, but I personally can’t give you a time estimation for when exactly this might be.

  4. It’s good to see Toolset is still alive.
    I see some people saying it should steer away from the blocks, or focus on legacy views and editor, in my perspective that’s the wrong approach.
    WordPress is clearly going into the ease of editing content direction and FSE is a gamechanger not only for “Themes factories”, which will have to change their approach to themes, probably focusing more in great patterns rather than a bloated classic theme, and also for Toolset, since FSE removes some of it’s advantages in content templates.
    However, there is still one “uncharted area” where the Toolset promise (create things withou coding) can make a lot of sense and can give it a unique position in the ecosystem: building the backend.
    The WP backend is great for people used to it, somewhat dawnting for newbies, but everyone is able to use it.
    However, if one needs custom admin pages or views, the only way to do it is by coding, there is no visual query builder (apart from the limited WP Data Access) to create rich options pages with listings, editing, and so on.

    Picture a common scenario: a corporate training with courses (the syllabus) and course editions (the actual courses taking place), which are sold via woocommerce (either a connected hidden product, or the event itseld is a woo product with custom fields like date/time/location/stock quantity and some frontend fields for attendee data).
    All that can be done now using plugins (events/tickets plugins) or custom fields and relations in toolset, using the blocks to build the frontend.
    But the client (the corporate training company) needs reporting, so they can follow on on how the business is going, how many attendees have signed up for edition A or B, ….
    Some plugin already have some dashboards hardcoded or sold as extra. Or one can make some limited dashboards in the fronted, using views/blocks, but it’s kinda awkward to tell the customer “go to the backed to view this and to the frontend to view that”.
    And that’s an area where Toolset can come in, using views/queries and, rather that custom frontend blocks, have “backend blocks” of some kind to be able to build and link stuff in custom options pages.

    This opens the opportunities for all kinds of stuff: not just the example above, but building custom CRMs for woo or anything else, custom reports for stores or communities, success/failure dashboards, …..

    Still in the backend department, Toolset could have better siblings/parents creation/editing metaboxes, like Jet has, allowing to define has shows up or not, currently, for exemple for woo products as siblings, a lot of options show up and must be disabled in a user by user process rather than globally.

    The thing is, if wordpress core is moving as a cck for the frontend, than Toolset can have it’s own space by becoming also a cck for the backend.

    Just my five cents…

    • Hi! Thanks for sharing your thoughts and very interesting ideas which I haven’t heard yet. I will share them with the team. But I would definitely agree with you that blocks is something one won’t be able to evade forever. As the whole WordPress ecosystem already turned to blocks there is really no going back for the platform.