Release Candidate for Toolset’s Post Relationship

   Amir

Announcements

April 26, 2018
66

We’re ready with a release candidate for all Toolset plugins. This should be the last version before a production update, very soon now.

As we get closer to the production release, the number of changes is going down. In this release candidate, we focused on completing the last remaining functionality and mainly polished up everything.

CRED plugin becomes “Toolset Forms”

The name CRED stood for Create, Read, Edit, Delete. Unfortunately, this name was clear to us and to a small part of our clients. To the rest, it was just another name to learn. To make Toolset easier for everyone else, we’ve rename CRED to Toolset Forms.

A bunch of usability improvements

We’ve been running usability testing on Toolset in the last few months and we’ll continue them in the following months. Our aim is to find places that hurt usability, improve them and let you use Toolset with a lot less stress.

Our aim is:

  • From zero to mastering the basics in 45 minutes – new clients who’ve never seen Toolset before should be able to create their first templates, Views and archives in no more than 45 minutes.
  • Advanced topics in under an hour – things like creating a custom search, displaying results on a Google Map, front-end editing forms, etc. Each of these, to learn completely from scratch, should take under an hour.

When we started these rounds for the basic functionality, we measured around 60 minutes. We already implemented a number of changes to the GUI and documentation. In the next round, this week, we’re aiming to see people succeed in under 45 minutes.

Support for CSV import with post relationships

Types 3.0 offers advanced post relationships, which we’re storing in a custom table. This creates a challenge for content import because import plugins can only create post-meta (custom fields) and taxonomy.

To overcome this, we’ve created an importer tool which will convert from post-meta to Types’ custom table. You will be able to specify the post-relationship information in the CSV file, import it in one pass and Types will set the correct relationships between the imported posts.

This approach has a number of benefits:

  • It works with all CSV importer plugins.
  • It allows you to set both simple and very complex relationships.
  • It allows to import all the content, including parents and children, in one pass.

Importing Content From CSV, with Post Relationships »

Download and try

The list in this post is nowhere near complete. This release candidate includes heaps of new features, usability improvements and bug fixes. The best way to see them is to try the beta.

You can download it from your Toolset account. Click on Downloads, switch to Beta and download.

We’re starting QA now and we expect to release the production versions in about two weeks.

Feedback?

Tried the RC? Let us know how it’s working for you and if you ran into any problem. Many of the improvements from previous betas came from your feedback. We appreciate the time that you already put into testing betas and we hope that you’re happy with the way it’s going.

The entire Toolset team is looking forward to reading your comments!

 

