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”.
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:
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
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.
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.
"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.
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.
These are great points! We would also benefit from these recommendations.
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
@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: http://ezxjqv.axshare.com/?Page=Related_data__custom_field_
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.
@Steve:
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.
@Don:
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: http://v24ub3.axshare.com/?Page=Module_page
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.
@KMac:
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
module
>> 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.
Offtopic:
@ 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: http://ezxjqv.axshare.com/?Page=Item_related_data
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,
Kalina
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:msdn.microsoft.com/.../bb386416(v=vs.90).aspx
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.
@Don ...and you don't want to manually link the other items, they should be pulled via shared taxons, right
@Kali
I totally missed that mockup link! :D
Notes:
- 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 :)
Hi all,
First, let me walk you through the latest version of the wireframes using a sample use case:
(wireframe: http://ezxjqv.axshare.com/?Page=Content_selector )
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:
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?
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?
We look forward to hearing from you!
Kalina1. 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\scheduled...like 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?
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).
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:
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:
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.
Regards,
Kalina
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.
Regards,
Kalina
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.
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.
Regards,
Kalina
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.
Thanks.
Hi Nummo,
For your case, it will be best to use Related Media Field, for detailed description see: www.sitefinity.com/.../related-media-custom-field
Regards,
Kalina
@Kali
Where is the migration script?...any idea what the status is on that?
Hi Kali,
I'm going to create a custom module using C# project. This module I'm going to use in multiple web site projects. And SlideShowEntry should be a custom content type implemented in this module. This type should contains more data then simple link to an image. This type should contains a Description field, DisplayOrder field, etc. Is there ability to implement content relation in custom content types in custom modules (not in dynamic modules)?
@Steve, we are fixing some bugs with the migration script, and expect to be done within a day or two. I'll let you know over email.
Kalina
I would be interested in looking at this when you have something to test out. I have a large project that uses a lot of related data that I will eventually want to migrate.
Hey Kali,
Any word on when you'll be able to relate content items to themselves in a parent/child relationship. Is this coming in 7.1? This is still a key feature for us before we can switch out our legacy custom modules and think it would be a very beneficial feature for the module builder. Just to reiterate what we currently need: we have many items, say practice areas, that have child items so we could have:
-business law
--> tax
--> other child practice areas
-Litigation
--> tax
--> other child practice areas
7.0 doesn't allow us to do this type of hierarchy with the dynamic modules but it seems like this is a pretty common scenario. Any update on when it will be included out of the box.
Thanks,
Kalvin
Hi KMac,
This feature is being discussed for 7.1. and we will attempt to include it in the release, if the time allows for that.
We are currently working on enabling multiple child content types per parent in Module Builder.
(currently, only one child per parent is possible in Module Builder). The discussion and wireframes can be seen here here: www.sitefinity.com/.../multiple-child-types-in-module-builder-for-sitefinity-7.1
I have a question - what is the number of child practice areas you foresee?
In terms of backend interface, do you expect to see the hierarchy of practice areas in something like a tree view, or would you rather have a link to child practice areas under each practice area, as in the example here: s7k1fr.axshare.com/ What would be more suitable in your case ?
Thanks and best regards,
Kalina
Thanks for the update. I'll keep my fingers crossed. As for numbers, it really depends but really probably no more than 10-15 in most cases but we then might have a third level as well. With our custom modules now we relate each child to it's parent using hierarchical classifications and we dynamically create the item's url so it becomes something like:
business-law/tax/third-level-child-name
As for backend interface, I think the treeview makes the most sense since that's how pages and libraries works already. Hopefully that helps and if you have any other questions, I'm happy to help.