First Preview of Many-to-Many Relationship in Toolset

   Amir

Announcements

April 24, 2017
34

You probably heard us mentioning the upcoming support for many-to-many relationship in Toolset. Finally, we have a first working part, which I want to share with you.

To set-up relationships, you’ll go to Toolset->Relationships. There, you will see the existing relationships and can create new ones.

You will be able to set-up different kinds of relationships:

  • One to one – This is a bit less intuitive, but also useful. One-to-one relationships intend to extend a single object, without hanging more fields on it. It’s good when an object has several kinds of optional fields, which should appear only in specific cases.
  • One to many – This is what Toolset had until now. You could set up a parent/child relationship, which is a different name for one-to-many.
  • Many to many – This is what many Toolset clients have been asking for. You’ll be able to easily connect many items of one kind to many items of another and vice versa.

All relationships will have names (which the parent/child method that we have today doesn’t). It’s important because it means that you reference the relationship by its name. Therefor, you can have more than one relationships between the same object types.

For example:

  • Arrivals – between airports and flights
  • Departures – also between airports and flights

When you’re displaying the “airport” page, you will be able to list “arrivals” and “departures”, even though both refer to flights.

Until now, relationships used custom fields. This is fine for smaller sites, but causes a performance problem for big sites. The new implementation uses a custom table for relationships. This means super-fast-performance, even for the largest WordPress sites.

Next month we’ll send another update of our progress. We plan to have the repeating fields group (which set up an implicit one-to-many relationship) and the complete wizard for setting up relationships.

Ideas? Thoughts? Questions? Leave your comments and I’ll get back to you.

 

