When you run Sitecore 6.x in Integrated Pipeline Mode, You will notice that ALL IIS log entries contain the log entry for the resquest to the layout (aspx) page (instead of the actual sitecore item .e.g /ContactUs.aspx).

If you run Sitecore in Classic Mode, the problem disappears. However, if you still wish to use Integrated Pipeline Mode, you will have to intercept the request before the Sitecore HttpModule (Sitecore.Nexus.dll) gets involved.

Solution

Create a class that extends System.Web.IHttpModule and set the path back to the original value after the request has been processed but before the IIS logging module writes the log entry.

I wanted to set the QueryStringField property of the DataPager dynamically. By default, if you do not specify this property, the pager works on a Postback Model.

On the other hand, if you do set the QueryStringField to something, it'll use the value that you set the QueryStringField to as a query string parameter and assign it the appropriate page number (IOW, it makes use of a query string parameter to change the page view)

So far...So good..

Using the above example, since we've set the property in the code behind, we'd expect the pager to use a query string to drive the page view. Commenting the line out forces the pager to use a postback model.

What about .Net 4?

the above situations work when the project is set up to run in .NET 3.5 . However, this solution does not seem to work with .NET 4.0 at all. If we set the Target Framework to 4.0, the paging does not work if we want to force a QueryStringField at runtime :(

I once inherited a sublayout that inlcuded an asp:xml control. The asp:xml control was there to handle and display an xml feed from another system, while the rest of the sublayout concentrated on rendering related feed content from Sitecore. The presentation of the xml feed was handled via an xlst rendering.

In this particular situation, I made use use of XSL extensions in the XSLT file. Registering the XSL Extension was fairly easy.

This article will focus on the implementation of the AjaxControlToolkit's AutoCompleteExtender into a simple ASP.NET application. What I'm trying to do here is pull the data from a database and use the AutoCompleteExtender to display the data as the user types characters in a textbox.

Server Implementation

Im not going to focus on how to retrieve the data (from a table of around 60,000 records). I'm going to use the simplistic SQLConnection/SQLCommand/SQLDataReader classes and passing sql command as plain text (as opposed to Stored Procedures). The key issue is how and what is the best way to store the data once being retrieved. Generally, Autocomplete comes in 2 flavours:-

1: Find words based on letters anywhere in a phrase (performing a LIKE '%ar%' in SQL).

2: Find words that start with specific characters ( LIKE 'ar%' in SQL).

In the first instance, you're pretty much tied up to using the LIKE clause (be it in a stored proc or simple text). The determining factor here is how and when to cache the data since each character typed in invokes the webservice and queries the database. Each query will yield a different result set.

In the second instance(the focus of this article), the more you add characters to the keyword, you are, in fact, narrowing down the scope of search. This means that the data we initially load is deterministic and hence we can cache it somewhere. But the real deal here is :which data structure do we hold our words in? List<>, DataTable, Linked List??

Trie

You might have already figured this one out. Anyway, a trie is an ordered tree data structure (a.k.a prefix tree) that stores the information about the contents of each node in the path from the root to the node, rather than the node itself. What this means is that each part between the root and any leaf represents a key and the goal is to find the key by traversing the tree.

Setting up the AutoCompleteExtender was easy. To get the autocomplete working, I only had to modify a few of the extender's attributes (.e.g. CompletionSetCount, TargetControlID, ServicePath, ServiceMethod, DelimiterCharacters ..) and data was being returned as I typed in characters. However, making the extender look good was a different story.

Client-Side Implementation

This is the bit where I'm open to suggestions. I'm no Javascript/JQuery expert but however, I finally got the extender working as I wanted it to. Characters relevant to the ones the user has typed become highlighted in the drop down list. It took me a while to dig this solution out. The javascript is awkward and needs to be refactored. Netherless, the solution works for IE and Firefox [ good enough for me :) ]

A test Sitecore Application .. I will be using the Sitecore Starter Kit [Sitecore Starter Kit 6.0.0 rev.090203] as an my starting point. (installed on IIS 7).

Before I start on implementing the solution, a little bit of background info would, I guess, be quite useful.

AddAspxExtension in LinkManager

