Tag Archives: sitecore

Rendering Parameter Standard Values – where the bloody hell are you?!

If your Sublayout Parameter values are coming through as null in your sublayout control, it may be because the standard values on the parameter template itself aren’t passed through*.

Standard Values for your parameters on the template that uses the sublayout will be fine, and the values will appear when used on any particular template. But if you are tearing your hair out wondering why your value is null, head on over to the template and set the value directly on its own standard values**. You should find the value appears.

* I am using Sitecore version 6.5.0
** or even the item in question, but that’s just messy

Tagged , , , ,


I’ve been working in Sitecore for probably half a decade now (hmmm, really Aidan?) and until the last couple of weeks I have never come across this problem. And now I feel like I’m picking at a scab by being proactive in dealing with it.

You see, when Lucene writes to an index it creates a little .lock file so that no other pushy little processes can come along and try to write at the same time. And where does it put this lock file? You would think putting it in the index folder might make sense. If you didn’t, you should have because that’s where I think it should go. But I’ll give the Lucene developers the benefit of the doubt because in matters related to computer science I’d put money on them to smack me down in a fair fight.

So where does it go? Well, C:\Windows\Temp of course!

On my machine I didn’t have access to this folder. Our IT department rightly believes giving non-administrator users access to the Windows folder a bit of a.. risk. So when Lucene crashed the other day I had quite a bit of trouble getting at those pesky little lock files to remove them.

While I had a friendly email exchange with IT to open up temp folder access for me. I came across the Lucene.Net.lockdir app setting. Great, thinks I, and says to me self, “we’ll just set this to somewhere app-local, such as my App_Data folder that contains the indexes”.

But ’twas not to be so simple! After a few too many hours testing the various path combinations I wanted to use and blindly ignoring the posts I’d already read on the subject, I had finally satisfied myself that I now understood what this setting could do… and it’s quite simple:

You can only use an absolute local path

That means no relative paths, no ~/App_Data/indexes, no UNC paths to share folders. Just a plain old simple C:\yada yada yada\put my temp files here\ type of folder path.

I’d really prefer not to have to manage file system permissions for my app at another location, particularly in C:\Windows, but it means I now have to manage folder paths across my environments. It’s quite a trade off, because now I’m more likely to have problems setting up a new environment. Or, God forbid, another developer setting up their environment and troubleshooting the app when they’re not familiar with it.

What makes matters worse is the problem is not obvious to begin with.

When there are problems with the lockdir, you’re Sitecore application isn’t going to start up properly. And you don’t get a message, there’s nothing in the logs – it just hangs.

And boy can it take a while before you know whether it’s just a slow start-up or whether it is proper fucked. It’ll hang when you hit your front-end site, it’ll hang when you try to log into Content Editor. You can actually access the /sitecore/login page (hooray!), and perhaps if your front-end site doesn’t use Lucene you may be able to get to that also. But that’s your message – hang.

So next time you’re hanging about staring as your Sitecore app starts up.. just double check your Lucene folders. Check the path and check for the .lock files. It could just stop you having that psychotic episode on the way home from work.

Tagged , , ,

telnet ftw!

Another nifty debugging story today.

The goal was to unify my Sitecore keepalive URL across all environments. You see when you have not one but three production servers, managing your web.config becomes a real bitch of a problem, and the Sitecore UrlAgent is one of the most annoying.

For the purposes of this post, let’s call our site http://www.bobble.com. Why? Well the Bob part is obvious, and there’s no denying that Bubble Bobble wasn’t one of the greatest games ever. But I digress…

So, the solution is pretty simple. I create a local hosts entry and binding in IIS. I ensure the IIS binding uses the local IP so this will only work on the server.        bobble.localhost

I do this on all environments from dev through to production. I can now set my keepalive URL to:


Simple. Done. I fire-up IE (because this is Windows 2008 production and we don’t have luxuries like Firefox and Chrome installed) and hit the URL to make sure it’s working… FAIL.

WTF?! Why would this happen.. this is simple. 1) Update hosts file. 2) Update IIS binding on website. 3) THERE IS NO 3.. it’s that simple! I’m perplexed, completely perplexed. I check, I double check, I double check the double check. My checks become sextuplets. I’ve got a whole family of checks for my complex DNS configuration. I refresh the browser at least 20 times. So you get it, I’m banging my head against the wall. All I keep getting is the STUPID IE FAIL SCREEN!

I ping the host name. All good – IP is correct. I try it with the real IP instead of the loopback IP. No change. There must be someway to get some real info on the problem.

telnet to the rescue

It hits me.. I wonder if I can telnet to the site and get some kind of response? A quick Google, and… Yes!

Here is the eventual command line process. Open Command Prompt and enter the following:

  1. telnet
  2. set localecho
    so we can see what we are doing. If we couldn’t before we can now see the prompt
  3. Microsoft Telnet>set crlf
    something to do with the enter key behaving how we want it to.
  4. Microsoft Telnet>o bobble.localhost 80
    connects to the site. The cursor will probably jump back to the top of the command window but the output won’t be cleared. You’ll need to just type over the existing output.
  5. GET /sitecore/service/keepalive.aspx HTTP/1.1
    Host: bobble.localhost

Hit enter twice to send the request… we should now get the full HTTP output of the request.

UHUH!! Here’s our answer..

HTTP/1.1 301 Moved Permanently
Content-Type: text?html; charset=UTF-8
Location: http://www.bobble.localhost/sitecore/service/keepalive.aspx
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
Date: Thu, 26 Jul 2012 01:13:06 GMT
Content-Length: 182
<html><title>Document Moved</title></head>
<body><h1>Object Moved</h1>This document may be found <a HREF="http://www.bobble.localhost/sitecore/service/keepalive.aspx">here</a></body>

I remember now. There is an IIS rewrite set up in the web.config that redirects all non-www domains back to the www.* domains. And because I don’t have http://www.bobble.localhost set up (in IIS nor DNS) the browser can’t even get close to finding it!

With telnet I was able to get the exact request details, without any silly attempts by the browser to redirect. This is going to be mighty useful in the future.


Tagged , , , , , ,