How to prepare your sites for the new post relationships, coming in Types 2.3

   Dario

Announcements

March 1, 2018
34

Toolset Types 2.3 release (currently in Beta) introduces a completely rewritten post relationship features. We created a new Post Relationship API to make sure nothing breaks after this big release.

Who is the New API for

If you have existing sites that use custom PHP code to query related content, you should adjust it to use the new Post Relationship API.

What is the Change About

Current, official release of Types features an old, “legacy” version of post relationships. So far, you could use WP_Query and functions with the wpcf_ prefix to query these legacy post relationships.

Types 2.3 will introduce a completely rewritten, more advanced version of post relationships. When you activate this version on a site, you will be able to run an automated process that migrates all the existing, legacy post relationships to the new ones.

We created this new Post Relationship API to ensure that any of your custom PHP code that queries related content keeps working after this update. The new API works with both the legacy and the new post relationships.

What You Need To Do

Head on to our documentation page about using the new Post Relationships API and implement the necessary changes to your existing sites.

What Happens if You do not Change Your Existing Code

Your sites will continue working but the new contents you add will not show up in your custom PHP queries (new content will show perfectly fine with all Toolset elements that you build with our GUI). Besides this, there might be some additional cases where some of your custom queries involving post relationships might stop working.

While we are doing our best to ensure your current custom PHP code keeps working even if you don’t switch to the new API, we cannot promise we will be able to cover all of the possible cases.

This is why we strongly recommend updating your sites now.

What’s Next

As stated in our documentation, we will be adding more functions to the new Post Relationships API, to cover more use cases and scenarios.

Any Questions or Comments?

If you have any questions or concerns regarding this topic, please let us know in the comments below.

 

