27.0.0 Navigation Item Reusability

@kdsain - yes, the current UX and content modeling design is intentional with v27.0.0

When creating a new Content Type, you can select from Pages, Emails, or Reusable content.

Pages and Emails are channel-specific and currently are only available in the channels they are associated with. Reusable content is meant to be used across any channel and is authored/created in the Content Hub.

We don't currently enable accessing Pages, which are channel-specific, from reusable Content Items in the Content Hub, which are channel-independent.

This could change in the future, but our guidance today would be to reference content in the opposite direction - from a channel item (like a Page or Email) to the Content Hub, or from a channel item to another channel item of the same type (like Page to Page).

If I'm misunderstanding your approach, let me know, but we also don't recommend modeling pages to also serve the purpose of navigation. Instead we suggest you model navigation as its own Content Type (specifically a Page Content Type that has "Include in routing" disabled).

From this Navigation Content Type, you can create (multiple) menus dynamically in the Page Tree of a website channel.

Here's an example from our Kbank demo solution.

With this approach your navigation can be as flexible as you need it to be, modeled as its own content, and independent of the hierarchy of other navigable pages in Page Tree.

It also improves site performance because clearing cache for a page linked in the navigation doesn't require clearing the cache for the whole site!

The use case is unique for the site as a document repository of compliance, regulations, and forms for each state/provence where some states/provences share the same documents.

Some documents are updated weekly. Updating a shared nav item ensures content teams aren't missing a requirement for any one state/provence when it's internal, state or federal governance requiring those updates.

Additionally, the menus are mixed navigation types; some pages, some documents and some external urls which may or may not have different target requirements. I shouldn't have to make three distinct queries to the database mapping three distinct content types to a viewmodels to build a menu.

Even if I build a unique Page handler for documents and external links, they are no longer shared with the current pattern in version 27.#.

kdsain,

Maybe an approach is to add these navigation properties to your differnet content types. Keeping them the same name across the page types. In previous versions we'd call this inheriting from another content type. This will allow your unique use case to have navigation dictated by content tree AND content items VS having a dedicated navigation structure.

@kdsain,

I think @bkehren might be on to something.

In a future release we will have reusable field schemas which might help solve your issue.

Multiple Content Types could all have the same set of fields - this would let you retrieve multiple types of content but treat them all the same way.

Ex: they could all implement the same C# interface and allow you to grab their "navigation" fields easily.

You could also create a custom "Mapper" class that encapsulates mapping a "navigation"-enabled Content Type to a consistent NavigationViewModel or something similar.

Reusable field scheams is our Xperience by Kentico solution to Page Type inheritance from Kentico Xperience 13.

@Sean

I've reverted to the tree structures and pointing widgets to the tree roots where the Content Items are placed.

With the current pattern, if one document is shared across two or more channel/pages, I would need to build a nav type for each channel/page linked to a Docement content type. In 26.# I could reuse the nav item from the content hub, making it a more efficient solution. The change, to 27 forced me to scrap weeks of work.

This will have to be a temp solution since the site I'm building is a document repository where hundreds of documents may be shared across multiple divisions in each of the states/countries with their associated products.

Without a "smart folders" feature in the content hub, finding a document will become a management nightmare for content managers who may have to update/modify documents (sometimes) weekly as laws and regulations change.

@kdsain, understood. That does make the content management workflow more complex.

We will be introducing Smart folders next year, which could aid you in making content selection for content relationships simpler.

Before Smart folders are released, we will have Taxonomies and tagging. This could also be helpful to you because you can create different types of taxonomies - internal and external. Your internal taxonomies could be used for faster content selection, filtering, organization, ect...

Each taxonomy has its own hierarchy and you can create as many taxonomies as you want.