No. Expected behavior with url "/sitemap" is to

• look for page "/sitemap" and use the template indicated in the page

• else look for page "/" and use the "sitemap" template

Just tested here and it works. What's the value of hideTopLevelNodeFromPath? Do you have hostnames configured?

I still don't get the template with /sitemap even if I change the hideTopLevelNodeFromPath from true to false and back again.

can i share the repo with you. send me your email at [email protected] so i can share the bitbucket repo.

Steps I took to create the site are

Create Empty Site with vs2012

Install-Package UmbracoCms

Run site

turn on "useDirectoryUrls" in web.config, set it to true

Install Cultiv Search Engine Sitemap

Open browser to site at /CultivSearchEngineSitemap

What else could I be missing?

OK, got the ZIP archive of your website and managed to execute it.

Note to all: to enable full routing pipeline debug logging, edit config/log4net.config and set priority value="Debug" in the element.

Your issue is: you have the following structure: Holding Page > Home. No hostname is configured, and umbracoHideTopLevelNodeFromPath is true. So the url of Home is / and the url / should map to Home. Unfortunately it maps to Holding Page which has an umbracoInternalRedirectId set to redirect to Home. Then, when following internal redirects, we re-evaluate the template and in doing so we ignore the url but not the querystring, which explains why ?altTemplate= keeps working.

So you have pointed out the following issues:

BUG#1: why does / resolves to Holding Page and not directly to Home ?

BUG#2: we should _not_ override the template when following an umbracoInternalRedirectId, if a template has already been set.

BUG#3: some debbuging messages that are written to the log are misleading

Working on it at the moment...

Correction to my previous post.

The url of Home is /home and /home maps to Home. Now, the behavior of / when no hostnames are defined is to map to the first node at the root of the tree, regardless of umbracoHideTopLevelNodeFromPath. So it is normal that / maps to Holding Page.

QUESTION: is this really normal, or should it map to the first child of the first node at the root of the tree, when umbracoHideTopLevelNodeFromPath is set to true?

Next, about the strange template behavior... at the moment having the template in the url or in the querystring (altTemplate) does not work the same, this obviously needs to be fixed.

QUESTION: if I set a template via /path/to/page/template or /path/to/page?altTemplate=template -- what should happen in the following situations (in between parenthesis is what I think is right):

• page not found, redirects to our custom 404 page (ignore alt template)
• access denied, redirects to denied or login page (ignore alt template)
• internal redirect (ignore alt template)

So basically I think that the alternate template should be ignored as soon as we're not displaying the indented page (and that would include internal redirects). Does that sound right?

Given at structure like:

Content
- SiteA
- - Home
- SiteB
- - Home 

I think that / should map to the SiteA node, regardless of hideTopLevel settings. Otherwise you have no way of showing the SiteA node?

If we have hostnames involved:

Content
- SiteA (www.sitea.foo)
- - Home
- SiteB (www.siteb.foo)
- - Home 

Hi Stephen,

I always use the "level 1 node" (HoldingPage in the above scenario, right?) as the "Home" node of my websites, so that "/" maps to that node, regardless of having assigned a hostname (I guess my logic is that as soon as I create another level 1 node, I start assigning hostnames).

Changing this behavior will only affect solutions where no hostname has been assigned, right? So "fixing" your site if affected, would be pretty easy... (?)

As for the three cases of using alternate template syntax on 404, 403 and umbracoInternalRedirectId pages, I agree with you to ignore the template.

/Chriztian

Hi,

I always define a structure like this for my multilanguage sites:

Content
- en-US (homepage of the English website)
-- page 1
-- page 2
-- ...
- nl-Be (homepage for Dutch website)
-- page 1
-- page 2
-- ...

Seems to work best for me.

greetings,

Anthony 

Question:

Is the following scenario possible to achive and if it is, how?

Content
--Site A (www.firstdomain.foo)
  --page 1
  --page 1

--Site B (www.firstdomain.foo/siteb)
  --page 1
  --page 1

--Site C (www.seconddomain.foo)
  --page 1
  --page 1

Just for completeness and because nobody else has yet mentioned it...

Content
- Choose Your Language
- EN
  - page1
  - page2
- FR
  - page1
  - page2
- DK
  - page1
  - page2

In this scenario you absolutely want the first node in the site to be "/". That way people can set their preferred language (and set a cookie so they don't have to select it again but are auto-redirected to the appropriate language homepage).

In my mind the first node should be "/" no matter what because it is obvious. Obvious is my preference.

But if you decide against that approach it is still possible in the template for the "/" page to do the language detection and redirection with a bit of macro code. It just isn't as obvious to those who live with a site but didn't build it themselves.

I agree about the alt template suggestion by Stephen completely.

my 2 pence worth anyway :)

cheers,
doug. 

Thanks all. So the consensus is that

• / should map to the first node in the tree regardless of hideTopLevel settings
• alternate template should be entirely disable as soon as we're not rendering the intended document

