Sure no problem. We did think about having everything inside a Home node, but it helps our menu this way and so far we have had no downsides. I wouldn't have thought this URL issue would be related, would it?

Here's the structure:
http://i.imgur.com/nObng3R.png

Here's the settings for one page (notice the URL):
http://i.imgur.com/lOYuqWX.png

Here's the settings for another page (same URL):
http://i.imgur.com/kWNlbg7.png

It does appear to be because we have our sections as root level nodes. This means we're going to have to redesign our menu code, but at least the URLs are working now. A little annoying, but thank you for your answer.

From my experience, adding everything under a "home" node is great incase you want to add another site to the same installation, or add some kind of external content repository.

Updating your menu code should be pretty straightforward. Feel free to post what you're using now to generate it if you need any help!

Here's a starting point if you're using a partial to generate your nav.

@inherits Umbraco.Web.Mvc.UmbracoTemplatePage
@{
    Layout = null;
    var home = Model.Content.AncestorOrSelf(1);
}

<ul>    
    @*Render Home item*@

    @{ var homeActive = ""; }

    @if( home.Id == Model.Content.Id){
        homeActive = "active";
    }

    @*Render Home children*@    
    @foreach (var item in home.Children.Where(x => x.IsVisible()))
    {                       
        var active = "";

        if(home.Id != Model.Content.Id ){ @* if NOT home *@
            if (item.Id == Model.Content.AncestorOrSelf(2).Id){ 
                @* if foreach id and currentpage ancestor id is equal  *@
                active = "current";
            }
        }          
        <li class="@active @item.IsLast("last")">                             
            <a href="@item.Url">
                @item.Name                   
            </a>
            @if (@item.Children.Where("umbracoNaviHide!= true").Count() >= 1)
            {
              <ul>
                @foreach(var subitem in @item.Children.Where("umbracoNaviHide!= true"))
                {
                   <li><a href="@subitem.Url">@subitem.Name</a></li>
                }
              </ul>
            }

        </li>
    }
</ul>

This has been an issue since v4, is there an actual fix for this rather than moving the content inside the root node as this doesn't fix the problem it just ignores it?

Ed

It's a best practice to put everything nested in home nodes for many reasons. We even add a level to have a languageswitching page

This way i can use xpath much more freely and within a language sensitive context (ie go to the homepage in the current language & list all children)

By the way, have you tried changing this setting in web.config?

    <add key="umbracoHideTopLevelNodeFromPath" value="False" />

It is only best practice given that you want to use Umbraco that way. 

We have our content tree in the home node with all regular pages residing beneath on a site with many thousands of pages. We use the heirarchy to determine the layout of the site which allows us to create incredibly simple menu and navigation macros.

We then have content which we want to sit outside of our regular structure, outside of our regular structure. This is very intuative as far as I am concerned and saves a great deal of overhead that would otherwise be required in the navigation and menu logic.

Regardless of this, the system let's you do it either way so either way should work. A system functioning correctly should not rely on best practice, especially best practice that differs depending on who you speak to and is not written in a formal guide from the core team.

I am not having a go at anyone who wants to use the system this way. Equally this is not a dig at the core team as they have plenty of work on there plate. I am merely pointing out that I should have to work around bugs just because I don't want to work this way.

And did you check that setting in your web.config?

Thanks Rik, I have just done that and it fixes the problem in our dev site.

Only problem now is, this is a public sector site with thousands of visitors who bookmark places in the site etc so rolling out this change will probably annoy quite a few of them...

Thanks again for your help.

Ed

You're being quite dramatic about something that should have been foreseen during the design phase of the project ;)

You could set up a number of rewrite rules to catch most of them, or create a smart 404 page using this Google snippet: https://support.google.com/webmasters/answer/136085

Ed,

I'm glad you Mentioned this so succinctly:

"This has been an issue since v4, is there an actual fix for this rather than moving the content inside the root node as this doesn't fix the problem it just ignores it?"

Thanks,

Nick

is working on a reply...