Monday, January 16, 2012

My Sitecore Personal Trainer: Stack Overflow

There's nothing like getting your ego invested in your Stack Overflow rating (mine is a puny 173 at present), to get you working on your technical chops. I spent a few (too many) hours working on this question:

I've created aliases for the home page of one of the local sites (and it's child pages) in my national website - and I can't figure out how this is happening. When someone lands on a local page, I have a control (cs file) that creates the local links (to the child pages) on the left hand side of the local web page. These links are derived from the Sitecore context (current item's content path). After I created the aliases for all of the pages in a local site, that's when I noticed this problem. If the URL is a Sitecore alias, the navigational links are built for the child aliases - otherwise they are resolved by the Sitecore LinkManager, just as they were before the aliases were created. However, when I hit a page for the original local item (not the alias), the links are being rendered for the alias: childLink.NavigateUrl = LinkManager.GetItemUrl(child); And I've verified that the child item is valid. Does anyone have any suggestions as to why the LinkManager would be rendering the links for the aliases - and how this can be avoided?
I had a hunch this was a caching issue, and wanted to put together a hello world demo to prove this out. So I dusted off my sandbox environment, created a control that had the LinkManager.GetItemUrl and the RawUrl property, and set about to prove that:
  • LinkManager doesn't return alias paths, so he must be doing something else.
  • Whatever else he's doing will be captured by output caching if that is enabled.
And I ran into...
  • I had LiveMode.config left on, from months earlier, so I was always hitting the "master" database.
  • My WebControl was not getting cached, because I had not set overridden GetCachingID. Much painful debugging to figure that one out.

In the end, my hunch proved correct, and the slogging proved useful. But getting to 1,000 on S/O is going to be a painful business.

No comments:

Post a Comment