Storing references for unroutable content items

[stephen-sherman]

Consider the following site structure:

• Site
  • Home
    • Page
  • Data
    • Tags
      • Tag
  • Settings

Assume that:

• The Home content item has a Culture & Hostname configured
• The Page document type has a Multinode Treepicker for selecting instances of Tag

In this structure, the Data and Settings content items and their children have URLs that are “unroutable”. This is typically fine, as these items should never be accessed from the front end of the website anyway.

However, this also prevents them from generating references (in Umbraco 13 at least). It would be very useful for content editors to be able to open a Tag and look at the Info tab to see where it has been used.

I can think of a couple ways to work around this…

• Assign a Culture & Hostname to the Data and Settings items
• Structure the website so that the Data and Settings items have valid URLs by default (e.g. make them children of Home)

… but it seems odd that this feature is tied to an item having a routable URL.

Has anyone come up with a novel way to avoid this limitation?

Aside: Does anyone know if you can disable the “Relate to original” toggle when copying a content item, or set it to false by default?

[pc-pdx]

Howdy!
I know this is late - but tossing out a finding anyway given that i’ve just ID’d something similar providing i’m actually understanding the question correctly.

I think the end goal here is to have the “Referenced by the following items” appear on the node.
I have a similar structure where we have taxonomy nodes that don’t necessarily need any inner fields/contents - only the title of the node. When that is the case - there is no corresponding reference displayed UNLESS you add a field to the docType.
I’ll often add an “instructional” label(string) field just to have a field defined - then Umbraco13 will show the “Referenced by the following items” in the info app. This is independent of any routing ability - it’s the field.

Hope this helps in some future effort? Perhaps this is fixed in u17 and not even an issue anymore. Happy new year in any case!

[stephen-sherman]

Thanks @pc-pdx, that works perfectly! It looks like the problem is not present in Umbraco 17, but this will serve as a quick workaround while we work toward upgrading.