You could find out how umbraco is fetching the node if you add ?umbDebugShowTrace=true. Can you do that and show us what output you get. On the other hand, there's other options that may change this behaviour.
- umbracoHideTopLevelNodeFromPath: if set to true then you'd get /home.aspx, /about.aspx, /members.aspx and /members/home.aspx. If set to false then /home will be put in front, so /home.aspx (remains), /home/about.aspx, /home/members.aspx and /home/members/home.aspx
- ensureUniqueNaming from umbracoSettings.config -> shouldn't change anything in your setup as it only ensures uniqueness for pages with the same parent
Let us know the output of the trace and we'll get it sorted.
That's the crux of the issue. The question is... why?
Any chance you've to urlRewriting (in the /config/urlrewriting.config or using another url rewriter) active on the site? Or maybe a docType alias with umbracoUrlAlias or one of the other umbracoXYZ properties set?
Do you have hostheaders in use on your site? If so, have you used the Manage Hostnames menu for *every* top-most node on your site? If you only set some and leave some unset you can run into weird problems like this.
If you were to right-click on the top-most page of your site and select 'publish' from the menu, and choose the box for all child nodes as well... that will force umbraco to re-calculate all the urls for all the pages below the one you selected. Repeat this for all the top-level nodes on your site so that all nodes get recalculated urls. You need to do this after you use manage hostnames, for instance.
I don't have any other rewrite rules setup in the urlrewriting.config (other than the one I have setup to bypass this issue for now). I don't have any other type of rewriting setup on the site. I do have umbraco properties defined for redirecting on my templates, but none are actualy set for eaither node.
I do have host headers setup on IIS, but I only have one site setup in umbraco so I haven't used the Manage Hostnames feature as I just want everything to map to the main site.
Republishing (either by "Republish entire site" or by right clicking the top most not and selecting "Publish") doesn't seem to resolve the issue.
Just spent a couple of hours debugging this with the source, and I have found the code that causes this. The reason that you trace does not reveal it is, that the result of the requestmodule is cached, so if the page has been requested before, then the ID of the query will be retrieved from cache.
Note the last if sentence. That matches urls with exactly two parts, and joins a new xpath to the query.
This actually means that _both_ pages are matched by the query, but later in the code, only the first match is used, which will be the root node.
It seems like a bug, but I imagine that it might be used because it is possible to add hostnames like this in the "manage hostnames" part: "example.com/en-us". So that means that your home page _could_ be fetched with "example.com/en-us/home.aspx".
So the question remains if this is a feature or a bug, but at least it explains the behavior you are experiencing.
Let me know if you need more details in case you want to report it as a bug on codeplex.
It has be considered a bug, doesn't it? I mean, this is not some behavior one could argue is appropriate or expected behavior.
Not sure how it might be coded to handle the different scenarios but there must be a way to handle this with/without HideTopLevelNodeFromPath, at any level in the tree, and with/without manage hostnames being involved. (says the guy who doesn't have to code a solution :) )
If I understand you correctly, this means that Matt has a few options to work-around this issue:
Use a urlrewriting rule to get around the problem
Rename the /members/home.aspx page to something else (that is, ensure that no second-level node has the same name as a top-level node
Move the /members/home.aspx page to anywhere other than the second level in the content tree since home.aspx also matches the top-level node.
Yes, that is the three options that I see currently.
A classic is to rename the /members/home.aspx node to "home " (note the trailing space). This will give it the url /members/home-.aspx, but it is not transparent for the editor who might rename it at some time...
Child page with the same name as homepage node routes to homepage
Hi Guys,
I have a site structure as follows:
Home
- About
- Members
- - Home
I seem to have a problem that when I navigate to /members/home umbraco actualy returns the content for /home
Anybody know why this might be?
Many thanks
Matt
Looking into it a little further, it looks like you can call anything like the following:
http://domain.com/ANYTHING/HOMEPAGENAME
and it will always resolve to the homepage, even if ANYTHING doesn't exist.
I've managed to resolve the issue for now by registering a rewrite rule to redirect to the permenant url for the page.
Would still be interested to know why it would do this?
Matt
Matt,
You could find out how umbraco is fetching the node if you add ?umbDebugShowTrace=true. Can you do that and show us what output you get. On the other hand, there's other options that may change this behaviour.
- umbracoHideTopLevelNodeFromPath: if set to true then you'd get /home.aspx, /about.aspx, /members.aspx and /members/home.aspx. If set to false then /home will be put in front, so /home.aspx (remains), /home/about.aspx, /home/members.aspx and /home/members/home.aspx
- ensureUniqueNaming from umbracoSettings.config -> shouldn't change anything in your setup as it only ensures uniqueness for pages with the same parent
Let us know the output of the trace and we'll get it sorted.
Cheers,
/Dirk
Hey Dirk,
Sure thing, here is the output from the trace (NB it should resolve to a page with ID 1149)
This line is particularly curious if /members/home.aspx is id=1149
Becuase it shouldn't be for node 1060.
But since it IS for id=1060 you get the following...
That's the crux of the issue. The question is... why?
Any chance you've to urlRewriting (in the /config/urlrewriting.config or using another url rewriter) active on the site? Or maybe a docType alias with umbracoUrlAlias or one of the other umbracoXYZ properties set?
Do you have hostheaders in use on your site? If so, have you used the Manage Hostnames menu for *every* top-most node on your site? If you only set some and leave some unset you can run into weird problems like this.
If you were to right-click on the top-most page of your site and select 'publish' from the menu, and choose the box for all child nodes as well... that will force umbraco to re-calculate all the urls for all the pages below the one you selected. Repeat this for all the top-level nodes on your site so that all nodes get recalculated urls. You need to do this after you use manage hostnames, for instance.
Let us know what you find out.
cheers,
doug.
Hi Doug,
In response to your questions:
Let me know if you have any other thoughts.
Many thanks
Matt
By the way, I've noticed that if the second homepage is more than 2 levels deep, it does resolve correctly
ie http://domain.com/members/something/home.aspx does resolve correctly.
Matt
Just spent a couple of hours debugging this with the source, and I have found the code that causes this. The reason that you trace does not reveal it is, that the result of the requestmodule is cached, so if the page has been requested before, then the ID of the query will be retrieved from cache.
Now, the code causing this trouble is:
bool rootAdded = false; if (GlobalSettings.HideTopLevelNodeFromPath && requestRawUrl.Length == 1) { HttpContext.Current.Trace.Write("umbracoRequestHandler", "xpath: '" + _tempQuery + "'"); if (_tempQuery == "") _tempQuery = "/root/node"; _tempQuery = "/root/node [" + _urlName + " = \"" + requestRawUrl[0].Replace(".aspx", "").ToLower() + "\"] | " + _tempQuery; HttpContext.Current.Trace.Write("umbracoRequestHandler", "xpath: '" + _tempQuery + "'"); rootAdded = true; } for (int i = 0; i <= requestRawUrl.GetUpperBound(0); i++) { if (requestRawUrl[i] != "") _tempQuery += "/node [" + _urlName + " = \"" + requestRawUrl[i].Replace(".aspx", "").ToLower() + "\"]"; } if (GlobalSettings.HideTopLevelNodeFromPath && requestRawUrl.Length == 2) { _tempQuery += " | " + pageXPathQueryStart + "/node [" + _urlName + " = \"" + requestRawUrl[1].Replace(".aspx", "").ToLower() + "\"]"; }Note the last if sentence. That matches urls with exactly two parts, and joins a new xpath to the query.
This actually means that _both_ pages are matched by the query, but later in the code, only the first match is used, which will be the root node.
It seems like a bug, but I imagine that it might be used because it is possible to add hostnames like this in the "manage hostnames" part: "example.com/en-us". So that means that your home page _could_ be fetched with "example.com/en-us/home.aspx".
So the question remains if this is a feature or a bug, but at least it explains the behavior you are experiencing.
Let me know if you need more details in case you want to report it as a bug on codeplex.
Fantastic research, as always, Morten!
It has be considered a bug, doesn't it? I mean, this is not some behavior one could argue is appropriate or expected behavior.
Not sure how it might be coded to handle the different scenarios but there must be a way to handle this with/without HideTopLevelNodeFromPath, at any level in the tree, and with/without manage hostnames being involved. (says the guy who doesn't have to code a solution :) )
If I understand you correctly, this means that Matt has a few options to work-around this issue:
Is that right?
cheers,
doug.
Yes, that is the three options that I see currently.
A classic is to rename the /members/home.aspx node to "home " (note the trailing space). This will give it the url /members/home-.aspx, but it is not transparent for the editor who might rename it at some time...
Awesome work Morten,
I'm happy to keep the custom URL rewrite rule for my purposes as the page is unlikley to move/change.
Does anybody know what the specific length check is for? If it is purely for the country code, could you not just add a regex to match the pattern?
Matt
is working on a reply...