Avoiding SharePoint Internal Name Pain

For the majority of users, the inner workings of SharePoint don’t hold much interest, but there is one aspect that you might find worthwhile to understand, especially if you are responsible for creating lists or libraries that yourself or others may want to customise later with XSLT, DisplayTemplates or even access using the Client Side Object Model (CSOM).

You’ll notice that I mentioned XSLT and Display Templates in the same sentence there, not just because XSLT hasn’t gone away completely in SharePoint 2013, but also because what I’m writing about here applies equally in SharePoint 2007, 2010, 2013 and Office 365.

Developers have been aware of SharePoint internal name pain for sometime. Ever since the first time I ever wrote a CAML query, I swiftly became aware of the difference between the display name used in the SharePoint UI and the name that SharePoint used under the hood. For the average end user however, they frankly don’t care because they never see the issue.

What is SharePoint Internal Name Pain?

Let me give you a (completely made-up) example:-

Jane is an Export Executive for the Ivory Coast Trading company, a company responsible for the export of various crops and spices from the ivory Coast. She needs to keep track of both the number of Coffee Beans shelled each month and the number of coffee beans subsequently sold.

She creates her list and starts to add some columns. The first column she adds is a simple number field, which she names "The Number of Ivory Coast Coffee Beans shelled".

Ok, a slightly exaggerated example, but there’s good reason as I want to show you what happens not just to names with spaces, but also those names over a certain length.

After our column is created if we click on the column name in our list settings to enter the edit column screen and cast our eyes to the address bar in our browser, we can see what SharePoint has called our column internally.

This dear reader is an example of SharePoint Internal Name Pain! And just to confuse matters, the browser has encoded our actual name a second time! Let’s dissect this a little.

The browser is displaying the following in the Address Bar:-

The%5Fx0020%5Fnumber%5Fx0020%5Fof%5Fx0020%5F

This is actually the internal name, encoded for use in a URL, the actual internal name replaces the %5F with the underscore "_" character:-

The_x0020_number_x0020_of_x0020_

But that’s not much better! SharePoint has replaced the single space character with 7 new Characters (This is called Unicode encoding) which not only means we’ve added a LOT of characters to our internal name, we’ve also hit the SharePoint limit of 32 characters. As a result when you view the internal name it really doesn’t mean anything and certainly doesn’t tell you what data is being held in the list column.

And as if that on it’s own wasn’t painful enough, Jane has just added a second column to represent the "The number of Ivory Coast Coffee Beans sold"

If we do the same trick as before, decode the value in our URL by replacing the %5F with the _, you’ll find we’re left with:-

The_x0020_number_x0020_of_x0020_0

As we hit the character limit, SharePoint realised that we already had a column with that name, so it helpfully stuck a 0 on the end! So we now have 2 almost identical internal names and no easy way to ensure which ones which without going into the list settings each time and testing.

The Solution?

Well the solution is quite simple; just make sure that you are sensible when creating your list columns in the first place! Avoiding the use of non-alphanumeric characters in your names will make them much simpler to read.

In our example above, Jane could have created the columns using the names ICBeansShelled and ICBeansSold. Once the columns have been created, you can then change the Display Name to be anything and the nice neat internal name remains the same.

I’m just an end user, why would I care?

Firstly your IT Pros will thank you, especially if you ever ask them to go an do anything on the server through powershell that requires them to do anything to your lists.

Secondly, your Developers will certainly thank you… writing CAML queries at the best of times is hard enough. Adding long meaningless field names to that just makes their job ten times harder and delays the delivery of whatever you’ve asked them to do.

And finally, if you’re a power-user (or aspiring to be one) then you will thank yourself as soon as you open SharePoint Designer and play with a list view, or start to write a display template in JavaScript and need to access your data through the context object.

ctx.CurrentItem.The_x0020_number_x0020_of_x0020)

ctx.CurrentItem.ICBeansSold

I think at this point, you’ll agree which is the easiest to read and understand. Especially when you go back 6 months later to make a change! You’ll be glad at that point that you learned to avoid SharePoint Internal Name Pain!

Paul.