Comments 34 Responses

  1. translate your newsletter and ….read carfull…..your software dokumentation in “GERMAN” or cancel me from all of your newsletter!!!…lol…. the guys behind WPML the translation company….LOL….LOL I have a lifetime license

    • Hi, Oliver.

      I am sorry, but from your comment, I don’t understand what is the actual issue. Was there something wrong with the newsletter, or do you mean that you lack Toolset documentation in the German language?

      If it is the latter, we used to have documentation in German, French, and Spanish but with time, we realized that it was simply not practical because of its scope and how often it changes. You probably noticed that other software-related products, no matter how huge they are globally and financially, in almost all cases have documentation only in English, and as we learned ourselves, there’s a reason for this.

      Kind regards.

      • A company that has developed one of the most popular “translation tools” is not able to translate its own newsletters and documentation? Dario, I’m laughing my ass off.
        It is too hard for you to translate the constant changes?

        But marketing on the Internet is done in German!
        Sure, but only until the stupid buyers buy your software.
        After that, you expect us all to learn English?
        I don’t give a shit!

        I don’t want to learn English. I like to speak my language!
        Read and learn!

        • Hi, Oliver! I am sorry you see it like this. We understand it is not a perfect solution but we realized this is currently the best way to provide our clients with the up-to-date documentation they need to use our plugins. Regards, Dario

  2. This is fantastic news!!!! I’ve been waiting for this for 3 months to properly test out the new many to many relationships and query their intermediary fields!

  3. Hi,
    This is really promising, I’ve been played around a little bit and I would like to make user custom fields with relationship linking to custom posts. For example, custom post “Company” associated with one or more users. Will it be possible to do?

    • Hi, thanks for the comment!

      Actually, the possibility to create relationships between posts and users is on our roadmap but will not be included in the first production release of Types 2.3. But definitely, everything was built with this in mind and it will be added as soon as possible in one of the subsequent releases.

      For the time being, you can use the following workaround. You can use a CRED form for creating new posts that only a logged-in user can submit. When they submit a new post you use their username to populate the post’s “Post Author” custom field. This allows you then to create Views that list only posts belonging to/created by a specific user.

    • Hi!

      No, you will not have to do this when the final release is out. We are working on the importing/exporting right now (it is not working in the current betas). So, for the final production release, this will all be implemented and we will make sure that all imports with legacy relationships are handled properly.

    • Hi Markov

      Thanks for the fedback and the question.

      I see that WP All Imports is a plugin used to import data into a site. For most of the fields that you would import to a site, no chnage is required.

      However, if you were adding relationships using the “_wpcf_belongs_{slug}_id” custom field key, then yes, some changes will need to be added to your workflow. Once the new post relationships are activated on your site (on clean sites they are activated by default), relationships wil no longer depend on those custom field entries, so any relationship data that you import afterwards using that format will not be properly registered.

      I am not sure if this is your case, but if it is then it might make sense to open a support ticket and let us check how we can better help you transition your code.

      Anyway, as Dario mentions, our roadmap includes adding a mechanism for exporting and importing data. Maybe that can help you too.

      Regards.

  5. I have an active website with several parent/child relationships which was created in 2015 with Toolset. Do I have to change code using the API as I am reluctant in case the site fails. I am not a programmer that is why I used Toolset and once I got it working, apart from basic upgrades I have not altered any internal coding. To be honest this change which sounds great scares me a little as a lot of people rely on the site working for them.

    • Hi, Rodney!

      It is really hard to tell without taking a look at your site’s code, but the site should probably be fine. However, as you say, a lot of people rely on the site, so I would suggest opening a ticket in our forum and asking our supporters for advice. After looking at the site/code, they will know more.

      There is still time before this version gets officially released, so I think it is very good that you are thinking about this now. We have enough time to take a look together and make sure your site keeps running just the way you made it to.

  6. Hi!

    I use _wpcf_ in add_post_meta and get_post_meta functions.

    Well, do I need change the code?

    Thank you.

    • Hi, Fernando!

      By what you have described, in the final production release, all of these cases will be covered and you will be able to keep using the same code.

      In more technical words:
      – We are not changing the wpcf-field postmeta prefixes.
      – For the _wpcf_belongs_*_id postmeta, there will be a compatibility layer that transforms it into the appropriate action for the new relationship implementation.

      Lastly, even though your existing code will continue to work, consider updating it to use the new API anyway. It will remove one layer of complexity when accessing the data and it’s generally a good development practice to keep the code up-to-date with any framework/platform.

  7. What happens to types_child_posts() in the future? I’m not using wp_query() as in the example in the new documentation, I use types_child_posts() to see if there are children then I use get_posts() with a query similar to the wp_query example but not exactly.

    Specifically, here’s my code.

    if (types_child_posts(‘work’)) {
    $childargs = array(
    ‘post_type’ => ‘work’,
    ‘numberposts’ => -1,
    ‘meta_key’ => ‘wpcf-sequence-number’,
    ‘orderby’ => ‘meta_value_num’,
    ‘order’ => ‘ASC’,
    ‘meta_query’ => array(array(‘key’ => ‘_wpcf_belongs_collection_id’, ‘value’ => get_the_ID())),
    );
    $child_posts = get_posts($childargs);
    $ret .= ”;
    foreach ($child_posts as $child_post) {
    $ret .= ‘ID).'”>’.$child_post->post_title.’‘;
    $ret .= ”.$child_post->post_content.”;
    }
    $ret .= ”;

    Can I assume that types_child_posts() will still work fine and I only need to update the meta_query part of this code to match the wp_query changes in the documentation?

    • Hi, Scott and thank you for the question!

      Since we still have some work on this API for the final release, I need to check with our Types lead developer about the types_child_posts usage and if it will require any change. I will update you here as soon as I find out.

    • Hi, again, Scott! I just talked to our lead developer and he says that this will work just fine, no need to update the code. However, you can still consider doing this using the new API, because this will be regarded as a “legacy” code, so it’s always a nice development practice to update the code with the latest code/API, if possible. Just a suggestion. 🙂

      • Thanks Dario. Sounds like types_child_posts is safe but my code still needs changes since the new query won’t work with get_posts(). I can change that part to use WP_Query() instead and I think everything will be okay.

        • Thanks, Scott, yes, if you run into any issues while doing this, our supporters will be happy to assist you!

  8. When do you think this will release? I’m in the process of setting up a website with CPT realtionships and hesitate to use the bata for the dev work.

    • Hi, Ronald!

      We are moving along fine and are aiming to release this officially in April. In your case, I think it depends on things like when the project needs to be finished. However, the current betas are quite stable, so there should be no surprises in any of the main features, especially the Types side which sets the relationships up and everything in the database.

      Additionally, there will be an automatic migration wizard, so even if you set up the relationships using the current official release, there should be no problem in migrating them after the release.

  9. Hi Dario,

    I tried the beta version with my site with existing many-to-many relations with an connecting table. The migration tool did not recognize this relationship and made two one-to-many relations. I can make a new connection no problem, but how do I get my old (670) relations in the new table? I tried with WP All import, but may be I did something wrong? Exportiong the new posttype with WP All Export gave a blank screen.

    Will this be solved in April with the official release?

    • Hi, Marijke, and thank you for the question! The thing is, existing (“old”) many-to-many relationships are actually two one-to-many relationships, and currently, there is no functionality that automatically turns them into the new many-to-many relationship. Also, there is no way to migrate the actual connections between your existing posts (670 of them) and WP All Import cannot help you with that, it won’t work.

      This is all something that we would need to add as a special feature. Naturally, we did take this into account, but it is something that requires a lot of development work. So, this will not be released with the first official version. We might add it later, but this depends on how many people actually use/need this and the feedback we get.

      However, there is one thing I need to add, regarding your particular situation:
      – Since you migrated your existing relationships, you don’t need to do anything, you can continue using them as they are and you will still benefit from all the behind-the-scenes improvements. So, by keeping relationships as they were, nothing changes, your 670 old connections will still be there and work, and you can also add new connections and they will also work normally.

  10. Hi

    Not sure if this is the correct place to post this regarding testing the beta versions of the plugins.

    I’ve been testing the new beta versions of Types 2.3-b5, Views 2.6-b3 and Cred 2.0-b1.

    I’m running them on a non-production version of my site (multisite). Running WordPress 4.6.1 with twentysixteen theme.

    (I’m still using the Toolset Twenty Sixteen Integration plugin.

    My issue is that in Custom Fields, when I create a new Post Field Group and try to “Add New Repeatable Group”, it doesn’t work. It simply doesn’t do anything.

    Using inspector, I can see that clicking “Add New Repeatable Group” button results in an 500 nternal Server Error.

    • Hi, thank you for reporting this! I just forwarded it to our testers to see if they can find why this is happening. As a side note, I find it peculiar that you are still running WordPress 4.6.1. Any specific reason for this?

      • Hi, again! I just got word back from our tester and he was not able to reproduce the issue. He used a setup with things you described (WP 4.6.1, multisite, those beta versions, and the Twenty Sixteen Integration plugin), but he didn’t encounter the issue you described.

        Could you please open a ticket in our support forum about this, and share a duplicator package of your site with our supporters? This should help them to reproduce the issue and from there, we can see what the problem is.

        Thank you!

    • Hi, Juanjo! Currently, it is not possible to migrate old many-to-many relationships to the new ones. This is because the old many-to-many relationships are actually a set of one-to-many relationships and this is what you also get after running the migration wizard.

      However, it should be pretty, after migrating, to manually set up the new many-to-many relationships between the migrated (old) post relationships in your site.

    • I did understand but we have almost 700 posts linked with more than 1000… I think its a lot of work to do it one by one.

      I just put this in the blog because you said ” So, this will not be released with the first official version. We might add it later, but this depends on how many people actually use/need this and the feedback we get.”. I use/need this and so here you have my feedback.

      A question… is it possible to have the old posts with one-to-many with intermediary post relation and new ones (those created after the installation of the new version of the plugin) with the news one and keep all working?

      • OK, so you cannot use the old post relationships together with the new ones as you described because the way you display data from related posts is different. In this case, if there are too many items to manually re-connect, the best workaround would be to do the automated migration but keep using the old post-relationships just as you were. It will not be ideal, but you will still see some benefits from the refactored post relationships.

        However, you are right, this is a usability issue and we are working on resolving it. I cannot say when, but our lead Types developer is well aware of this issue.

        • Loaded up the beta today – which looks amazing! But that was my first immediate concern as well. A migration tool for m2m relationships would be a HUGE time saver.

          • Thanks, John! We are looking into this and need to see how big a project this would be to implement.