Preview: Ability to Relate Content to Other Content Items

Hi all,

Now that 6.3 is out, we are starting the work on 7.0 which will preserve the focus on the most popular community requests.
Below are the first ideas on feature: “Ability to Relate Content to Other Content Items”.

• This option will allow you to easily setup any content type in Sitefinity to relate to any other content type using custom field “Related item”. The initial prototype for this field is here.
• Once “Related Item” is added to a content type, editors editing content items in the backend, will see option to select and link to other content. The screen for selecting an item to link to will be similar to this one here.
• On the public site, related content will be displayed in the Content Widgets of the respective content type as lists with links showing under the content items.
• Sitefinity will offer the ability for users working with the HTML editor to insert link to any content item on the site (we allow linking to static pages only now).
• The CMS will store statistics for linked items.

As you can see, our ideas are still in rough shape and this is the right time to turn to you for more feedback regarding this feature:

• In your practice, what are the most common scenarios in which you had to relate content?
• What feature would you prioritize first?
• Will you have a case when you don’t want to set the related items to be of a certain content type, and you would like the editors to be able to relate to any content type of their choice?

Please share with us any wishes in regards to this feature. It’s Christmas time so we might as well fulfill them :)

Regards,

Kalina
Sitefinity Team

"Please give us a "User" picker option as well"

Ah yah, forgot that one. ++ for the User picker.

I know this is off-topic, but...

Any plans on providing us with a "Duplicate Form" in the same way as we can duplicate pages?

It'd be great to create an initial generic form with the usual suspects (first name, last time, MI, street, city, ..., email, phone...etc.), then duplicate that as the starting point for our other form needs.

It'd definitely saves us time!

Thanks,
Gregory

Sorry Steve, didn't want to upset things!  lol  Thanks for the points, makes a lot more sense.  I would wholeheartedly agree with your forms point.  We're doing more and more with forms, and I can easily see where relating with content items would be handy.

Hi Kalina,

I'm working with an early prototype of this feature and it is very handy. I often add custom fields through code. A few examples:

- Image field in a Sitefinity User Profile
- Dynamic Content Selector in a Sitefinity User Profile
- Dynamic Content Selector in a News, Blog Post or List item
- Images, Documents etc. in a News, Blog Post or List item

So yeah, I can easily think of many purposes which I now do by hand.

A VERY IMPORTANT THING HERE would be to have the ability to also include Pages as a type. So you want to relate a Page to any other Content Item as well. This is what I use VERY OFTEN.

Besides all this it is needles to say that it is also VERY IMPORTANT to have this working in a multilingual environment, otherwise 90% of my projects won't benefit from this.

So if that means it would be version 7.1, so be it. It is not of any help in a single language project.

CHRISTMAS WISH:
For the time being I really would like a decent solution to select multiple images and pages in a multilingual environment through a Page and/or Image Selector :)

Thanks!
Daniel

Russell!  No, shh quiet :)  Right now we **CAN'T** relate content in Sitefinity...period.  "What about thunder" you might say...well I say...
1) I have to open visual studio to generate it
2) Sitefinity is just storing a list of Guids, it has NO ability to know what "Type" those guids are for...or if they're even valid.  Like if you link content Y to content X.  Then delete content Y item...the link still exists because there's no way for SF to clean that up.

This is all about removing the need to obnoxious amounts of custom code.  Go sign into everlive and create a complex type with links between types...its super intuative and the resulting data-type is crazy powerful....with no code.

@Kali
1) I like the selected and list is separated into tabs...with tons of content (as we have) checkboxes on the same list is hard to manage.
2) Please don't forget about content deletion cleanup of linked items.
3) Please give us a "User" picker option as well
4) Since we're on the topic of "related content"...there's a big need here to have a relate content "Forms" widget so they can pull in content items to be picked on a form.

I think it is great that you are developing new abilities.  However, for my use I just don't see a use for this feature, as cool as it sounds.  I would like to hear some more use cases which might then spur my imagination enough to understand where this would be useful.

These are great points!  We would also benefit from these recommendations.

I am very interested in this feature.  We will likely have over 70,000 dynamic content items and many of them will link to others.   In some cases I envision a section of "related content" that displays a relevant list.   I would ask you to consider security in the design - for example, I could have an item related to 45 other items, but one user may only have security rights to 15, and a different user may only have security rights to 3 other items.  Fast security trimming of the list of related content would be critical for us.  Having this wired in from the beginning ensures it uses base security methods.  Building this after the fact has often been messy.

