Exclude top level node from Path

Topics: Feature requests, General
Dec 8, 2010 at 3:22 PM
Edited Dec 8, 2010 at 3:23 PM

Consider this scenario


1 C1 installation
3 languages (da, en, kl)
1 website root

Since the website root node MUST have a url we set it to forside, frontpage, saqqaa. Now, to lets see how the url's will look like in the context of the english website


frontpage: /en/frontpage.aspx
about page: /en/frontpage/about.aspx
contact page: /en/frontpage/contact.aspx


So, how do i get rid of my frontpage-part of the url? i want it to be


frontpage: /en.aspx
about page: /en/about.aspx
contact page: /en/contact.aspx

Dec 9, 2010 at 1:47 AM

Not sure but, I guess you can define a FriendlyURL in the page settings tab.

Of course this will be redirected to the original address even after that. I believe the friendly url should be the one you see at the address bar but it isn't.

for example :

/company/about.aspx -> If I set a friendly url as "/about" then this new url will work but it redirects to the original url. I was expecting http://domain/about instead of http://domain/company/about.aspx

@CompositeC1 is there any solution to this?

Dec 9, 2010 at 1:56 PM

IMO the whole problem originates from the fact that you can set url-prefixes on the individual language-elements. If i set the url of my frontpage to en instead, ie. the url would end up being http://domain/en/en/contact.aspx. To prevent this double-langauge prefix i suggest the following logic

Generating urls
1. language prefix is en
2. url of root node is en
3. because prefix and root url is the same, just merge them
4. url will be http://domain/en/contact.aspx

Resolving of page from http://domain/en/contact.aspx
1. langauge is resolved to en because of the prefx
2. since we have a root node url of en as well, step 1 shouldn't remove en from the url but let it be for further resolving
3.  the resolved node will be en/contact and not just contact which would be the case today

Coordinator
Dec 9, 2010 at 2:03 PM

In the current releases there really isn't a way to fix this without either changing core code or doing filtering on URL's going way in/out. Neither are super great. The Friendly URL feature isn't solving this problem.

On the short term roadmap (jan-feb-mar) we have improved URL handling in general - this include new features like

  • Not being forced to have a 'root page' URL title (unless multiple sub sites exists, which share host name) (*)
  • Not having the .aspx extension if so desired (*)
  • The ability to map to a Culture (language version) using the host name instead if a folder name, making the "/en/" part optional if you specify "host name to Culture" mapping, like "contoso.de -> German, contoso.com -> English" etc. (*)
  • The ability to map multiple host names to a home page / culture
  • Perhaps the ability to map a host name to a sub page

We would make this features easy to config from within the C1 Console so it's generally available.

The 3 features marked (*) would give you the ability to get to the front page of two different language versions like this:

  www.contoso.com/
  www.contoso.de/

and a sub page could look like

  www.contoso.com/about
  www.contoso.de/über-uns

In short, no .apsx., no language codes and to top level page, These new features should be the answer to the URL question above.

If you have other ideas in this area, just fire away.

 

Dec 9, 2010 at 2:19 PM

amazing how my Filter and Module just gets bigger and bigger :)

Dec 10, 2010 at 1:20 AM

For people interested, i've uploaded a patch containing necessary files for implementing following functionality

  • Full working SiteMapProvider wrapping the C1 Sitemapnavigator and adding new functionality such as nicer urls
    1.  
      1. all lower case
      2. language prefix is removed (requires root-node to have a url-value of the two letter language name it represents)
      3. .aspx extension is removed
    • Supports all expected functionality as CurrentNode, RootNode, FindSiteMapNode and FindSiteMapNodeFromKey, Child, Parents etc.
    • Nicer urls are
  • UrlFilter that finds all internal links in the html and replaces them with nicer urls
  • UrlFilterModule that intercepts requests and translates nicer urls into C1's format

The patch has id 7704 in the patchlist http://compositec1.codeplex.com/SourceControl/PatchList.aspx. Note that it is code used in production in our own libraries, tweaked a bit to work on its own. This customized code has not been tested so use on your own responsibility or look at it for inspiration.