A potential solution is to change the value of AddAspxExtension from true (by default) to false. If you do change it to false, you will have to create a wildcard script map to the ASP.NET runtime. This causes IIS to intercept every request made against the web server. This includes requests for images, asp.net pages and HTML pages. Therefore, enabling a wildcard script map to ASP.NET does have performance implications. If you wish to find another way to use pages without .aspx extensions in Sitecore, please read further....

Sitecore Aliases

Aliases, in a nutshell, allow you to shorten the url of an item. For example, if your item is currently accessible via http://hostname/MyParentItem/MyChildItem.aspx, you can specify an alias of myChildItem, which will be a placeholder for the actual item as it is in the Sitecore tree. Hence, the url of the alias is http://hostname/MyChildItem.aspx. For SEO purposes, this allows us to surface items from deep down in the hierarchy right up to the site root.

Note:

Aliases do not work if you remove the .aspx extension

No matter how far your items are in the sitecore tree, an alias allows you to refer to it from the site root.

Step 1: Install and Configure Helicon ISAPI Rewrite Lite

Start by installing Helicon ISAPI Rewrite. This process is fairly straightforward. Since we are using the lite version, our Regex entries will be placed in the global http.conf (located in the Lite version installation folder). The entries in my httpd.conf are as follow:-

Url Rewriting Rationale

Before a request is forwarded to Sitecore, the ISAPI module intercepts it.

Line 1: You NEED that ! This turns on the Helicon ISAPI Module

Line 2: Errr...This is self-explanatory..

Line 3: We don't need to chop off the .aspx when we are in Sitecore CMS. For this reason, we're basically telling the module to not do anything when a request has "sitecore" in it.

Line 4: This is the most important bit. This appends .aspx (and querystrings,if any) to requests and consequently forwards the resulting request to Sitecore. Two scenarios arise as a result of this.

3.1 : Sitecore maps the request to an item in the database. The page gets displayed in the end.

3.2 : Sitecore cannot find the item based on the url. You will either end up with the Sitecore's "Item Not Found" page.

NB:

Before we go any further, I need to confess that I did modify the Starter Kit a little prior to this operation. Basically, when you load the starter kit, you are greeted with a dummy home Site, that has a nice layout and there is a link to the Actual Starter Site. I was tired of this as my home page, So, I changed the value of "startItem" [in the Sites Definition of website (in web.config)] from "/home" to "/Sample". In that way, when i hit the website, I will eventually land on the real starter site!. Also, by doing so, all my urls within the website will no longer contain "/sitecore/content/.." since the Start Item has changed.

It looks like we have a half-baked solution. Aliases will now work without the .aspx extension as well. The other bits that need to be considered are

1 : How to make sitecore controls (.e.g. sc:link etc..) aware that they should drop the ".aspx" extensions

2 : How does it all tie up together with .NET (user controls etc..)

Step 2: XSL Extensions (revised)

To follow up on custom solution, you will need to tell Sitecore to remove the ".aspx" when it renders urls (either via sc:link [xsl extensions] or c# code). For XSL Extensions, we need to disable the default implementation that Sitecore provides us with and roll out our own. Fortunately, it's very easy to do so. [Credits : Chris Wojciech ]

NEARLY THERE!!!. All the links (that are rendering using sc:link) have now lost the .aspx extensions on the front end.

Step 3 : Sitecore and .NET interaction (with Url Rewriting)

If you have a Sitecore solution built using XSLT renderings only (highly unlikely though..), you're kinda safe here. However, if you have usercontrols (that host controls that can cause a postback) as well (for argument's sake, a contact us form), you end up with one issue.

Let's create a Contact Us form and add it to the presentation of the Contact Us item in Sitecore

It's the third time I'm writing on this particular topic (The EncodeNameReplacements element in the web.config). Articles 1 and 2 have had their importance in building SEO-friendly links in Sitecore.

Double Encoding in Urls