Assuming this is a parent-child relationship, it would be important for child objects to have access to the parent item, as well as parent to children related nodes.  In this way you could build hierarchy and fuel navigation using a TreeView if desired.  There should be no limit to the parent-child relationship (infinite levels of hierarchy).  This opens up a world of possibilities for large scale sites.

Finally - just to clarify - I assume this functionality would be accessible in the UI (not just in code) for custom dynamic content modules created, not just pre-built ones like newsletters.  It would be a shame to have all this wired up but not supported for custom dynamic modules in the UI you are proposing.  And it would be awesome if it works this way!

This is GREAT news for us - I remain impressed and appreciative of all the work to constantly improve Sitefinity!

Here is a live examples of two content items related. 

We have two custom modules: Presenters and Schedule. The Schedule has a list of event sessions. Each session might have one or many presenters associated with them.  We have a list of the sessions (displayed as a schedule). When you click on the session, you get details on the session as well as a list of the presenters associated to it.  You can then click on the presenter to get more detailed information.

http://americaeast.panewsmedia.org/schedule-of-events/2014-schedule

The only issue we've run into with this on the front end, is that if the user clicks all the way through the presenters details, there's no way to get back to the schedule.

We also have the presenters listed on their page as well: http://americaeast.panewsmedia.org/schedule-of-events/presenters

I like the idea of being able to create, edit, and delete related content items from the parent content item screen. My question is whether the user will still be able to edit them through their own content item page.  For example, will our users still be able to edit presenters from the Presenter screen instead of going to the session they are related to.

We do a ton of this right now and currently use custom taxonomies to link one item to another in custom modules. I love seeing that it's coming internal to SF7 since we've had to jump through a few hoops to get it to work. What I'd like to see is:

1) make sure you can relate to the same content in a hierarchical fashion (e.g. we have a custom module that is called practice areas and they often have sub practices. we would like to be able to build a hierarchical list of this items and then easily bind to a radtree or something similar). If an item is related to another same content type it should naturally be hierarchical in nature.

2) Limiting the amount of items a user can relate to a content item (e.g. we have locations as a custom content and we only want a user to pick one of these for a person content item)

3) We end up doing the same thing on multiple sites so ensuring that this related data information works when you export a dynamic module and reimport it into another site would be helpful.

4) Currently we can't add a media selector field to a custom module (or a built in module) so being able to relate these modules to documents and images would be helpful (I didn't see this content types as options in your mockup, but maybe that's just an oversight). Basically we'd like to be able to pick a bunch of photos and relate them to a news item. Simple as that.

5) Bi-directional so that if I relate a couple of news items to events it's easy to show that relationship on either the news detail page or the events detail page.

6) Well tested. I'd rather wait a release to get something that just works than start promising that this is coming soon only to realize it's not really ready for primetime yet. This has happened several times and with this particular piece of functionality I want it to work out of the of the box, pretty, pretty please.

I think that's it. I'm excited for this. I think it'll mean we can start to move away from some of our custom modules for the first time, so can't wait.

I'd rather not need to link every related item to every other related item, I'm hoping that I can relate the current item to a tag/category/custom type and then show other items that are also related to that item.

eg
Blog Post -> (related to) Location
Then on the blog post details page I can easily display other items (blog posts, news, events, images etc) also related to that location.

@Kali
  I'd like to just comment on what @betty is asking for

It's a different request than the related content we've been asking for, however it's TOTALLY needed to make sitefinity behave like a modern cms.  I had to hack this into a current project so I'm very VERY familiar with the shortcomings SF has in this respect.

Lets take a blog like Gizmodo: (link: gizmodo.com/move-over-virtual-reality-is-mixed-reality-the-future-1493760473)
Okay, so the dude makes his post, categorizes it, then the "detail" view auto-populates the sidebar based on "related" items.

What's required is a few things:
1) A method on the content item itself to get related content:  So it looks at the taxons applied to the current item and returns a list of items in the same taxons. (or just 4 random)....difficulty: option to get related based on content of the item, but I realize that's maybe far off :)
2) A widget that can be placed on the detail template to populate this for us (with configurable template)
3) Ability to "backfill" related items.  Like if the blog template design calls for 4 items to be displayed, and there's only 2 that share the same taxon...then it should go up in the tree to find matching in parents, OR just get 2 random ones.
4) Ability to define a sort on the results

In SF this is a critical thing to have in like eComm where you want to drive users to related products, or a blog with related "more" reading.



Steve

Hi all,
and thanks for the extensive list with requirements! We are processing them currently and will get back to you with questions in the following days.
I am using the opportunity to wish you  a successful year, and hope that Sitefinity will contribute to that as well :)
Regards, 
Kalina