Toolset Blocks 1.3 Beta – Test the post relationships improvements

Β  Β Dario

July 28, 2020

Help us test the Toolset Blocks 1.3 Beta! This release aims to make it much easier to display content from related posts. It also greatly simplifies the translation workflow for sites built with Toolset.

Easy-to-use Post Relationships

Better Translation Workflow for Toolset-powered Sites

The translation workflow for websites built with Toolset just got much easier.

Thanks to these improvements, this is basically how translation works now:

  • To translate Toolset elements simply send them for translation. All the strings inside them will be available in the Translation Editor. This includes Content Templates, Archive pages, and Toolset forms. 
  • To translate a View, simply send the page with a View for translation. You can then translate all the strings in that View along with the rest of the page.
  • To translate related posts or the ones with repeatable field groups, you don’t need to first create them in the default language.
  • You can now also connect posts that do not have a default language version.

How to Install this Beta Version

We recommend using the beta for testing purposes and not on production sites.

To test this beta you will need 3 beta plugins:

  • Toolset Types 3.4 Beta
  • Toolset Blocks 1.3 Beta
  • Toolset Forms 2.6 Beta (for post relationships forms)

Go to your Toolset Account’s Download page and in the Choose channel dropdown select Beta. A list of available beta plugins will appear and you can download them. Alternatively, you could switch to beta versions directly from the WordPress admin.

Testing the New Translation Workflow

If you want to test the improved translation workflow, you will also need the following plugins:

  • WPML Core 4.3.17 Beta
  • WPML Translation Management 2.9.9 (stable)
  • WPML String Translation 3.0.12 (stable)

Go to your WPML Account’s Download page and download the stable versions of WPML Translation Management and WPML String Translation.

Then, in the Choose channel dropdown select Beta. The WPML beta plugin will appear and you can download it. Alternatively, you could switch to beta version directly from the WordPress admin.

Share Your Feedback

Found a bug or have a feature or usability suggestions? 

Let us know in the comments below and we’ll reply quickly!

 