Whilst doing some routine administrative tasks in sitecore, I noticed that some links were no longer working. I was pretty sure that those links were working before I did a publish. :( Back to the drawing board.

in my web.config. It was working fine when sitecore items were having names like "Camera one" (->url: camera-one.aspx), "Camera one two three" (->url: camera-one-two-three.aspx) etc...

However, if an item name has a character that has already been defined in my EncodeNamesReplacements section, Sitecore throws you back on the Item Not Found page. In my situation, I had renamed the Sitecore Item :"John Doe" to "John-Doe" (lame administrative task...I KNOW) . The effect of this is that when the user clicks on the John-Doe.aspx, he/she is redirected to the default "Item Not Found" sitecore page. A careful look at the url has revealed that Sitecore was trying to request an item with a name of John--Doe and consequently failed.

Solution

or hack (for some people)

If you are using a specific character to get rid of spaces in url, you need to make sure that a cms user will not be able to create an item name having that character in. Easy way to factor this in is to include your character in the InvalidItemNameChars element in the web.config. In my implementation, I've changed that setting to :

Here's the situation. You are about to implement a password protected area on your website. Let's assume that the general site structure looks like this

Pages below General and Products are accessible to everyone, whereas pages under Members should only be visible to authenticated/logged in members. I will first briefly outline the steps required to get this problem implemented using ASP.NET. Later on, I'll move onto it's equivalent Sitecore Solution.

Using ASP.NET

Implement Forms Authentication and set login url in the web.config.

Implement Login control and decide where to retrieve and store login credentials (in web.config or database)

In the web.config, add a Location Path pointing to the Members folder (Deny anonymous , allow authenticated users )

This is all about it really...(as far as I remember..) ...

In Sitecore, it's a different ball game.

In addition to adding the loginURL to the form authentication section (important if you use the loginview control to show the login page), you will need to add the "loginPage" attribute to the site which is defined by your extranet domain (normally, it's called "website" )

The LoginPage attribute is not something new here..It has always been there..(e.g. the shell website has already a loginPage set), but i did not know what was its purpose . Thanks to Chris Wojciech, I've discovered how to use this existing functionality in the web application.

The addition of Location path in the asp.net-only model is analogous to denying read access to the Members folder (+descendants) in Sitecore.

Once you perform a site publish, you can see the effects straight away.

If you've already signed in, you will be able to view /Members/View My Account.aspx.

If you're an anonymous user and access /Members/View My Account.aspx, you will be presented with a default page that Sitecore serves in case access is denied due to security privileges.

Recommended Solution

The nag in the above quick fix is that sitecore internally adds 3 QueryStrings to the url ( item, user and site). If we compare this to the normal ASP.NET solution, we would have ended up with only 1 querystring, which is the ReturnUrl. Our goal is to follow the asp.net solution as close as possible. This is where Chris comes in..

Rolling out your own Security Resolver

Chris extended the HttpRequestProcessor class in order to intercept the request ,check if the user requesting the sitecore item has appropriate rights. If that is not the case, the user is redirected to the login page, with the appropriate ReturnUrl QueryString. Please go check the code out on his blog at http://blog.wojciech.org/?p=64

The processor should then be plugged in the web.config, before the definition of the ExecuteRequest processor.

LoginView Control Caveat

The LoginView control "magically" knows the login page url. This is specified by the LoginUrl attribute in the FormsAuthentication section of the web.config. This is not to be confused the LoginPage attribute (from the sites section). I had to modify my web.config to

Erractic Behaviour when logging out

I did not experience any problems when logging in .i.e. the control did what is was supposed to do (display sitecore username and Logout Link). HOWEVER, when I pressed the Logout link, I always got redirected the Sitecore Layout page instead. I did spot similar behaviour with ListViews in Sitecore (also documented by Paul George and Mark Cassidy, where its events were not being fired at all. I've made the following change to my web.config and that solved the problem :)

I guess that a value of "00:00:00" for the interval attribute does disable automatic publishing. If you set the value to (say..10 minutes) "00:10:00", you will notice that after 10 minutes or so, changed items from the master database will be copied over to the web database.

Automatic publishing is useful where you have integrated external datasources in sitecore (using Data Providers) and where there needs to be a predefined process that synchs the external data to the web database. For the automatic publishing to work in this particular situation, you must have had created a new database entry (with a reference to your data provider) in the web.config.