Will do.

@Christer: entirely possible. Actually setting the domains as you have proposed should just work:

Content
- Site A - www.domain-1.com - url: www.domain-1.com/
- - Page A1 - url: www.domain-1.com/page-a1
- Site B - www.domain-1.com/site-b - url: www.domain-1.com/site-b
- - Page B1 - url: www.domain-1.com/site-b/page-b1
- Site C - www.domain-2.com - url: www.domain-2.com/
- - Page C1 - url: www.domain-2.com/page-c1
- Site D - www.domain-3.com/anything - url: www.domain-3.com/anything/
- - Page D1 - url: www.domain-3.com/anything/page-d1

Hostname takes precedence so everything that begins with www.domain-1.com/site-b will map to Site B -- even if you create a page named Site B under Site A. Mmm... I need to update the doc to explain this.

@Doug: sure, works. And starting with 4.11 you just set a wildcard domain on EN (no hostname, just the language) to set culture to english, and on FR to set culture to french, etc.

@Doug, again: I fully agree with you, things should work the way that's most obvious. Which is why I wanted you in that discussion ;-)

@Ben: and your sitemap page is going to be at /home/SearchEngineSitemap

Hi Stephen,

Thankyou so much for doing this. Your a legend.

@Stephen

I tried this with a couple of different configurations and could'nt get it to work. I should point out that it's version 4.9, maybe that's whats causing it to fail??

Note: umbracoHideTopLevelNodeFromPath is set to true in all configs. If set to false it will work but the main site www.domain-1.com will have /site-a in it's URL for sub pages and thats not the way the customer desire.

*Changed settings

Config 1
useDomainPrefixes=false

Site A (www.domain-1.com)
www.domain-1.com/  => Maps correctly
www.domain-1.com/page-1 => Maps correctly

Site B (www.domain-1.com/site-b)
www.domain-1.com/site-b => Maps correctly
www.domain-1.com/site-b/page-1 => Page not found

----------------------------------------------------------

Config 2
useDomainPrefixes=false

*Site A (no hostname)
www.domain-1.com/  => Maps correctly
www.domain-1.com/page-1 => Maps correctly

Site B (www.domain-1.com/site-b)
www.domain-1.com/site-b => Maps correctly
www.domain-1.com/site-b/page-1 => Page not found

----------------------------------------------------------

Config 3
useDomainPrefixes=false

*Site A (no hostname)
www.domain-1.com/  => Maps correctly
www.domain-1.com/page-1 => Maps correctly

*Site B (no hostname)
www.domain-1.com/site-b => Maps correctly
www.domain-1.com/site-b/page-1 => Page not found

----------------------------------------------------------

Config 4
*useDomainPrefixes=true

Site A (www.domain-1.com)
www.domain-1.com/  => Maps correctly
www.domain-1.com/page-1 => Maps correctly

Site B (www.domain-1.com/site-b)
www.domain-1.com/site-b => Maps correctly
www.domain-1.com/site-b/page-1 => Page not found

----------------------------------------------------------

Config 5
*useDomainPrefixes=true

*Site A (no hostname)
www.domain-1.com/  => Maps correctly
www.domain-1.com/page-1 => Maps correctly

Site B (www.domain-1.com/site-b)
www.domain-1.com/site-b => Maps correctly
www.domain-1.com/site-b/page-1 => Page not found

Note: useDomainPrefix set to true in combination with no hostname causes strange behavior with URL's in general

----------------------------------------------------------

Config 6
*useDomainPrefixes=true

*Site A (no hostname)
www.domain-1.com/  => Maps correctly
www.domain-1.com/page-1 => Maps correctly

*Site B (no hostname)
www.domain-1.com/site-b => Maps correctly
www.domain-1.com/site-b/page-1 => Page not found

Note: useDomainPrefix set to true in combination with no hostname causes strange behavior with URL's in general

@Christer: yes, everything I'm talking about here is 4.10. Any version prior to 4.10 used deprecated routing code that behaved somewhat unexpectedly ;-) It's quite possible that the examples don't work with 4.9, and that there's not real way you could make them work. That was the reason for rewriting the routing.

@Stephen

Great! Then I will upgrade to 4.10 or should I wait for 4.11?

@Christer 4.11 will be out this Friday, best to wait a few days :)

@Sebastiaan Great!

As mentionned in http://issues.umbraco.org/issue/U4-1222 I have pushed code into 4.11 that should bring the following behavior:

• you can set an alternate template via /path/to/page/template
• you can set an alternate template via /path/to/page?altTemplate=template
• when using both, the one in the querystring takes precedence
• if using ?altTemplate=foo and foo is not a valid template alias, just ignore
• ignore alternate template if not displaying the expected document

Not displaying the expected document means: following an internal redirect, displaying a custom 404 page, displaying the login/access-denied page... basically anything that changes the document.

is working on a reply...