Comments 66 Responses

  2. Way to go. The improvements sound great as do the name changes, they make a lot of sense, I did not know what Cred meant. I have 3 projects which need repeating field groups. If I install the beta plugin will I be able to upgrade when the final plugin is released? Thanks in advance. 😉

    • You can start building sites with the current betas (from today). At worse, there could be some glitches (which we want to know about and fix), but we’re not going to make any changes that will break backward compatibility.

  3. “CRED plugin becomes “Toolset Forms”” – This is a positive move and will likely make things easier for new users.

    “A bunch of usability improvements” – Excellent! It’s very important to make Toolset easier to use, it’s quite daunting to start using it as it’s just so powerful.

  4. Dear Amir,

    Really excellent news one thing please can you make the:
    -From zero to mastering the basics in 45 minutes.
    -Advanced topics in under an hour.

    As Step by step getting-started videos to show as a case study for all Toolset features.

    With Thanks,
    ArabsW

    • “As Step by step getting-started videos to show as a case study for all Toolset features.”

      This.

    • Yes, should work fine. You will need to create a CPT for each of these and then connect them using the new Toolset->Relationships.

  6. This is SO exciting! I’ve been holding off implementing the many-to-many relationships in my world-changing pioneering web app until 3.0. So…. just a note to say thanks for all the hard work. 🙂

  7. Really great Amir! How can we update from previous versions. Downloading and replacing files with ftp? Ther is no option to update from wordpress admin. Thank U!

    • First, I don’t suggest to use these betas on production sites. If you’re using them on development sites that you’re building now, it’s fine. We’ll be done with QA in about 2 weeks and then it’s fine to use on production sites. We’re not updating our sites to this beta yet also.

      While it’s in beta, like you wrote, you need to download the ZIPs, place them in your ‘plugins’ folder and unzip there. The safest process to update plugins manually is:

      1. Deactivate the plugin(s)
      2. Delete the plugin files from the ‘plugins’ directory
      3. Unzip the new version into the ‘plugins’ directory
      4. Activate

      Deactivation and reactivation doesn’t modify the data, so it’s safe to do.

  8. Great news! I noticed the downloads cover Types, Views, Layouts, and CRED. Should we leave CRED Commerce, WooCommerce Views, Access, and Maps in place using their current live versions? I’m assuming yes but just want to double check, as I’m guessing some of these plugins talk to each other? Thanks for the confirmation.

    • Hi Aaron

      Thanks for the feedback.

      CRED COmmerce, WooCommerce Views and Maps will get also updated along with the four main plugins for the final, official stable release. For now, it should be safe to use their existing stable releases, although there might be some glitches (like the position their shortcodes group take in the Fields and Views dialog, for example). Nothing should be broken, just maybe a little off.

      Hope it helps.

      • Thanks, this is helpful. I will proceed with updating just those 4 plugins and wait for the final release for the others. Backing up the site now and moving forward!

  9. Love it!

    Just wondering if there are any plans to be able to include multiple relationships in one intermediary CPT?

    E.g.

    Course
    Module
    Lesson

    Lesson can belong to many modules and many courses – rather than creating a second relationship, append the lesson module relationship with the ability to specify the course.

    Is this currently possible and I missed it? Or something that might be considered for the future?

    Love what I’ve seen so far, thanks!

  10. Where do you want us to report any glitches we discover (here or via a ticket)? A distance filter shortcode is no longer working on one of my views.

    • HI there

      It would help a lot to get those reported in the forum, using a ticket. Just make sure to state clearly what versions are used for the plugins involved.

      Thanks in advance.

  13. In my site I have lot of relationship tables. I am really afraid to update with the new version and I don’t understand well how to change and modify the tables and the relationship

    • Types plugin will migrate the relationships for you. It comes with a migration tool just for that. We’re about two weeks from the production version. If you’re moving a production site, I suggest to wait for the stable release before moving your production site to Types 3.0.

  14. The import functionality is going to be a game changer for us. A great step forward. Now time to wrap my head around how to use it. As a visual learner, a video tutorial would be awesome.

  15. Thanks. I have an issue on a development site that was started with earlier versions of these betas that I was hoping would be resolved in this release, but isn’t. When I go to an individual custom post type and try to add a connection using “Connect with existing…” through a many to many relationship I built, the Save button isn’t clickable even if I make a selection. I was able to make connections in a previous version of the betas, and those work.

  16. I’ve just downloaded and installed the latest version and it appears that I am unable to set relationships between the same custom post types. Will this be possible with the newest version?

    I’m building a motor vehicle database and would like to show “related vehicles” in a sidebar widget when viewing a vehicle.

    • Yes, in this release we haven’t yet implemented relationships between the same post type. It will come soon next, but not yet in Types 3.0. You can definitely set-up “related posts” for motor vehicles using both the current one-to-many and many-to-many relationships. I’ll be happy to explain how. If you’re interested, please create a thread in our support and add a link to it here. I’ll take that thread and explain there in details.

  17. This is excellent stuff, thanks guys! Really got my fingers crossed for support for intermediary post type fields in views. They currently do not render and I could really use this functionality on something I’m putting together. Any idea when this will be baked in?

    • Hi there

      Thanks for the feedback. Well, I am not sure I do follow what might be happening here, because intermediary post fields should be available for usage in Views already in our latest beta package. Would ypu mind to elaborate what is not working and what is your setup?

      In advance, let me explain what is needed to get those fields. Views can list the intermediary post type itself, and in that case, they should be rendered right away. Intermediary posts are first-class posts, and their fields are regular fields, so when the View lists the intermediary posts, their fields are just like native fields for the current post. No problem in this case.

      Now, when your View lists one of the sides of the relationship, this is different.

      Imagine a songs-to-albums relationship, with an intermediary post named tracks with a field named track number. You have a View that is listing songs, and you want to show the track numbers. But you can only show those track numbers of songs when you know which album you want to display data from. Otherwise, the same song might have a different track number in different albums. To decide which album you want to get songs and tracks data from, you need to add a filtre by post relationship to this View.

      Hope it makes sense. Let me know anyway what is not working for you and we will sort this out.

      Regards.

      • Hi Juan,
        Thank you for your response. I did a little bit more testing and I got this figured out. I had everything set up appropriately (including the query filter) except when I inserted the intermediary post field, I overlooked the Post Selection options for that field to use “A post related to the current post, set by a Types relationship”. I set this to the appropriate relationship and all works well. Thanks again for your response and the stellar product!

  18. It seems that we can’t “quick edit” date fields of child posts directly from the parent post edit page (fields remains grey and can’t be selected)… I haven’t tested every type of fields, but it works well for single line and select fields.
    Does this limitation for the date fields can be solved in the future?

    • Hi Sebastien, thank you for reporting this issue. We’re already aware of it and working on making all field types work properly. In the next release, Types 3.0, it will be fixed.

        • Hi Sebastien

          We just released an updated release candidate for Types that should include a solution for this issue.

          Hope it helps.

          • Thanks Juan, it works now indeed but… in the back-end only…
            And by the way, it seems to be unrelated to relationships as I can’t output dates field in a simple view listing fields of the current post type..

  19. Hello

    Thanks for creating relationship. I am testing for a network of tourist guides sites of small destinations in Chile and I find myself with some doubts.

    I have ordered with custom post types:

    Activities
    Attractions
    Accommodations
    Gastronomy
    Locations

    Create a relationship of one is to many. For example, a locality has many attractions.
    Now I have created a shortcode in a view that filters the attractions in a specific locality and that shortcode inserts it in a new page created by myweb.com/atractivesofthelocality. Until here everything perfect.

    The problem exists when I want to do this on a large scale, according to this example, I have to create one by one the views to show on a page attractive in a locality, or activities in a locality or etc, in a site that has more than 100 locations its a big problem.

    Is there any way to create 1 single view for example of attractions in the locality, and in the shortcode or other place to be able to change what custom post types should show ?. Or can I create an attractive view, but in the shortcode can I change which location I want to show the entries?

    So far I have only encountered examples of displaying custom post types entries depending on where the shortcode is located. For example insert the shorcode in the entrance of the locality filtering the view so that it shows the results according to where this insert.

    I hope you have understood me.

    From already thank you very much

    Sorry for my English

    regards

    • I hope that I understand your explanation correctly.

      You should create a template which will be used for all the localities. Into this template, insert the View that shows the attractions of the displayed locality. This way, you only design it once and it works for all.

      If you have different designs for groups of localities, you can create several Content Templates and assign the right template that you want to use to display each locality.

      Will this work for you?

      If you need more help, I recommend to create a support ticket. There, you can give us more details, include screenshots and links. Our support team is fully trained on the new features in Toolset, so they can help you with practical solutions.

  20. I have relationship between destinations & flights (one to many), and made views to display flights for spacific distination (using filed calld CODE), so I made filter for that but it was show nothing.

    • It’s hard to know why nothing shows. Can you create a ticket in our support forum, show screenshots of what you’re doing (the View setup) and our supporters will help?

      Could be that the View is not choosing the right data or you haven’t set the correct “post selection” for the fields. Most likely it’s the later. Remember that when you show fields that belong to a different object, you need to select which object you’re referring to.

  21. forgive me if this has been covered in previous comments or posts but looking at this beta, you cannot have a cred form that allows a user to create a new post with normal fields and grouped fields in the same form? It looks like you have to have a separate form for the basic fields and one for each of the groups of fields? why is this?

    • Hi there

      Thanks for the feedback. Not sure if this topic has been covered here, but for sure we are aware of this.

      If you look at how repeatable field groups work in the backend, you will notice that you first need to save a post before being able to add any instance of that group. You create a new post, save it, and only afterwards you can add a new group of fields to it. This is because the group of fields needs to belong to a given post, and until you save it, there is no post to save.

      This is what happens in the backend, and it is a smooth workflow because after you save the post you are still in its editor page. But in the frontend things are a little different.

      In the frontend, you have a form to create a new post. If you were able to add groups of fields right there, there will be no post to attach them to, yet. Only after you save the post those groups of fields make any sense. But by the nature of frontend forms, once you save the post you are in a different page, and not editing the post itself, hence the workflow is broken.

      We will work on this apparent paradox after we have a first stable release. We are considering a couple of approaches to let you dd groups of fields right away from the form to create a new post, bu all of them have problems that we need to solve.

      Hope it helps.

      • So effectively the process is no better than before for front end forms then. Its very disjointed when having to have multiple forms and ask the user to link each form with another post.

        Still a right move in the right direction but now wondering how far off a fully working implementation will take.

        i was under the impression the grouped fields would work in a similar way to advanced custom fields solution, without the need to save a post first.

          • Hi there, Joseph and Peter

            Our solution is quite different fro the advanced custom fields one. As they state i their documentation, they keep all the data in the postmeta table, and play with suffixes to store it in a convenient way. They have an API to get the data and render it – manually.

            We decided to be a little more performant and manage things under the hood like the seem to be: with a relationship. This means that the data management is more robust and the database interaction is cleaner, also when deleting elements. But the downside of it is that if you want to allow defining groups of fields before having an actual post, you might end up with “orphan” groups that belong to no post if you just abandon the mentioned post before saving it.

            So it is a trade-off, but one that we know how to change if required – we would need a garbage collector to clean up orphan items from time to time. Afthough I tend to not like this kind of solutions, we can implement it if we get enough feedback in that direction.

            Hope it helps.

            • So what is the process if you have field groups? My idea is geared around clients inputting their own content. Can you point me to documentation on this?

            • In response to Jon Kay below – it seems as though you can’t add a new post using CRED with field groups.

              In my opinion, this ‘field groups’ is not complete yet and needs lots of work.

              Whether its front end with CRED or back end through the CMS, the parent post has to be saved first before you can then add values to the grouped fields. This is cumbersome enough in the CMS but basically unusable with front end CRED forms as you have to have multiple forms. One to create the parent post and one to add data to the grouped fields. And im assuming the one with the grouped fields will need some way of determining which parent post they belong to as well.

              For how long this has been in production, i have to say its pretty disappointing. I think a lot of people were hoping for a solution similar to ACF’s grouped fields and repeater grouped fields which lets face it, have been around and working well for a long time now.

            • Hi Jon and Joseph

              As I stated above, our solution is quite different than the one in ACF. We do not have the luxury to do things that way, because we do need to care about how elements work with CRED forms, with Views searches, and with WPML.

              This is especially relevant for Views. If we were to store field values in prefixed postmeta keys, Views would not be able to even discover those fields.

              We have docs on how to create instance of repeatable fields groups:
              https://toolset.com/documentation/getting-started-with-toolset/creating-and-displaying-repeatable-field-groups/front-end-forms-for-repeatable-field-groups/

              I would recommend you to do as follows:
              * Create the form for adding the post XXX, and set it to redirect to the post after submitting.
              * Create the form for adding the repeatable field groups to each XXX, and make sure that the shortcode used to render the parent selector gets a value of the shortcode wpv-post-id`which means that it will default to create a repeatable field group for the XXX post where this form is included. Make sure it is set to keep displaying the form after submit, and that it reloads the page (no AJAX submission).
              * You can also create a View to list the repeatable field groups, and add a query filter so it only return groups that belong to the current XXX post where the View is shown.
              * For that XXX post type, create a Content Template and make sure it includes:
              ** The XXX post body, so the post itself is rendered.
              ** The optional View, to list all the already existing repeatable field groups for each XXX post.
              ** The form to create repeatable field groups for the current XXX post.

              Now, every time you create a new XXX post, the form, after getting submitted, will redirect you to toe XXX post. It contains the post body, and afterwards te form to add a repeatable field group. If you fill that form and submit, the page will reload, include the group you just created in the View, and display again the form to add another group.

              I can agree that this is still not in the final shape that we want it to be. But it will get there. I am sorry if this is not there yet in terms of usability, but considering the numbers of features we are including in the next release, we consider that it is better to include a way to do this, even if not perfect, than holding it. I mean, we are getting proper, pure, powerful relationships (with support on Views filters and frontend search, even chained relationships, and with support on frontend forms), we are getting post reference fields (long demanded), we get repeatable groups that can be saved and displayed i the frontend, and created in the frontend, yes, even without the most convenient way.

              We do know there are things left. Improving this mechanism to add repeatable field groups is one of them. We are evaluating strategies already to get this better. But we are also not including setting many related items on a frontend form: you can only set one related post if the relationship is a one-to-something. Because we did not find a suitable, really usable way of doing it without delaying the development cycle.

              Hope this helps.

            • Thanks for the suggestions Juan.

              No complaint about the support from you guys thats for sure.

              Also, it’s worth noting that whilst i feel this particular feature’s rollout is disappointing in my specific use case, I appreciate that your product has to cater to many and am overall a very happy customer.

              I look forward to seeing these new features rollout and evolve.

    • Hi Rickard, thanks for the feedback.

      No, this feature will not be included in the first production, stable version for the post relationships. We have plans to maybe implement it in the future, if we get enough feedback about it. Yous, of course, counts. This is a quite complex feature to include, and one that has potential to be both quite powerful but also quite expensive in terms of database interaction. So even if we decide to go on with this we still are not sure about the best strategy to take.

      Hope it helps.

      • Hmm.. Would it be possible to put some fields in the post relationship instead of the parent or make inheritance in some other way?

        It is a pain to copy paste the same fields from parent to child when you have hundreds of parents and each have a ton of children.

        • Hi Rikard

          Relationships of the kind many-to-many can indeed hold fields. Those of kind one-to-one or one-to-many can not, because the intermediary link has no proper entity that the sides of the relation can not cover.

          Anyway, this will not solve the problem. The main bottleneck here is that filtering or sorting by data of another element is expensive. In other words: when listing children, it doe snot matter whether the field belongs to the parent or to the intermediary relationship item: as long as those fields are not from children themselves, the only strategy we considered for now to support using them for sorting or filtering means long queries and performance penalties.

          We are brainstorming the best way to have this soted out, and we plan to try to include it on the first iteration after the upcoming stable first release. We do nto want to delay the whole first release because we can not do everything we want to do at once.

          We knot is is a problem to duplicate fields. Indeed, it is more than a pain: it is wrong. Data has meaning, and putting data where it does not belong produces problems in the long run. We will try our best to have a proper solution for this.

          Hope it helps.

  23. Any news on the Production Version of 3.0? Just about to implement many-to-many on a site and holding off… Thanks x

    • We’re completing the QA during this week. So far, we’re around 70% done. We found a number of small problems and updated the betas with their fixes. So far, we’re on schedule to release the production version next week. If you’re building a new site (not updating a production site), you can use the betas.

        • I’m sorry, but we’re not. We did a full “dry run” on our sites this week and we found show-stopper problems with the migration process and backward compatibility. These problems will likely affect only a very small percentage of Toolset-based sites, but we still want to handle them before we release a production version.

          If you’re building a new site now, the betas are absolutely fine. For a new site, there’s no backward compatibility problem.

          The risk is when you upgrade an existing site. We found issues with WPML compatibility, checkbox fields and get_posts queries in PHP. We’re handling these right now and we’ll run another full round of tests on our sites.

          Fortunately, our own sites use all the features of Toolset, combined with WPML, other plugins and lots of our custom code. This allows us to find corner cases. We should have run these tests earlier and avoided this delay.

          We’re doing our very best to have everything ready for Monday. Anyway, we want our own sites to be running on this new release before we release it for clients.

          Again, sorry for this delay.

  24. I just created my first relationship. I first created two cpt’s “Topic” and “Antwoord” and then I created a one-to-many relationship between the two. I followed the wizard and chose all the default steps. In the last step I followed the suggestion by the wizard naming the slug “topic-antwoord”. After finishing I got an error message: An error when creating a relationship “”: No relationhip with slug “topic-antwoord” was found.

    • I tried this several times. The wizard gets stuck in the step Relationship fields. When I click on the Finish button I get this error. No relationship is created.

      • Hi Erik

        Thanks for the feedback.

        If you do not mind, I am contacting you privately to see if we can find what is happening here.

        Regards.

  25. I’ve gotten a chance to migrate several complicated sites to the RC. Kudos to you all on how relatively smooth it has gone. I wish I could say the same for WooCommerce migrations.

    What WOULD be helpful in WordPress Intermediary Posts Admin Listing if the relationship was shown as a columns (like title, date). This would eliminate the step of duplicating that information in the title or adding a custom field. It would be a real time saver when you have hundreds of posts.

    • FYI – This was also the case under the old relationships where you had to build the many-to-many yourself. But now that it is more automated, it would be helpful (and cleaner) to not have to duplicate content.