How would you structure shared content across multiple channels in Xperience by Kentico?

I would ask the question "Can this page be completely rendered through CONTENT (no widgets)?"

If the answer is yes, I would push to have a set URL route (/profiles/{user-profile-url-segment}) that renders the template from the uniform content item(s). The content item should contain a unique url-segment taht acts as the lookup code, and what I did for SEO stuff is i had a "Content Item SEO Metadata" reusable content type that contained the normal stuff (Page title, description, keywords, OG image, etc) that can be attached to Reusable content.

If it requires widgets, then indeed keeping as much in a uniform location, and having 'pages' pull that in (along with then allowing widgets and other content) to be set. Perhaps some sort of global even that if the profile content item gets deleted, the related profile webitem pages also get deleted?

A LOT of my site (physicsclassroom.com) is actually structure reusable content and hard-set templates and routes.

Thanks @Trevor for the response.

Answering your question: It can be fully rendered through content, however, the template should support widgets, since the editor can eventually go to a page and add a custom widget to a particular profile.

But I got your point and it makes sense. I think we can also set a field on the shared content type within the content hub for the profile, so editors to set:

Url Slugs per Channel [A]:

• /profile/last-name-first-name
• /profile/two

Url Slugs per Channel [B]:

• /member/first-name-last-name
• /member/two

Maybe that is not possible. Actually, I have been thinking if there is a way to share content cross-channels, like for example: Channel [A] has the original content pages, then on Channel [B], There is a reference to that page with their own url slugs, or maybe we don't need a reference, but just see if the API is able to retrieve content from one channel to another and hard code the routes as you mentioned.

Thanks again for the reponse

I'd take a slightly different approach NOW. Prior in Portal Engine I'd do exactly what Trevor mentions. However, with the way things are now, we tend to use a combination of Page Builder and Templates to give the user the flexibility they need/want.

What I'd suggest would be the following:

1. Define your "<profile>/<member page>" in a setting or content type or in the widget definition for the channel.
2. Add a custom route that would handle your / path on the controller action you want to execute.
3. Add a page in the content tree for the member's "profile" to be displayed on.
4. Build a profile widget that references that setting value per channel from #1 above.
5. Place the widget on the profile page.

Maybe in your custom settings for the channel, you define your profile page AND the view name or some css classes that get applied when the view is rendered so you can make them somewhat "custom" looking per channel.

That is an interesting approach @Brenden, thanks for sharing it. That could actually work some how.

So, the idea would be to add a pivot member's profile page only on each channel, where I will add the widget, so the routing exists and as you saiduse the custom route on the controller action I want to execute.

I will give it a try to both options and see what could fit better, I will then comeback here and share the final results

Thank you

What about a slightly different architecture. I am not a developer but a producer and this is what I would ask the team to implement for maximum automation and less authoring time. Yes there is more dev automation but it is once and never again. As a Business analyst, for me the barrier that makes this automation worthwhile is content with more than 20 items that have additions more than twice per month. Otherwise on a 3 year project lifetime you will never recoup the ROI. But whent it is deployed you can save your client a tonne of page creation authoring time.

1. Create a profile content type and create each profile as objects in the content hub
2. Set up a channel taxonomy with a tag for each of your channels
3. Tag each profile with the channel taxonomies for each channel that content is destined for e.g. that profile to display on that list of sites (assuming you want the flexibility to display different profiles on different channels)
4. Create a folder in each channel named consistently to hold the profile pages
5. Use code and the content API to automate the creation the profile pages from a page content type in the correct channels automatically on publication of the content hub object. Create the page as a draft saved but not published in a channel if that tag is selected on the content hub item.
6. Include 3 sections on the page builder as a part of the automation: Blank, Widget prepopulated, Blank. The content type blank sections allow marketers the flexibility to add additional marketing content on the profile pages above and below the structured content and allow for flexibility for SEO to make the content unique or even in the future to delete the widget and replace it but keep the same URL consistency if they want to reuse the URL for another purpose. Marketers love the flexibility even if they never use it. When they want it is the one time that you dont implement it to cut a corner and you have to do it under pressure during UAT.
7. Create a top level page on each site
8. Create a dynamic folder in the content hub for each channel with taxonomy PROFILE + CHANNEL NAME
9. Create a widget to display dynamic folders from the content hub - set one widget connecting to the dynamic channel once. Dont forget to have ordering capability in this widget (alphabet, date and rating number) because you will want the flexibility to reorder these. Also you might want another layer of filtering so adding filtering to this feed widget is also a good long term thing
10. Add the widget to show the dynamic folder in a feed on a page wherever you want it on the site pointing to the folder of profile pages.
11. Have a notification notify the channel approver when a new draft profile is on the channel for review. If governance is not important then publish the pages automatically as well.

This is the process we use when we are feeding structured content in from other sources - e.g. if the course mangement database feeds all the course pages on the gordon https://www.thegordon.edu.au/courses/all

The site settings and styles come with the content type in each channel, structure content is interspersed with marketing content inbetween. I think in this example we have 5 data widgets on each page with marketing content above and below each widget. Marketing is happy - they now have flexibility and can improve outcomes and SEO if they want but if they are short on time they can do nothing, they dont need to create the pages or configure widgets. Governance is happy, it gets to review the pages but if they dont want to make updates all they have to do is approve publication and the pages maintain themselves from the source of truth. Noone has to create pages or drop widgets onto them once the top level page and its feed is set up.