Dynamic root cannot start at root content?

[james-whittington1]

I have a site where a settings node is outside of the site root, and there is no way to select it using the new dynamic root except picking it by key.

As an interim solution I have built a query step that gets the pages at root, but it seems like this is an origin, as it step it just discards whatever else precedes it.

An origin of "Root content" which returns the same as _contentService.GetRootContent() would be a reasonably useful kind for websites that have multiple root content nodes I think?

[bergmania]

Sounds like a okay idea, but for the specific use case, what are the problems with choosing the settings node by key? The key id not the Id, so it will be the same on all environments.

[james-whittington1]

Hello, sorry I got really busy and didn't have time to reply. I've just come up against this same issue again and I don't understand what you mean by picking by key?

all my page content is under home, and then Home's sibling "settings" holds shared data that can be used in pods etc.

I would like a dynamic root item that allows me to start the multinode tree picker at the settings/health funds root, where the user would be able to see "Fund 1", and "Fund 2"

previously we just put xpath //settings and that was ok, but not it has started to show errors, and we want to make sure we're not making any potential upgrades to v14 more difficult.

Site

• Home
  ++ all pages
• Settings
  ++ Health funds
  +++ fund 1
  +++ fund 2

[james-whittington1]

We are using umbraco deploy so the key will (or could) change between environments as far as I am aware

[skttl]

We are using umbraco deploy so the key will (or could) change between environments as far as I am aware

Keys won't, id's will.

[james-whittington1]

Incredible. That is handy.

I do think it would be useful to have the option of selecting dynamic roots @ level 1.

For example, we have sites that are not using deploy and the key will change (if the content is manually authored in different environments).

We are using usync (for settings only) in these situations so the configuration should be the the same for each environment, so the ability to do things based on node structure rather than the key is still really important.