Comments 34 Responses

  1. Thank you for your commitment to rolling out features like this…
    Toolset is truly one of the most powerful suite of plugins I have found for building out professional business solutions within the WordPress architecture. Everything with this upcoming feature looks to be quite straightforward and the GUI makes a lot of sense. This is going to be so helpful and intuitive to use. Again, thank you.

  2. I like what I see and I am glad you are moving in this direction.

    I would suggest the relationship type (one to one, one to many, many to many) appear on the first screen in the video as well as the next, the relationship table. The description is there (3rd col) but the relationship type would be a good summary to refer back, especially as time goes by.

    Thanks for the preview

    • Thanks for offering to help. We’re not in a beta state yet. I hope to have something nice to test in about a month. At least, we need to complete the setup wizard and all actions for the relationship page.

  6. Interesting. But would rather see you add the ability to upload media/files to specific directories based on custom post type such as uploads/custom-post-type. And would also like to see the ability to automatically delete all media/files attached to posts belonging to specified custom post types when deleting those posts.

    If you’re creating a business directory let’s say, and there are thousands of businesses and each business has several images, that’s possibly tens of thousands of images dumped into your uploads folder. How are you supposed to find images intended for other parts of your site in that? And when those directory listings get deleted over time, they leave all their images behind. How do people deal with that mess??

    I know this doesn’t belong here, I’m new to Toolset and am a little disappointed that what I thought would be basic functionality doesn’t exist. I would think the need to control media/file uploads and deletions would come up a lot more often than the need for many-to-many relationships, no?

    Anyhoo, one day maybe I’ll need many-to-many relations and I’ll be happy then that you’ve added it.

    • What you’re describing about managing uploads makes sense. Have you checked to see if there are already plugins that do that?

  7. Thanks for the reply, Amir.

    I’ve looked for solutions to this yes, this is the closest plugin I’ve found:

    https://wordpress.org/plugins/custom-upload-dir/

    It looked like it was on its way to being something really powerful but it hasn’t been touched in over 2 years. Also, from what I read elsewhere, you had to save your post/page first before adding media so that it’d know which post type the post belonged to or something which is a deal breaker.

    I’ve also seen some code snippets/functions that are supposed to be able to set custom upload directories, but according to a post on your support forum this is not recommended as it could break Views etc which apparently only look for images etc in the default /uploads folder:

    https://toolset.com/forums/topic/can-i-give-a-custom-post-type-its-own-specific-upload-path-in-the-media-library/

    And of course none of these offer any help when it comes to deleting attached media before deleting a post.

    Thanks for any help.

    • Hi Peter… I agree with your previous post that this functionality is needed and would be right at home in the Toolset Suite. I am currently working on a Project Management system and this is one of the pain points I have on my list of things to resolve.

      I have spent several days on this exact topic flushing out overall needs and while I also would like to store files outside the WordPress Media workflow I may also have to go with default file attachment and storage for the time being. In regards to deleting I found a plugin that will delete attachments from the Media folder when the post is deleted but there are obvious other needs relating to deleting, delete based on post type, delete attachment only but not the post and so on.

      https://wordpress.org/plugins/autoremove-attachments/

      Getting back on topic… Many to Many Relationships, what the Toolset team is designing is quite powerful and when you start architecting your system and looking for ways to efficiently manage and store data I think you will find what they are doing quite helpful.

      Kind Regards,
      Dave

      • Hey Dave. Thanks for pointing out that plugin. I made a request to the developer to add the ability to limit automatic deleting to specific post types only and he agreed to add the feature. 🙂 I hope it woks as expected, but would still love such a feature to be native to toolset.

        Hopefully the Toolset team can work their magic on custom upload locations for custom post types too. I don’t see any way to achieve this(without coding it by hand, which unfortunately I can’t do) today and guarantee compatibility with the Toolset plugins.

    • Hey Peter, another angle to attach this from would be renaming the images after upload. This would likely help with SEO and give you an easy way to identify images attached to a post.

      I use a plugin called YoImages! which renames the images and allows me to create custom crops for different image sizes. It’s great but doesn’t work with uploads done through a CRED form 🙁

  8. I welcome this upate 🙂

    How is this going to effect sites with existing post relationships? Is there going to be a way to upgrade the relationships if needed?

    Well there be any performance benefits to the new relationship system?

  9. Hallelujah! I can’t wait. If I’m understanding this correctly, an intermediary post type (relationship) is still created behind the scenes? Even if so, it looks like the new UI will make the process much easier and transparent to the user. Thank you for putting this on the front burner!

    • The intermediary post type will only be created if you need the relationship to have fields. If the two sides of the many-to-many relationship are connected without any additional information, we’ll not create an intermediary post.

      Let me give you an example.

      If you connect between Albums and Songs (albums <> songs), you will probably want to indicate the track number. The track number is a field of the relationship. So, Toolset will automatically create the intermediary object (let’s call is “song-track-on-album”). You will be able to edit that information when you create or modify the placement of songs on albums.

      On the other hand, if you create a relationship between People and Hobbies, you may not need any information for this connection. If you don’t choose additional fields for the connection, Toolset will not create the intermediary objects.

      In any case, the connections themselves will happen through a dedicated (and very efficient) table. The intermediary objects will only store custom fields for the connection and not be part of the association itself.

      Does this help?

      • Yes, this makes sense. Thank you for clarifying. Really looking forward to this addition as I have at least one project coming up in the summer that could definitely benefit.

  10. Also interested in the answer to “What happens with existing relationships?”

    I also mentioned this in a previous post when you were describing this new feature but will there be cascading delete options? If I delete a parent, I don’t want to have orphaned child records (which is what happens now with relationships).

    • Existing sites will not be affected by this upgrade.

      First, the new code will still support the old shortcodes. You will not need to update your content for sites to continue working. The new version of Types will automatically migrate the DEFINITIONS of the relationship from the current schema to the new one. We’ll move only the definition (how posts are connected). The current shortcodes that display related content will continue to work, as it’s practically impossible to ask clients to update all their existing sites.

        • Sites implementing many-to-many relationship will have a very significant performance gain. Sites with one-to-many relationships are already fine. They may be slightly faster, but the current relationship model isn’t causing them any performance issue.

  11. In this comment it sounds like you are going to be implementing a repeating field group

    We plan to have the repeating fields group (which set up an implicit one-to-many relationship) and the complete wizard for setting up relationships

    Which im assuming will allow us to group repeater fields together so that you could, for example, create a repeater that contained an image upload field and a text field that repeat together, without having to create a separate post for each repeatable item as it currently works. In which case it sounds like a move toward the similar ‘grouped repeater fields’ offered by Advanced custom post types. is this correct? If so that would be a great step forward and judging by your forum posts would benefit many.

    • I’m not 100% fluent in ACF, so I can’t give you a 1:1 comparison. What’s coming in Types is:

      1. In the fields group setup, you’ll have a button that says “New fields group”
      2. This will open a sub-group (in the same editor, just tabulated) to which you can add fields
      3. This sub group will also have a button to add “New fields group”, which will work the same.

      Under the hood, Types WILL create a container post for this group. If you wish, you can make this container visible. Otherwise, it’s going to be hidden and not clutter the admin.

      The container post is absolutely required in order to avoid serializing fields (which I think that ACF does). Serializing fields means that there’s no way to query them and filter by them. The container post has no effect on performance or usability. If you don’t need it, you’re not going to see or feel it.

      Does this help?

      • That sounds like it gets closer to an easier ‘grouped repeaters’ offering. Will it integrate into the front end cred forms easily?

        • Sorry for the very late reply. Yes, the many-to-many relationship will be in all Toolset plugins, including CRED forms.

  12. Hi, looks great. Do you also plan POSTUSER relationships ? I used posts2posts before, which is also very powerful, but now I have to create a quick intranet site, so Toolset would be my favourite weapon of choice.

    • Sorry for the late reply. Right now, we’re implementing the relationship between posts and posts. We will see if it’s possible to include users too, but not in this round of development.

  13. I’m excited about this development.

    I’m using Types to make custom post types for my courses. I have a vision of reusing individual lessons across multiple courses. This new feature sounds like it can make that happen.

  14. Hi.
    Im excited about this, as Im building a site with several many-to-many relationships.
    But I have one question: How would you implement a many-to-many relationship between a user (or a group of users) to a custom post type?

    • Right now, we’re going to add the many-to-many relationship between posts. We’re going to look at users next, but we’ll start with posts.

  15. Hi Amir,

    This is great! I’ve been waiting for a long time for this!

    Can you provide a ballpark as to when this feature will be available in Toolset? You mentioned that you would post more at the end of this month, however; I’m not sure if that means we will be able to use this on live sites? Or is it just another round of previews?

    Thanks!

    • It’s still a while before this development will be ready for public testing and then production sites. When we started this project, we under-estimated the amount of work needed. This week I’ll do a full review of the remaining work and I’ll give a better estimate when we show the next preview.

  16. This looks amazing! Will you be able to traverse multiple m2m relationships through nested views?

    Course –> Module –> Lesson

    Course m2m Module
    Module m2m Lesson

    How is the m2m relationship fundamentally different than creating a junction post type?

    E.g.

    Course <> Module
    Module <> Lesson

    Can’t wait to get hands on a beta!

    • We’re not going to be able to link through m2m relations. You can still implement it in your sites, but you’ll need to use a Content Template to connect between these two far sides. If indeed there’s a many-to-many connection between courses and modules and modules and lessons, you’ll be able to create a template that displays the modules that belong to a course. In that context, you can also display the lessons that belong to a module.

      We’re aiming to have a first fully working beta in 2 months.