Preview: Ability to Relate Content to Other Content Items - Feature Previews & Betas - Feature Previews & Betas - Progress Community
 Feature Previews & Betas

Preview: Ability to Relate Content to Other Content Items

  • @Kali
      Can I add one more to the list for this...same lines...a manager method to return "Random Content" (with take count).  Even if it's just a wrapped version of what Tim suggested on g+, at least its a single point that we can all use that could be optimized by telerik if need be.

    ...single method shouldn't take much time with no UI component
  • Hi all,
    Thanks for the detailed responses. The updated wireframes for this feature are
    on this link:

    My feedback on your comments is below:
    @Daniel: I confirm that the example you provide in your post will be met.  We are planning to
    cover Pages but at this point it is not 100% that they will make it for the 7.0 release. If not, they will be released one month later, in April. As to the content selectors, once these are done we can distribute them in a custom build here in this thread.  


    2)  content deletion cleanup of linked items was included in the specs, thanks for the note.
    3) On the user picker, this option is also in the plans, but not 100% for the release in March. It will be included in the next iteration. 
    4) a relate content "Forms" widget was logged as a request for future
    iterations as well . Thanks, it seems very usable.

    Permissions will be taken into account when displaying related items in the
    front end.
    Question: What about the backend? If a user cannot view “news1” should he be able to see it as related item under “event1” in the backend or should it be hidden?

    As to hierarchical relationships, related fields will not be appropriate to use for such purposes. Hierarchies are special in that relationships there are two sided (item1 and item 2 are related in way that item 1 is parent to item 2, and item 2 is a child to item1). Very often in hierarchies you want a deletion of a parent to delete all children. Also you want permissions set per parent to be inherited by all children. This is why we prefer to treat hierarchies as a separate feature from related data.  The major restriction of the current hierarchies seems to be that one parent content type can have only one child content type. We can remove this restriction and allow for multiple children
    per parent.
    Here are sample wireframe for this feature:

    I confirm that there will be interface for picking custom content type data in the interface.

    @Amanda Shafer:
    On the question if “the user will still be able to edit them through their own
    content item page”:  I confirm that Presenters will be edited in the Backend Screens for Presenters and users will not have to go through “Sessions”. Later this week, we will present the
    wireframes and you will be able to see the exact user flow.

    The comments on your requirements are with >> below:
     “1) make sure you can relate to the same
    content in a hierarchical fashion”
    >> This feature was added to the plan. It will be included in some of the
    releases after 7.0.  
    2) Limiting the amount of items a user can relate to a content item
    >> Admins will be able to if one or many items can be related.
    3) ensuring that this related data information works when you export a dynamic
    >> this was included in the spec, thanks!
    4) media selector field to a custom module
    >>  I confirm that this will be possible.
    5) Bi-directional
    >> This will be possible.
    6) Well tested.
    >> We are not planning to rush on this feature.

    @betty, Steve:
    We will try to insert those so called automatic relations for the 7.0 release. Users will have to insert those widgets on the widget templates of the content widgets and specify the parameters based on which to display them. Steve, we will make sure random content can be generated as well.  

    @ gregory hernandez – I confirm that duplicating forms will be included in 7.0.

    I have some additional questions for you:  
    >> Related items will be shown in a section of the
    edit screen:
     We were discussing internally that this placement might not be very suitable when
    dealing with a big number of related items. What is your opinion on this placement?

    Thanks for your feedback,
  • 1) Linking to drafts is a must, however feel free to have a dropdown next to the 'narrow by typing' on the selector that lets you filter by published status.

    2) Most of the time i'd want to be able to go either direction on a relationship - on a presenter i'd like to see all the sessions and on a session i'd like to see all presenters. 

    3) I'd probably just use multiple fields for this (eg a presenter and a helper field).  However in my current project I do have the need for something like this, our client wants to be able to add new roles/titles for a presentation then associate a person to that presentation.  This is a fairly advanced situation in my view I don't think it needs to be done in phase 1.  However rather than a category for the relationship I think i'd rather (somehow) be able to add more than 2 items to a particular relationship (example relate a Presenter, a Session and a Title as one relationship).  Again this is a fairly special case and I could probably come up with a work around

    Another sudden thought/question  is how self referencing entities will be handled, If I wanted to add in a manager hierarchy to users how would that work?  I'd almost expect 2 fields on a user (Manager and Direct Reports) but it would be nice if they somehow could automatically update when needed (eg change user A's manager from B to C i'd like the direct reports field to remove A for B and add A for C).
  • Thanks for taking the time to respond!  In regards to permissions, we expect our front end users to be external website users authenticating with a different provider and have zero access to the back end. These external users would have varying access to one of 50 different publications we offer based on their subscription, which we would provide with a custom membership provider.
    We expect the back-end to authenticate using Active Directory, and this credential would be exclusive to back-end access, completely different from front-end access.
    I hope this answers your question - if not please elaborate.

    As to hierarchical relationships - my use case would be as follows:
    I have a content module item with a parent and 5 children - think of it as a page in a publication, like
    This content module item displays HTML content of various kinds and data and at the end displays a list of related authors and/or related articles.  Like the "See Also" at the bottom of of the linked Microsoft example above.
    But the "See Also" items I want to relate are different custom content module items of a different type, and also the same type.
    That's what I'm trying to accomplish.
  • @Kali
      I totally missed that mockup link! :D

    -  Can you let me specify\modify the kendo template used to render the items?...some dynamic content is more image-based, makes more sense to look like products, or we need to show more data than just the title.  I'd like to be able to tweak that if I could.

    -  Re: Placement question: I'm fine with that being there...I mean from a UI perspective at least it's consistent...probably something you could do to make it show lots of items, tabs, scrollbars, whatever....I'm sure you could come up with something.  Where else would it go?  It would be really sick to also show the items which share the taxons as well , but I realize that might not be on the roadmap (as it exists on the taxon).  I like how this shows draft items as well.

    -  Do we have to have a show more button on the related item itself?  I don't know about other people but even on our content heavy site we're not adding more than a handful of items, and I would want to see them all listed there...wouldn't want anything hidden behind a showmore button.

    - Re: Content Picker - I assume the language will be hidden if we're not multi-lingual?...and custom taxonomies will be in the filter, not just Tags and Cats (likely just the exampletext right?)

    This is great :)  
  • @Don ...and you don't want to manually link the other items, they should be pulled via shared taxons, right
  • 1. I can see a use for being able to select Draft items. Especially if it's something like related news stories. You might not be ready for the story to go live yet. But once you do, and you publish it. You don't want to have to go adding it to anything it should be related to after the fact.

    2. My gut reaction is that everything displayed should be consistent. Either the two items are related or they are not. No matter where you look, you should see the same data.

    3. A categorical relationship would be great. It would be a welcome addition. However, I don't know that it's a must for phase I. I feel like it would be better to make sure the core product is working first before adding extra bells.

  • 1) Yeah, need drafts\ amanda said, don't want to go back or remember to re-edit.  HOWEVER like I mentioned above, please remember to test deleting those items, backend and frontend.  Like if you link presenter1, presenter2, presenter3...then in the backend someone deletes presenter2, the "links" to it get resolved and deleted or handled and nothing is throwing errors.

    2) That is a weird case, would be strange to hard link it on both ends.  However if I did do that for some reason, I would hope it wouldn't be removed on both ends...or at least that cascading would be configurable as a behaviour.  Does anyone have a use-case for doing such a thing, maybe that would help illuminate?

    3) I'm not following this one?  With the current version (and using thunder) I would have 2 single select Guid custom fields for Main presenter and supporting presenter (or supporting as a Guid[]).  I wouldn't expect to have functionality like products where I can change the status of one right there...although it would be a nice to have.  Am I missing the boat here with the question?
  • Hi all,

    First, let me walk you through the latest version of the wireframes using a sample use case:

    1. User creates two Custom Content Types: Presentations and Sessions
    2. User goes to Presentations, adds a custom field of type Related Data and selects “Sessions” (wireframe:
    3. User goes to Backend>Presentations and clicks to edit “presentation1”
    4. On “presentation1” edit screen user sees all sessions related to this presentation in a newly added section “Related Data”(wireframe:
    5. User can select to associate more sessions to “presentation1”, for example I can relate “session1”by clicking on Add or select Sessions

      (wireframe: )

    6. On the front end, the detailed page of “presentation1” page shows a list of related Sessions with links to the public pages of sessions (wireframe:

    In a simple case, this is how related content will work.

    However, there are some features on which we are deciding on and will need your opinion:

    1. In step 5 above, should user be able to select from Sessions with status different than published?

      Our initial assumption was that users will be linking to items in order to display them on the site. Therefore, if a sessions is not published (i.e. draft) it would be confusing to allow to user to link to it, as this link will not show on the site. However, there are cases when users might want to relate to draft items. What is your opinion?

    2. In the case above, what should happen if I add to Content Type Sessions a Custom Field “Related Data” which relates to Presentations?

      From this moment on, in Backend>Sessions I will start seeing all related presentations to a session. So, on the edit page of “session1” I will see all related presentations. But “presentation1” was already related to “session1” in step 5 above. So, do you expect to see “presentation1” as relate data for “session1”? What should happen if I detach “presentation1” from “session1”. Should that be reflected on the “presentation1” edit page as well?

    3. In your opinion, should relationships have a type to differentiate between them?To illustrate: “presenter1” might be the “main” presenter for “session1”, but he might also be “supporting” presenter in “session2”. In short, presenters might be related to sessions more than once in different types of relationships. Do you think this is MUST for phase I?


    We look forward to hearing from you!

  • Hi all,

    And thanks for the valuable feedback. A quick follow-up is below:

    On 1) Per your feedback, we have added the possibility to relate to item in any status (not just published).
    On 2) When two items (X and Y) are related, the relationship b/n them will be visible from both sides.  So, in the Backend, the edit page of X will show the link to Y, and the edit page of Y will show the link to X.
    On 3) To handle the scenarios when one content type is related to another content type via more than one custom fields, we decided to store the name of the field as a parameter of the link.

    Let me illustrate:

    1. There are two dynamic content types: Sessions and Presenters
    2. In Sessions I add custom field named “main presenter” which links Sessions to Presenters
    3. In Sessions I add another custom field named “supporting presenter” which links Sessions to Presenters
    4. Users editing a session will be able to select a main presenter (stored in “main presenter” field) and supporting presenter (stored in “supporting presenter” field)

    All relationships records will be stored in a table. For each relationship we will store the linked items and also the custom field via which they were related.

    So, in the case above, we will make two records:

    • For the link b/n session1 and presenter1, via field “main presenter”
    • For the link b/n session1 and presenter2, via field “supporting presenter”

     Thus, in the front end, when you are retrieving the related presenters for a given session, you will be able to specify whether you want to show the presenters associated via “main presenter” or the presenters associated via “supporting presenter”

    Let me know if that makes sense.

    Betty, on your question about hierarchical self-referencing relationships, in this iteration we will not cover this scenario, but it is on our list for next iterations. We will however, allow for self-referencing relationships that is flat. For example, for a given Product, user will be able to specify other related Products.

    Steve, I confirm that deletions will be handled properly. Thanks for the note.

    Thanks for your help and feedback. Let me know if you have other questions that we can address.


  • I would expect option 1 in most cases.  Typically we setup structure etc when defining the English content then get translators to come through later and just edit individual content items, this means they don't need to understand how the site works and don't need to setup relationships.  Massive time saver.

     The only case I can think of where option 2 makes sense is where the data in the two different languages isn't a direct translation of the other - eg related contact details directing you to someone who can speak your language. So it could be useful, but not a massive time saver like option 1.

  • Hi all,

    We are making a steady progress with the Related Content implementation, and we are planning to have a beta build including a preview in the coming weeks.  Details will be announced.

    I have one question to you in regards to multilingual support for relating content: When you relate an item which is translated to other languages, do you expect the relationship to extend to all translations of the item, or only to the current translation you are working with?

    Let me illustrate with an Use Case:
    1) I have a project with these languages: English (EN), German (DE), Spanish (ES)
    2) I have custom content type “Presentations” with item: “prEN”, which is translated to “prES” and “prDE”
    3) I have custom content type “Showcases”, with item “scEN” which is translated to “scES” and “scDE”
    4) I relate “prEN” and to “scEN”.

    Option 1:
    5) Automatically, “prES” is related to “scES”, and “prDE” is related to “scDE”.

    Option 2:
    5)   “prES” is not automatically related to “scES”, and “prDE” is not automatically related to
    “scDE”. For each language, I need to relate the items separately.

    In your practice, which of the scenarios makes more sense?
    I look forward to receiving your feedback.


  • Betty, thanks for the feedback. That was very helpful.

    Hi all,

    We have a question on Relating to Pages. This seems to be a popular request and we are interested in collecting scenarios in how this feature will be used. Can you provide us with examples from your practice when a content item was linked to a Page. How were the linked Pages displayed on the public site?  

    Currently, there is workaround for achieving linking to Pages. You can add a custom field of type “Long text” to “News”.  Users editing a news item will be able to insert links to pages via this field by using the HTML editor (in HTML users can insert links to pages). This will result in generating lists to pages on the news frontend. Can this work?

    Thanks in advance for your feedback.


  • Hi all, we are currently writing a script for migrating items from Thunder generated Dynamic Items Selector field to the new Related Data field in Sitefinity 7.0. For testing purposes we need some real case projects with dynamic selectors. Should you be a volunteer, please send us your project in a support ticket, and your database.
    Please make sure the project can be build and easily setup. Thanks!
  • Sitefinity 7 goes in live. How can I implement this ability in custom types in custom module. For example, I'll try to implement SlideShow widget in custom module that will use  are custom content types SlideShow (with fields Title, Description, PreviewImage, etc.) derived from Content class and SlideShowEntry (with fields Image, Description, etc.). Please, give me any related example project or sample code of field definitions for backend views or link to any related blog or other help information.