To make it work it requires the following two changes to web.config

  1. Add the sitemapprovider under system.web/siteMap and make it the default one (http://msdn.microsoft.com/en-us/library/ms178426.aspx)
  2. Add the UrlFilterModule as the very first module under either system.web/httpModules or system.webserver/httpModules depending on your iis version.

Thats it. Enjoy and please comment if you find it useful.

Feb 3, 2011 at 8:07 PM
On the short term roadmap (jan-feb-mar) we have improved URL handling in general - this include new features like
  • Not being forced to have a 'root page' URL title (unless multiple sub sites exists, which share host name) (*)
  • Not having the .aspx extension if so desired (*)
  • The ability to map to a Culture (language version) using the host name instead if a folder name, making the "/en/" part optional if you specify "host name to Culture" mapping, like "contoso.de -> German, contoso.com -> English" etc. (*)
  • The ability to map multiple host names to a home page / culture
  • Perhaps the ability to map a host name to a sub page

We would make this features easy to config from within the C1 Console so it's generally available.

The 3 features marked (*) would give you the ability to get to the front page of two different language versions like this:

In short, no .apsx., no language codes and to top level page, These new features should be the answer to the URL question above.

Great news... I'd love to know what the status of these updates are. One thing that I've seen done quite commonly recently is

www.contoso.com (int'l site)

www.contoso.com/ca (Canada)

www.contoso.com/ca/en (Canada English)

www.consoso.com/ca/fr (Canada French)

Interesting what Apple does Switzerland does: http://www.apple.com/ch/

 

Feb 3, 2011 at 8:16 PM
Edited Feb 21, 2011 at 11:47 AM

is /ca/fr or /ca/en common !? i though it followed the standard schema of fr-ca or en-ca.

Its easy to do though using the CompositeC1Contrib project which renders urls like this

http://www.sogm.gl/en/competence_areas/port_constructions

Coordinator
Feb 10, 2011 at 7:32 AM

The status is that we haven't dived into this area yet - we are currently wrapping up 2.1 and the only open 'feature' right now is replacing the code editor with CodeMirror - hopefully we have a stable release out of the door within a few weeks, and we are back on the feature track. This area is something we would like to "tool" with a lot of UI support so the features are accessible to most users.

Coordinator
Jun 17, 2011 at 12:15 PM
Edited Jun 17, 2011 at 12:21 PM

The related feature request is fixed. In v2.1.3 you can either set an emtry url UrlTitle for the root page, or you can bind a hostname to a page and that will remove page title from from the url. See UrlConfiguration on docs 

Jun 20, 2011 at 7:33 PM

Just a point of reference to burningice... for three bilingual countries, Canada, Switzerland and Belgium

Apple, who have a very international audience, does it this way:

Canada

apple.com/ca/ (defaults to English)

apple.com/ca/en/

apple.com/ca/fr/

Switzerland

apple.com/ch/ (Defaults to language selection page)

apple.com/chde/ (German)

apple.com/chfr/ (French)

Belgium

(Same as Switzerland, but with /benl and /befr) 

 

Microsoft seems a bit of a mix:

microsoft.com --> goes to www.microsoft.com/en-US/ (As you would expect for .Net )

microsoft.ca --> goes to www.microsoft.com/en/ca/

microsoft.ch --> goes to www.microsoft.com/de/ch/

microsoft.be --> goes to www.microsoft.com/belux/ (language select page)

Dell (bit of a mess, but...)

dell.com --> int'l site (USA)

dell.ca --> ca.dell.com/ca/en  

FRENCH: ca.dell.com/ca/fr

dell.ch --> German default (but www.dell.ch/ch/fr and www.dell.ch/ch/de also exist)

dell.be --> Dutch default (but dell.be/be/nl and dell.be/be/fr also exist)

In my mind, I think country comes before language when you're selling physical products. Products, for example, that are sold in the USA and Canada have different labelling requirements safety regulations, etc. Products (especially food products) are different by country first, and then language. When you're selling services that cross boundaries, then language is more important than country. For example, you're selling software to "English-speaking" people, or "French-speaking" people. However, to be HONEST, I think this is rarely the case. In fact, if you go to www.microsoft.com/fr you get a 404 page, as there is no GLOBAL french community that would go there.

 

Coordinator
Jun 20, 2011 at 8:04 PM

@atomiton seeing you have some real insight into this area and care about it, would you consider giving our latest build a test run and see how you like ?

The feature is described here http://docs.composite.net/UrlConfiguration - you would need to host the site in IIS to fully test host name features. If you have IIS you can pretty quickly get a beta build up and running by following this guide: Preview the latest beta builds of Composite C1 (make WebPI use IIS and not WebMatrix).

If got the time to dive into this and run into issues or need tips on simulating host names don't hesitate to ask.

Thanks!

Marcus

Jun 21, 2011 at 5:51 PM

Sure, I'll definitely give it a go! Is it easy to upgrade an existing 2.1.1 site? We have one on our dev server and I'd love to try it on our real data.

We'll definitely be using it when we launch our translated site.

Coordinator
Jun 21, 2011 at 6:26 PM

Send me a mail to maw at composite.net and I'll send you back a package that auto upgrade you to the latest build. I don't think we have written/validated upgrade steps yet and the package way is much faster also,