Sitecore 6 addAspxExtension=”false” issue

In my previous post (LinkManager – Working with URL’s in Sitecore 6) I was quite enthusiastic about the addAspxExtension feature, which allows you to disable the .aspx extension in Sitecore URL’s, as long as you provide an 404 handler or use IIS7.

Unfortunately the feature seemes to affect the Sitecore Client negatively, because when enabling it, it is no longer possible to edit Sitecore contents:

addAspxExtension=false error

addAspxExtension=false issue

The problem was found using a Sitecore 6.0.0 rev. 081222 running on a IIS6. If you are running this version of Sitecore, you should not set the addAspxExtension to false if your site requires the Sitecore editor to work. If your installation is a front-end server only, you should have no problems.

LinkManager – Working with URL’s in Sitecore 6

Have you noticed that a page in Sitecore 6 can be accessed through several URL’s? This is an example of the products page on the Sitecore website. The following URL’s are all valid and points to the same page and the same language:

http://www.sitecore.net/en/Products.aspx
http://www.sitecore.net/Products.aspx
http://www.sitecore.net/Products.aspx?sc_lang=en
http://www.sitecore.net/Products
http://www.sitecore.net/?sc_itemid={5D8489BF-419B-4336-B9DA-CA704C682B51}

This can confuse statistical tools like Google Analytics, as the statistical data is collected per URL basis. Sitecore’s own Online Marketing Suite does not have this problem, but all tools that collects data from Javascripts inserted on the page will get confused. It is hard to get a total number of hits for one page, as you have to collect the statistics scattered over many URL’s.

So how can you limit the number of URL’s to one page? The solution lies within the linkManager setting in web.config:

<linkManager defaultProvider="sitecore">
  <providers>
    <clear />
    <add name="sitecore" type="Sitecore.Links.LinkProvider, Sitecore.Kernel"
         addAspxExtension="true"
         alwaysIncludeServerUrl="false"
         encodeNames="true"
         languageEmbedding="asNeeded"
         languageLocation="filePath"
         shortenUrls="true"
         useDisplayName="false" />
  </providers>
</linkManager>

These are the default settings in the web.config, which allows the widest range of available URL’s per page. But this is not always a good thing. The following settings caught my eye:

languageEmbedding="asNeeded"

This setting allows Sitecore to add the language as a part of the URL “as needed”. In practice this means “as the wind blows” because it is very hard to find a pattern for when the language is added and not. My recommentation is to use “always” for multiple language sites, and “never” for single language sites.

Another cool setting is this:

addAspxExtension="true"

Setting this to “false” removes the .aspx extension for all URL’s. In order for this to work you will need to use IIS7 and map all incomming requests to ASP.NET, or write your own 404 error handler that redirects any incomming request to the correct .aspx page.

App_Data folder in a virtual application or directory

This is a common issue when working with webservices in virtual applications in the IIS. Imagine this folder structure:

Website with virtual application

Website with virtual application

The “Website” is the website with it’s App_Data, and “Virtual Application” is a virtual application running a webservice with it’s own App_Data.

To get the physical path to the website’s App_Data folder you write:

HttpContext.Current.Server.MapPath("/App_Data/myfile.xml");

And to get the physical path to the Virtual Application’s App_Data folder you write:

HttpContext.Current.Server.MapPath("~/App_Data/myfile.xml");

The difference lies within the tilde (~) sign, as this defines the relativeness of the path. Adding a “~” to the path tells .NET that this path is relative to where I am.