First Beta of Types 2.3 with Post Relationship

   Amir

Announcements

September 28, 2017
79

Types 2.3 beta is now offline. We appreciate all the great feedback that we got already and we’re working on the next release, which we’re aiming for November. The next beta will include Types and Views, so you can play with relationships on the front-end too.

After a year of planning, design, and development, we’re finally ready with a first public beta of Types, supporting post relationship and lots more. Take the new beta for a ride and give us your feedback.

The highlights in Types 2.3-b1 are:

  • Many-to-many connections between posts
  • Much improved one-to-many connections and the new one-to-one connections
  • Repeating field groups with infinite nesting
  • Post reference fields
  • Lots of UI improvements

Watch Dario’s video to see an overview of the new features:

This beta includes only Types and doesn’t even have a PHP API to display all this related content. Crazy, right?

Well, there’s actually a purpose. The next part of the project is to include the post relationship support in Views, CRED and Access. We already have detailed planning for it and a lot of infrastructure. However, at this point, we want to stop to get your feedback.

Download

You can get this beta from your Toolset account. Click on Downloads, switch the channel to Beta and download Types 2.3 beta.

The next beta will be ready in November.

This is barely a beta version. It’s only intended for testing purposes and definitely not for any production or development site. Types 2.3 beta doesn’t even work with other Toolset plugins (yet).

How to test and give feedback

This new post relationship project is intended to serve you and help you build websites for your clients. If we know what you’re going to develop with Toolset, we’ll make it happen for you.

This is what you should do:

  1. Install Types beta on a clean WordPress site without any other Toolset plugins.
  2. Set up the custom types, fields and post relationships that you’ll need for a real upcoming project.
  3. Create some sample content to see how the new repeating field groups and post connections really work.
  4. Tell us how you want to display this data and what forms you need for it.

The last part is what we need most. We need to know what kind of sites you’re going to build with the new Types features and how you want to display that content on the front-end.

Please create a support ticket and tag it as “Post-relationship”. Describe the project and include screenshots of the custom-types, fields, taxonomy, and relationships that you created. Then, explain what you want to display on the front-end and how you want it to appear. The most important thing for us to realize is where and how you plan on displaying related content. The more specific you are, the better.

Remember to describe custom searches, CRED forms, templates, archives and other elements that you’ll need to build.

After you’re done writing that ticket in Toolset support, please add a comment here with a brief description and a link to your ticket. This will allow us to find your story, study it and get back to you.

We know that this is asking a lot. Every such “design blueprint” that we get will be a huge help. It will help us design exactly what you need in Types API, Views, CRED and Access.

The entire Toolset team is looking forward to your feedback!

 

