Enable XSLT IntelliSense within Visual Studio

Wouldn't it be nice to have Visual Studio list the available template names when typing out a call-template statement in XSLT? Wouldn't it also be nice to have it list available parameter names when typing out a with-param statement?

To enable these autocompletions and more, you need to back up your registry and then run regedit. Within regedit, create a string value called "XsltIntellisense" under "HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\XmlEditor" key, giving it the value "True". That's it!

Ultimately, I'd like to see full IntelliSense for XSLT in Visual Studio, but this is a good start.

The type initializer for 'Sitecore.Search.SearchManager' threw an exception

If you get this (or similar) error, check that the version of the Sitecore.Kernel.dll referenced by class libraries is the same as used by the web site. It fixed a problem I had anyway!

ASP.NET Accessibility Top Ten

Here are my top ten tips for designing accessible ASP.NET sites. These are based on my understanding and opinion. If I am radically wrong about any of these, please feel free to correct me by leaving a comment.

Always set the display of validation controls to ‘dynamic’
In this way, screen readers ignore the text of the error message when there is no error.

Do not use image buttons
They are invisible to screen readers. Use a button with a background image instead.

Do not use AutoPostBack
They are impossible to navigate using a keyboard.

Do not use separator characters between links
Characters in breadcrumbs, footers, etc. are read out by screen readers. Use a span instead with a style instead. Or better still, use a bulleted list with a background image.

Display sets of results or links in a bulleted list
In a landing page or search results page, having each result marked up as a bullet makes it easier to navigate between results.

Insert hidden header text at the start of every navigation list
Screen reader users can navigate by headers and choose to skip the navigation lists.

Surround the individual digits in telephone numbers with span tags
Otherwise, the whole number will be read out as a single value.

Use hidden images with pagination and other non-descriptive hyperlinks
If pagination links are in the format: 1 | 2 | 3, a screen reader will read the links as ‘link 1’, ‘link 2’ and so on. So, insert a hidden image that has the alt text set to something more descriptive.

Include file sizes and types in hyperlink text
Unwittingly clicking a link to a file attachment can cause confusion.

Don’t bother using access keys
They are device-dependent, they can conflict with other shortcut keys and there is no standardisation as to what each key combination should do. Better to have clear navigation.

Using a Clean Sitecore Client for Authoring

I had a situation this week where I could not get the Sitecore client to work on my local machine. Although I could browse the end web site, I got the dreaded vague null reference exception when trying to browse to /sitecore. As the web site was fairly complex, I was finding it very painful to try to re-contruct from new. In the end, it dawned on me that all I needed to do was install a clean Sitecore client that was completely separate from the web site. This gave me the ability to change content, while the end web site enabled me to view the effect of code changes. This set-up has other benefits too; the Sitecore client runs unimpeded by any custom code (unless you are using pipelines, etc.). This makes it easier to identify/eliminate custom code as a possible cause for any slowness. Similarly, you can readily identify if any errors in the log are due to your code.

Value cannot be null

When trying to open the Sitecore client (ie. by putting /sitecore in the URL), I got the following exception:

Exception: System.ArgumentNullException
Message: Value cannot be null.
Parameter name: item
Source: Sitecore.Kernel
at Sitecore.Diagnostics.Assert.ArgumentNotNull(Object argument, String argumentName)
at Sitecore.Web.UI.HtmlControls.Menu.AddFromDataSource(Item item, String target)
at Sitecore.Web.UI.HtmlControls.DataContextMenu.OnLoad(EventArgs e)
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Control.LoadRecursive()
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

I noticed that the URL had changed to /sitecore/shell

With so few clues as to the cause, I simply entered the full path to the log-in screen (/sitecore/login). The log-in screen loaded and I was able to log in successfully.

Out of curiosity, I logged out again and then re-tried /sitecore on its own. The log-in screen opened OK that time. I've no idea as to the cause and I don't fancy investigating. If you're having the same problem, why not try what I did? Good luck.

Save Settings to Web.Config file

Here's a quick snippet showing how to save a setting back to the web.config file. You are best wrapping this block in a try/catch in case the ASPNET user (or equivalent) does not have write access permissions to the file.

Configuration config = WebConfigurationManager.OpenWebConfiguration( "~/" );
AppSettingsSection appSettings = config.GetSection( "appSettings" ) as AppSettingsSection;

if ( appSettings != null )
{
if ( appSettings.Settings ["mySetting"] != null )
{
appSettings.Settings.Remove( "mySetting" );
}
appSettings.Settings.Add( "mySetting", text );
}
config.Save( ConfigurationSaveMode.Modified );