Don’t Use a Query String Parameter Called ID Unless You Mean the Item ID

The other day I got a question from my pal D’arce Hess (@DarceHess):

I am using jsLink on a couple lists and I have an interesting circumstance I’m running into.

Scenario: I have a list of Work Centers and each work center has associated machines that are in another list.

I’m having an interesting situation that when I click on the link in the Work Center, it is supposed to reload the same page and append the Work Center ID to the url  so that it will load the associated machines in the other list. I have the functionality working, however for some reason, when it adds the ID and reloads the page, it is changing the page layout from the layout that is chosen for the initial .aspx page.

Since it is literally re-loading the same page, just with an additional ID, I’m not creating new pages. Any ideas of what may be causing this?

After some back and forth about it, I realized that D’arce was using a query string parameter named “ID”. (I know, it should have been obvious to me right away, but we have a way of using shorthand when we describe technical issues that always makes a little back and forth useful.)

ID seems to be very reserved in SharePoint. Someone probably left some sort of back door thing in SharePoint once a long time ago, because I’ve seen using the ID parameter on the query string for anything other than the item ID cause issues way back to SharePoint 2007 at least.

By switching from ID to WorkCenter for the parameter name, all was right in the world again. For example, instead of “ID=1”, “WorkCenter=1”. Not only does this fix the issue, you end up with a query string parameter name that is more descriptive. That’s useful down the road for maintenance and will even make more sense to users. “That URL is ugly” may become “Oh, I’m selecting the WorkCenter”.