Comments 79 Responses

  3. looks great!
    how will the update work with sites which are already using “for each” in a view? in a slider, for example.
    also – will the new relationship module help in creating something like hierarchy in taxonomies? let’s say in a car part search. we have car makers, car models, car years and car engine type.
    great work.
    thanks!
    ido

    • The production version will automatically import content from the old schema. We’ll make sure that existing sites don’t change and don’t require manual edits.

  5. Mind. BLOWN! This is going to be a game changer. Very useful, long overdue for WordPress and simple to setup. #BRAVO!

    • There’s no specific thread. You can open your own thread and please add another comment here with a link to it.

  7. I think this is the perfectly right way, that these plugins are evolving to. The repeating groups are a game changer! Would love to have it already released and use it for my current project.

    • Thanks for the feedback. Next week we’re starting to implement the front-end support. It would be great if we knew what you are going to build with the new repeating fields and post-relationship and how you want to display it on the front-end.

  8. Hi Amir,

    This is for testing on the back end only, I take it? As no other Toolset plugin is loaded such as Views and Layouts, we can’t view what happens on the front end.

    Interestingly enough I dived in and loaded on my test site with the betas for Views and Layouts and it wasn’t pretty when it came to repeating fields. I suspect “for each” will need some work?

    Will have a look over the weekend how it all works on the back end.

    • Exactly. This version of Types doesn’t yet have an API for displaying this content on the front-end and doesn’t work with other Toolset plugins. Of course, it will in the near future. We’re looking for feedback for the new GUI and want to know what you’re planning to build with it on the front-end. This way, we can include the features that you need in Views and in CRED.

    • This beta version of Types has nothing to do with Elementor. The issues between Elementor and Toolset come because Elementor, purposely, re-registers all Javascript. We understand why it does that, but this makes compatibility very problematic. Imagine, if you write some code to achieve compatibility and the other plugin forces WordPress not to load it, it’s going to be pretty difficult to be compatible. Right?

      There’s a very simple solution, but Elementor folks need to want it. They need to have a whitelist of Javascript files that they DON’T kill when launching their editor. Have you tried to suggest this to them?

      • Thanks for the explanations, no one so far explains as you did here.

        Yes I’ve raised the question to them but it was ignored . just raised another one hope to receive some feedback, hopefully.
        There is some plugin that could block the script if it’s a file, like Gonzales plugins .
        I understand that Views 2.5 will have this fix too? i wonder if there is a need to create separate plugins for toolset-element or compatibility? Many thanks !

        • Sure, thanks for helping and for being involved. There’s no need for a glue plugin. We’re interested. When also Elementor folks will be interested, we can resolve everything in a day. The more of their clients ask for it, the faster it will happen.

          • I guess ill just have to keep pressing them then.

            Btw according to support in form View 2.5 Stable will have this fix. This is no longer now? My site is filled with 120 content template because of this conflict. i am not sure if this will cause performance issue setback.

            • I checked again. The status of this problem is that we know what’s causing it, we know how to fix and we need the help from the other side. I’ll contact theme again and see how we can move this. Having our clients stuck isn’t something we can accept.

            • excellent move. cant wait to fix this and you’ll have one of the finest websites for a showcase that is using toolset largely 🙂

            • Hi, Amir, good news, Toolset guys replied and want to work together to solve this. ive cc-ed you the email asking for more information wht they need to do to solve this issue . thanks.

            • Thanks. We’re on it. This Monday is a little busy with so many things. We’re preparing a technical proposal for Elementor team, which will resolve the problems.

            • Thank you Amir. hope elementor and toolset with have more customer from this initiatives. cant wait to clear my huge list of redundant content templates!

    • I’m sorry if the announcement blog post was not clear enough. I tried my best. This beta doesn’t work with any other Toolset plugins at them moment. We released it so that people can play with the new GUI and tell us what they’re planning to do on the front-end. It’s not intended for ANY existing sites, including sites that are under construction.

  15. Hi thats fantastic. Tow years ago I built a website with toolset and many-to-many-relationships using post connector. This works, but there are some shortcomings. I would be happy to switch back to 100% Toolset. Will there be an import function from Post connector plugin?

    • Right now there’s no importer. It’s not even integrated with the rest of Toolset plugins 🙂

      Let’s finish the development, you can see how you like it and if it’s still relevant, remind us then about such importer. OK?

    • ok, I see. I looks good in the first version video presentation 🙂 and I will follow the development and remind you. I am sure it will work fine

  16. Finally! This is something what ACF has already. Very good decision to implement this to the new version. How long we have to wait for finale version wit working views?

    • I think that it’s about 2 months from now for full integration with all Toolset plugins and a useable version.

  17. Amir, you’re doing an awesome job. I do have one request, PLEASE:

    In the next version of CRED Commerce, please enable us to choose as many WooCommerce products as we want, so that we can connect them to the CRED fields.

    Also, enable the user to choose as many products as he wants, based on the his input.

    For example, if he types “5”, or checks the “5” checkbox, CRED will add 5 products of that particular type (we connect the product we want for that field in the backend) into the cart.

    This is the only thing I’m missing in your awesome set of plugins, and has been a headache for my digital marketing agency.

    PLEASE, make this available. I don’t think it would be that hard to code into CRED.

  19. I must be missing something. Testing it out and it doesn’t appear to allow for many-to-many relationships, such as cpt “Children” belonging to many cpt “Parents”.

    Yes…certainly, I’m missing something.

  21. I set up the demo site and did as you asked, then posted to the forum but they thought I was asking a question – can I just send the details to you directly by email?

  22. Amir,
    two questions:
    1) Will there be a link between posts and users? In that case, I could use Toolset for e-learning site (LMS). I would assign courses to users.
    2) Will it be possible to limit available posts by taxonomy or custom fileds?

    • I’ve had a similar thought, but I came to the idea that perhaps the author field is the ‘proper’ way to link posts to users(?). Although I too would like to be able to setup the relationship myself as with other post types.

  23. Hi Amir,
    Great work! I have just tested a bit and I have 2 questions:
    1. for which cases is the intermediary post type needed? If I should guess, this would only be needed if there are custom fields for this intermediary post type, right? So, it would only be needed for a many-to-many relationship. When would I need it then for a one-to-many relationship?
    2. I have created a post type “series” and related it to posts in a many-to-many relationship. For the intermediary post type I have created a number field “part” so that I can make a post as a “part” of a series. Will I later with Views be able to create a view that shows all posts of a series sorted by this intermediary post type field “part”? Or would it make more sense to add this field to the posts post type as a custom field?

  24. Dear Amir,

    Awesome Team Work,I have to ask this time please REVIEW the current steps and workflow to setup a client area for business membership site with woocommerce integration as the current steps not only complex to implement but also requires many preparation from user profile to frontend dashboard and finally the user management with roles.

    With Thanks,

  25. Looks pretty cool! When creating a repeating field/group however, I didn’t see an option to limit the number of times a user can repeat a given field/group. Is that option just not added yet?

    And as always, would really love to see a regex-validation option added where we can enter a regex to validate and control data input for each field. 🙂

    • Thanks Tom. All valid points. I’ll go over them tomorrow morning and break them into tickets for Types development. I appreciate your help and detailed feedback. This is exactly what we were hoping to get from a beta version 🙂

  28. I desire for this feature for a long time, hope you release official version in the soon future, but I want to take proposals, you may set up a small feature for repeating field,
    group +1, it means when users or editors added a new repeating fields group, system will automatically count it +1, no need manually do that. for example, a tour company want to type in a itinerary, Day 1, Day 2, Day 3. they do not need to set up it manually, just type content, toolset will allow a itinerary day by day automatically for options, it will help some tour companies or some site owner who want to sort items of content.
    2nd, can it show up only when it meets factors by filter? for example, if you want to book a hotel you just want to search a room available on your schedule at you desired hotel, hotel may have variable room types, but only show the rooms on your schedule. No I am not working at travel industry, but used to be… 🙂

    • 3rd, I have set up relationship posts for archiving feature of repeating fields group, could you please give a tutorial regarding how to immigrate data to post when your are done? Thank you guys for you great job！

      • Right now, there’s no migration tool to the new schema. As part of the production release of Types 2.3, it will automatically migrate data from the current “parent/child” schema. You will not need to manually run any process or update your sites to enjoy the new features in Types 2.3.

    • This makes sense. A field type of “auto-incrementing index” would be useful to many sites. I’m taking a note of it and I’ll see when we can add it.

  29. Sounds great but unfortunately can’t get started as installing beta version breaks the site. Have opened a thread on support forum.

  31. This looks amazing!! Can’t wait to see it with views.

    A few thoughts:
    -why not allow a hierarchical relationship between the same post type? I have an absolutely massive needs for this (right now I just store the post ID of the parent field as a numeric field, which bypasses the issues having to create tons of nested content templates to access the grandparent) and I can’t imagine this is uncommon.
    -hard to get a sense of how views will change at this point. Will we be able to query a m2m without a join? Can we filter by data on parent records (or filter by multiple parent records)?

    From my experience view is amazing but breaks down when once you try to start getting data from the other side of a many relationship (which is not a critique, this is not a problem unique to wp-types).

    For example:

    Publisher Books Authors

    Things that are challenging today:

    For an author, what is the total number pages within all books that they have contributed to?

    How many ISBNs has an author contributed to?
    Or even:
    Display a list of ISBNs an author has contributed to
    -While doable, you’d end up with potential duplicates or have to write PHP

    Better navigation of these data structures (without code) would be simply amazing.

    Ability to feed a list of results from one view to another (e.g. https://toolset.com/forums/topic/view-filter-by-multiple-parents/) in a straightforward fashion would be an incredible differentiator on complex sites (naturally, performance becomes a concern).

    Keep up the great work!

  32. Hi Amir,

    Looks great! Quick question… does this functionality break the current support for the WP-REST API?

  33. This is going to save so many problems. I see you’ve said you’ve taken care for existing sites to keep their structure, are you able to comment more specifically if the way in which relationships are going to be store will be the same (where the relationship type already exists of course) in the database? Just in case someone has, ehem, you know, coded queries in php when the parent / child ID has been retrieved from the Post meta table?

    • Today, the parent/child relationship is stored in postmeta (custom fields). We’re moving this information to reside in a dedicated table. This makes everything a lot more efficient, both in the admin and on the front-end.

      Today there’s a PHP API in Types for getting children and the parent. Of course, you can also use it in Views with filters and field IDs.

      The migration tool will:

      1. Set up the relationships in the options table
      2. Connect between posts in the relationship table, based on the postmeta relations that your site has today
      3. It will NOT remove the old data, so if you’re calling it manually, your calls continue working as before – but only on the old data, not on new data

      So, anything that you created with Types API or with Views will continue working without any need for changes. If you wrote code that accesses the DB directly, I suggest that you isolate it and prepare to upgrade this code, so that it uses the API calls (which make it future-proof).

      “Isolate” – to have the related code in one file and not scattered in many places and well documented, so you can upgrade it easily.

      Does this help?

    • We’re planning to have a working BETA of Types + Views with post relationship in about 3 weeks from now. Please note that this will still be a beta and not yet include the importer from the relationships in the production version.

  35. Not sure if it’s too late to post questions on here as the blog is so old. But I had a couple of questions about the new types.

    One of the things I dislike about types custom fields (and therfore leads me to use ACF) is the inability to change the order of fields.

    In ACF I can assign field groups to appear either below the title, or after the standard fields. I can also change the order of fields so that I can keep similar fields together (for example if I add a new field at a future date that makes sense to be listed next to similar fields on the edit form), or re-arrange the order of fields in the future if required.

    Does the new version of types allow for this, or are we still stuck with fields outputting in the order they are added?

    • Hi Oliver

      Thanks for the feedback. I have good and not that good news.

      The good news is that fields inside field groups can be ordered with our current stable release, and we will keep it in any future Typs version. When you define TYpes fields inside field groups, if you drag them from the field settings box header (the top side of the settings box, where the field type and name are displayed; it is easier to do if you close the box), you can move them up and down the fields list. That sorting is permanent and shown in the post edit page.

      The not that good news is about the field groups placement. It is not the first time we are asked about the ability to put a fields group below the title and above the content editor. That location is not “standard” for a fields box, and although there are ways to do it, we still use the native way of defining such boxes, which means that you can move them freely (yes, also to be under the standard fields if you drag and drop that fields box), but only between supported spots.

      We might consider adding this feature of placing the fields box above the editor, but Gutenberg is on its way, and it will modify the post editing experience in a complete way: there will be no more “above the editor” and who knows what else. I think it is beter that we wait until we see which customization options Gutenber offers, although I am taking a note about the request.

      Hope it helps.

      Regards.

      • Juan, I can’t see that listed in the changelog, nor do I recall reading anything about it in a blog release, nor find mention in the documentation. When did the ability to re-position fields sneak into the stable release, and why wasn’t a big deal made of it? Previously if I repositioned a field it would only change for me, and only on the edit page for the fieldset.

        For me – and therefore I’m assuming others – the last time I used Types for field groups, the only way to change the order was to export all the custom posts, change the field order in the XML file and then import them back again.

        This was a horrible user experience and was the main reason that I purchased ACF for all my custom field requirements. I didn’t buy ACF for the repeater fields or relationship fields. I bought ACF because I was planning on creating a complex set of fields and wanted the ability to change the order without a huge hassle.

        I really think that you should mention this change outside of a blog reply.

        ____

        Back on the subject of positioning field groups. Being able to place them after the title, or after the content was a secondary requirement to being able to change the order. It’s nice, but not a must-have. That said, what would be even nicer would be the ability to change the order of field groups like we can now change fields.

        For example, if I was to add 5 different toolset field groups to a custom post type, they all appear together, but there doesn’t seem to currently be a way to re-arrange them at a group level from 1, 2, 3, 4, 5 to 1, 5, 3, 4, 2.

        I’m not entirely sure how you’d manage that in drag and drop without creating a whole new edit page, but maybe an optional numerical priority setting or a load after XXX field group dropdown might work?

        ____

        While I’m at it, there is one more tweak I’ve always wanted to see. It’s not something that I can do in ACF, but it’s something that I often end up creating a functions.php function in order to fake.

        I’d love to be able to change the visible name (as far as the UI goes) of the Title, Description and other default wordpress fields.

        For example, if I was creating an ‘Author’ post type, I might want the title field to be an author_name field and the description to be author_bio.

        To do this, I’d create a custom post type that doesn’t include those two default fields, and instead create my own versions of them. Then, because title and description have other uses beyond just being displayed, I’d add some stuff in functions.php to populate the title and description fields in the database with the data in my custom fields.

        I’d love it if Types provided a way to change the display name and display description of a default WordPress post field, without having to jump through hoops.