While working on the information architecture for an upcoming Sitecore project, I decided upon Sitecore wildcard items as the solution to my problem of sharing content. The general idea for the site is that an item only resides in one location in the content tree but is shared to other parts of the content tree using wildcard items as placeholders for the shared content.
When I first started testing out wildcard items in Sitecore everything seemed to work as expected… until I started using Display Names for the project. Then everything went to shit.
Problem Number 1: This first problem was a bit worrysome but luckily there was an easy solution. While developing with Sitecore v6.5, I found that turning display names on for the project caused the “Item Not Found” page to be presented when attempting to request a wildcard item in a language other than the default language. So I was successfully able to request the wildcard item in the default English language but not in French. So after some internet research and coming across this helpful post, I finally caved and contacted Sitecore support. It turned out to be the right decision as Sitecore support is aware of the issue and already had a patch for me to use! Thanks guys!
Problem Number 2: While I was originally doing some tests with wildcard items, I did not have Display Names activated for the Sitecore solution. Since I did not have to worry about multilingual URLs, that meant that each item’s URL was directly mapped to it’s structure in the content tree (ie: The path for an item matched it’s URL structure). This made working with wildcard items extremely easy because I could simply pick out URL segments from the item’s URL and use them to directly get another item using the getItem() method and specifying the path to an item as the parameter.
It wasn’t until after I activated Display Names that I realized that this approach would no longer work. The problem occurs because the Display Name option for an item allows you to set a different value that will appear in the URL structure. Because the name of an item can now differ from how it appears in the URLs means that I can no longer rely on using the path to find a wildcard item. Damn!
To be completely honest I am now halfway through my current project and I have not been able to find an efficient way to get wildcard items while using Display Names. At this point the best solution I have is to recursively walk down the content tree and query each child item in order to find the next url segment. So that means for each step down the content tree I compare a URL segment to each of the child item’s Display Names until I get to the end of the URL. I know, it’s ugly! I hope I will be able to find an elegant solution for this problem so I can revisit this post.
The only other piece of advice I have when dealing with wildcard items and parsing the URL segments is to remember to split the final url segment on the “?” character so you can get rid of all the querystring parameters that you will not want. This is pretty easy to see when you attempt to visit the page editor or preview mode while forgetting to truncate all the querystring parameters.
Conclusion: So my advice to anyone planning on using Sitecore wildcard items is that they should make a point to decide if they are going to need to use Display Names for the project before building any custom logic around wildcard items.
Since this is the first time I have used wildcard items in Sitecore I would really appreciate any advice other Sitecore developers have regarding wildcard items. Every little bit helps!