Comments 34 Responses

    • Hi, Torsten! Sorry, I don’t understand. Where is this link to the WPML forum? I just double-checked the post and can’t see it. I did link to the WPML Account page and the WPML FAQ page about how to get the WPML betas. Can you clarify please?

  1. Hi Dario, itΒ΄s really nice to see Toolset improving. Good job!
    However I am really eager for the updated woocommerce views plugin and woocommerce course. Are these coming out as well?

    • Thanks Roberto! Yes, we are working on some last improvements to the Toolset-WooCommerce integration. It wasn’t included in this beta but our goal is for it to land either in the next beta (if we go with it) or in the final, production release. And yes, the WooCommerce course will go out together with the release. πŸ™‚

  2. I’m working on the archive page with blocks

    I have created a grid. I select Container, then dynamic background image.

    They could implement some way to select pre-configured image sizes (Thumbnail, or Medium, or Large). I have tried all the options that they have given us, unfortunately always loads the larger image in the background (featured image).

    Yes, I have also used custom sizes, it only changes the size of the displayed image, but the file that loads, is still the largest image.

    This undoubtedly influences the page loading speed.

    Thank you

    • Hi, Raule! OK, this is not related to this beta at all, but I checked it out and understand what you mean. I just reported this to our develop as a feature request.

      If you use post relationships in Toolset, or have multilingual sites built with Toolset and WPML, I suggest also trying this beta and letting us know how the related improvements in this beta are working for you!

    • Hi, Bruno! Actually, yes it does. πŸ™‚ You can now, for example, create a View to list intermediary post type and then you can display both sides of your many-to-many relationship.

    • Hi, Darryl! I am not sure what you mean about Access, but it is already working just fine in combination with Toolset Blocks. Is there anything specific you are missing?

      I will submit your suggestion about shape dividers to our development team as a feature request. Our to-do list is huge already so I cannot give you any estimation on whether or when it could be implemented. Plus, it depends on how popular/wanted these container features are.

      • I was creating something in the block editor and wanted to restrict access to something using Toolset Access. I couldn’t find a block for Access and there was nothing in the settings for the block. Having Access integrated into each block would be sweet.

        • Hi, Darryl! Actually, you can already do this using the Toolset Conditional block. Insert it and set the following condition: set the first option (it’s a dropdown) to check if “Current user role” is equal to (another dropdown option) “Static value”. A free text field will appear and there simply type in the name of the user role. For example, if you type in “administrator”, only administrators will be able to see the content you will put inside the Conditional block.

          And that’s it. Save the condition and you will see that your Conditional block acts the same as a Container one, whatever you put inside it will be displayed only if the conditions you set are met.

          • That procedure isn’t very intuitive. If something that’s easy to do is changed and put in a place where it wasn’t before and made to be so I need to be told how to do it, that’s not so good.
            Even though right now it’s clunky AF, I do like having the regular conditional stuff integrated with the Access stuff πŸ™‚

            • Hi, Darryl! Could you please give me just a little bit more information so that I can share it with our development team? Specifically, it would be great if you could specify:

              1. What do you mean that this Conditional block workflow is “in a place where it wasn’t before”? What workflow are you used to? Where would you expect to find it? Access controls in the settings of each individual block or something else?

              2. When you say that the Conditional block is “clunky”, what do you mean? Did you encounter any bugs or any usability issues while trying it out? The more details you can share, the better!

              Thank you for the feedback!

          • Hey Dario, sorry for not being clear. I don’t think the conditional block is clunky, just the current way it handles what was previously part of Access.
            I like the idea of having one conditional block instead of a separate conditional an Access blocks. Currently though it’s far from intuitive and I would have never figured that out of my own. I’m sure it’s going to get better or at least adopt the same method as is in the Access plugin.

            • Hi, Darryl! Sorry for more questions but that’s exactly what I am trying to understand – when you say “adopt the same method as is in the Access plugin”, what do you mean? Currently, with Blocks, nothing changed regarding to Access, it works just as if you would use the old Views workflow. You still need Access plugin to control access to content in your site, just as before. Toolset Blocks didn’t change anything related to Access.

              Or did you mean something else?

              Additionally, the Conditional block also works without Access because you can check other things with it, like values from custom fields and taxonomies, for example. So, Conditional block is not only to show/hide blocks based on Access permissions, but to show/hide blocks on conditions in general.

              Thanks a lot for all the feedback! I am just trying to understand exactly what you mean/need so that I can pass it along to our development team. πŸ™‚

    • Hi, Darryl, after thinking about it, I have to ask you one more question.

      Please, could you specify which exact features you need for containers? Which ones do you miss when designing pages? Thanks!

      • I think the Toolset blocks are actually pretty darn good. I looked at a bunch of block collections and went back to using just the Toolset ones.

        Two things I would like to have though:
        Make the container width full window width with a toggle. When toggled to full window width, have the content either full window or regular content width. Elementor does that and it allows for some nice designs.
        Second would be shape dividers. I linked the video above for an example, Elementor would be another example, and another would be https://www.shapedivider.app/

        For bonus points, I’d like to see better integration with with Bootstrap 4. I’m loading BS4 in Toolset settings but it doesn’t seem to be used by any of the blocks. I’d like to be able to set colours and styles using a Bootstrap class or better have the presets as selections (and maybe globally override the colours).
        There’s a bunch of Bootstrap components that could be used but aren’t. I use the Bootstrap stuff in my content templates all the time and could do it manually in code but if I have to keep doing things in code all the time, why would I need the Block Editor?

        • I just figured out how to make the container full width πŸ™‚ It would be nice to be able to set the inner content to whatever was set as the regular content width though.

          • Hi, Darryl. Thanks for the follow-up. The Container block has an “Inner Content” section where you can set the Min-Height and Max-Width options for its content. Is that what you are looking for?

            As for the Bootstrap, blocks do not use it, this is by design. But if I’m not mistaken you should be able to achieve any Bootstrap-like styling by using the design options in Toolset Blocks and inside the Block Editor. For example, there is no need to apply Bootstrap Cards structure and classes when you can really easily design such cards with a few clicks.

      • Hi Dario – the beta already looks great – one specific feature that will be great, if we could add dynamic-/static links to a whole container block.

        Unrelated to the container blocks, a dynamic- / static accordion block would be awesome. There are some accordion blocks available in other block collections, but they cant be used with dynamic data. I think the accordions would be very useful when they can be used with fields from a repeating group or values coming from related custom posts.

        This way we could easy construct FAQ’s etc.

        • Hi, Peter! You mean that if you click anywhere on the Container block, it would take you to a dynamic/static link you specify? Basically, to make the whole Container block a link?

          About accordions… This was already requested previously and we have it on the list of to-do’s but I don’t have any estimation on when it could be implemented.

          • Hi Dario
            Exactly – if that could be done with the Container Block it would allow us for example easy building of any kind of call to action buttons.

            Great to hear that the Accordion made it into the To-do list.

            I forgot to mention earlier that a Tabbed block for dynamic/static content probably will be liked too. Maybe with an option to choose horizontal or vertical tabs.

            • Yes, you’re right, Tabbed block really goes hand-in-hand with Accordion and actually, I see that it is already covered in that feature request I mentioned earlier. Thanks! πŸ™‚

  3. it’s the second time I install the beta plugin, after a day the server service Aruba block my site as a sospicious files in my site. I apreciate to know which tables are changed in mysql, so to understand better the new mechanism of the table that are involved in the new relationship and if it is possibile to change them manually. Tnx

    • Hi, Carletto! I am pretty much sure this is a false positive, however, I don’t know how your hosting service’s filters are set up. Can you at least share the list of files that were detected as suspicious? Without that, it is hard for us to take a look at it.

      We highly advise against doing any change to post relationship tables manually (plus, it maybe even impossible for you to make them properly by yourself). This is why this beta and the upcoming release has a migration protocol built in. It will automatically do everything that needs to be done.

      Can you please explain, why would you like to do it manually?

  4. I do really not which files are detected as suspicious. Maybe all the process to integrate and alter all the tables in mysql is suspicious for the server of Aruba. That’s why I asked to renominate the table relationships manually without the on line process. Thank you

    • I am sorry but without knowing which files are detected as suspicious it’s impossible for us to help. I suggest contacting your host and asking them for an exact list of files. Because that’s not how a good hosting solution should work. If they block their own user’s site they should tell them exactly why they did it and even help them solve the problem.

      That being said, please open a support ticket if you need our help in figuring this out – but again, you will need a list of detected files from your host.

    • Hi there, I’m Jan, the developer in charge of the Types plugin. I can tell you about the tables we’re touching during the upgrade process: wp_toolset_migration_precondition_test_table, wp_toolset_associations, wp_toolset_associations_old, wp_toolset_associations_new, wp_toolset_connected_elements (assuming wp_ is your database prefix). However, I’d strongly advise against trying to do anything manually. It is a pretty complex process that profoundly changes how the data is structured (and even more so if you use WPML), not just adding new columns, for example. Does this answer your initial question?

      I think the best I can offer here is a WP-CLI command that allows you to run the database upgrade without interacting with the GUI (please let me know if you’re interested). But it still uses the same code in Toolset plugins under the hood, so I’m not sure it’s going to help.

      Generally speaking, the permissions to create custom tables or update their structure is one of those things that are assumed by WordPress, and many plugins do it upon installation, for example. So I’d be really interested to know what “suspicious” does Aruba see regarding this database upgrade…

      • It’s not a particular file that Aruba is considering suspicious, they said to me it’s a problem the interrogation between the toolset plugin and the database, it’s a loop os requests (pending) which crashes the server. Sorry I am not able to express better. Hope this could explain in a better way. Carletto

    • Hi, Gary! I just sent you an email asking you for more detailed information about how exactly you were installing the beta and how/where it told you it failed to install. Thanks!

Leave a Reply  

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

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