Toolset Beta with Support in CRED and Layouts for Relationship Forms

   Amir

Announcements

March 20, 2018
18

Yesterday we released another beta for Toolset, now with Layouts support for post-relationship forms. This update allows you to try the upcoming Toolset functionality, with all Toolset plugins.

This means that you can now use Layouts with post relationship forms. There’s a new Layouts cell for relationship forms, which works very similarly to other CRED cells in Layouts. To learn about the relationship forms, read How to Build Front-End Forms for Connecting Posts.

There’s one more beta release, which we’re aiming for next week. This will include full support for intermediary posts, used in many-to-many relationships. Then, it’s time to close this (very long) development cycle and release the production versions of all Toolset plugins, with post relationship.

Toolset Release Checklist

  • Post relationship in Types
  • Post relationship setup wizard
  • Post relationship in Views
  • Post relationship in CRED
  • Translation for repeating field groups and relationships
  • Prepare Types to migrate custom code
  • Post relationship in Layouts
  • Support for intermediary posts
  • Production release 🙂

Download

As with all previous betas, you can download them from your Toolset account. Go to Downloads, switch to Betas and download the plugins you need. Remember, if you’re using betas, don’t mix them with production versions of other Toolset plugins.

Feedback

Questions? Ideas? Comments? Leave your comments and we’ll reply.

 

Comments 18 Responses

  1. Sounds great! Hopefully you’ll also fix some of the bugs?
    Like:
    -being able to choose which fields to show in the editor of the related post. ie: “choose child fields to display”
    -currently I can’t create a new related post in the editor, only connect existing. When I try to “save” the new one I’m trying to create nothing happens.
    -Hopefully any views I was able to achieve in current version will be achievable in new version? Can’t figure out how to achieve a certain view I was able to do before. I have a ticket in but haven’t heard back yet.

    Thank for all your great work!

    • Hi Scott

      Thanks for the feedback.

      We are still in active development of this project, and we do know there are some things to iron and to include, so we do apreciate that you ask for anything that you miss.

      You mention 3 things, let me go over them.

      Yes, we know that Types used to let you select which fields were included in the table for children posts, when creating or editing a parent post. This has not been possible with the new relationships, but we have a task, currently on testing, to provide this very feature. So for sure this is coming on the final version.

      The problem about not being able to add new related content sounds like a bug to me. I could go on and try to guess the cause, but I think the most useful way to try to address this is by opening a suport ticket. Our support team will make sure this gets properly escalated to our developers.

      Finally, our goal is not only that you can do whatever you were doing in prvious versions of Views. We want to go beyond that.

      In one hand, we want any existing View to continue working as before, out of the box: backwards compatibility is a must for us. We are currently testing the changes needed to support frontend search filters by post relationships, including chanined relationships, so you can filter a post by which items it is related to, and by the related of those related (something we already hd but was not supported for the new relationships).

      On the other hand, we want you to be able to have Views with wider features. For example, we are working on a way to let you filter a View by data from a related post (custom fields or taxonomies from the parent, for example), which is something that you could not do before.

      I am not sure whether this covers what you mention. If you could link to your support tickts here I would be able to take a deeper look directly.

      Hope it helps.

        • Hi Scott

          Thanks again for the feedback.

          I read your support ticket, and as you comment in your opening comment: things are not ironed out yet, and you probably want to wait. The structure and request that you describe is not ready yet, and anything offered in the ticket itself are temporary workarounds, but not the final, official, supported way of doing this.

          The support for frontend searching by the new relationships (and this includes relationships migrated to the new system, even if created before activating it), and for including intermediary post types, and for displaying data from intermediary post types, and all possible combinations… is coming.

          We are finishing an upcoming new beta for Views that will bring this all. It will be released erly next week, and it will include:
          – support for frontend filtering by relationships, including chained relationships like Views supports in its stable version.
          – support for including intermediary post types in those filters by relationships.
          – ability to display data from the parent or child posts when displaying an intermediary post.
          – ability to display data from an intermediary post when both parent and child are well defined (meaning, when in a View loop by one of the related posts, with a query filter by the right relationship).

          I think this will cover all your needs. Please just give us a couple more days to complete our internal testing.

          Hope it helps.

          Regards.

  2. Also, and this is a huge problem for me, with the relationship form the dropdown picker is searching through the parent + child + pages. I only want it to search through the parent CPT for a selection.

    [cred-relationship-form-container]

    Tracks
    [cred-relationship-role role="parent"]

  3. At this point how safe would it be to use the Beta version in a live site? I have a site launching next week and would love to use repeating field groups.

  4. another bug?
    when I click to edit the intermediary post in the parent editor it takes me to the other parent to edit – not the intermediary post.

    • Hi Scott

      I am not sure I am following this thing you report. The parent editor page lists all the “children” that belong to this given parent. This list contains links to edit, yes, but those links are for the “child” post being listed, not for the intermediary post.

      I understand that it would make sense to include a link there to edit the intermediary post too, I am filling a ticket for us about it.

      Thanks!

      • Hi Juan,

        I will explain more fully.
        CPT “A” and CPT “B” in a many2many relationship with CPT “C” as intermediary. CPT “C” has fields.
        When I’m in the editor of CPT “A” and I click on CPT “C” to edit a field it takes me to CPT “B”.

        Hopes this can be worked out ’cause it will be a problem for my users.
        In the current version you can edit CPT “C” directly in the editor of CPT “A”.

        Thank you!
        Scott.

        • Hi Scott

          Yes, we added it to our lista dn this will be included in our first stable version.

          In any case, when you are in the editor of CPT “A”, what it lists is CPT “B” that are related to that “A”, not posts of the intermediary type “C”. That is why the link taks you to “B”, because it is indeed listing “B” posts.

          However, I must say that the current stable version fo Types can not include this, because the current stable version of Types does not include native support for many-to-many relationships. Yes, there is a workaround involving manually creating the intermdiary post type and linking it to both sides of the relationship, but this is in no way a proper data structure.

          But like I said, this will come. Thanks for noticing this was missing.

          Regards.

    • Hi Amir, any news on when can we expect the new production release, I would hate to migrate my site to beta only to see the production release get out a couple of day after.

      • Hi there

        Thi is Juan, Toolst team leader. Thanks for your feedback and patience 🙂

        Our current roadmap includes a final release candidate beta, which will go out early next week. We are ironing the last issues that we want our first production release to include, and we are pretty close.

        After that, we will start a period of review, testing and QA to verify that we are indeed ready for production. We do not expect to find important glitches, but anyway we have a lot to test and cover, so we expect this to take around two weeks.

        And right after that, a first production release will arrive.

        Hope it helps.