Recently I worked a case where the customer was not able to create publishing pages at all. Whenever they trying doing so, it errors out in the browser and in the ULS logs we see the following stack:
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index at System.ThrowHelper.ThrowArgumentOutOfRangeExceptionat System.Collections.Generic.List`1.get_Itemat Microsoft.SharePoint.SPFieldMultiColumnValue.get_Itemat Microsoft.SharePoint.Publishing.PageLayout.get_AssociatedContentTypeIdat Microsoft.SharePoint.Publishing.PageLayout.get_AssociatedContentType at Microsoft.SharePoint.Publishing.PageLayout.get_UIDisplayNameat Microsoft.SharePoint.Publishing.PageLayoutComparerByUIDisplayName.Compareat System.Collections.Generic.ArraySortHelper`1.SwapIfGreaterWithItemsat System.Collections.Generic.ArraySortHelper`1.QuickSortat System.Collections.Generic.ArraySortHelper`1.Sort
Following the stack, one can see the issue is with getting the associated content type Id information. This makes sense because when we try to create publishing pages, we get directed to /_layouts/CreatePage.aspx which lists all the available page layouts in a list control to create our page from.
Hmm! So, something is causing that enumeration to bail out. Further digging and probing, we saw that most of customer’s page layouts were “corrupt”. Huh! How do I say this? I say this because when I visit /_catalogs/masterpage/forms/allitems.aspx page at a good environment, I get to see the page layouts available as shown in the below screen shot.
Note the “Associated Content Type” column. The values for this column for page layouts are like “Article Page”, “Welcome Page” etc.,
There are a few page layouts without associated content type information – that’s okay!
But at my customer’s environment, the values for associated content type for these page layouts were displayed as:
Hmm, that’s not right!! Digging more from the database we saw the data that’s supposed to hold content type association information were messed up.
As an example, a typical content type association data will look like:
;#Article Page;#0x010100C568DB52D9D0A14D9<and a really long GUID kind of thing>;#
But at customer’s environment, this was stored as:
Article Page,0x010100C568DB52D9D0A14D9<and a really long GUID kind of thing>
Notice, there’s no ‘;#’ in the beginning, in the separator between the content type name and Id and in the end.
So, what did they actually do? Probing continued…
After more probing and good amount of research, this is what the customer did to get into this situation (Oh yes, this is SharePoint 2010 version dependent, it was SharePoint 2010 June CU 2010 environment we worked on):
There it was, I had June CU 2010 installed followed the above steps and go to see the same issue customer reported. Unfortunately, it turned out to be an unsupported scenario: http://support.microsoft.com/kb/2492356. However, the contradicting behavior observed to what’s published in the KB led me believe this could be something to do with June CU 2010 patch.
What’s the fix? So, the idea was to ensure we turn all those ‘#VALUE!’ things to read “Article Page”, “Welcome Page” etc., Well, it was easy as it sounds. Since we were in kind of disaster recovery situation (the customer had almost 100 sites created this way), I wrote a tool that would look at a site with “good” data in it (in this case, a site where publishing infrastructure & publishing features are enabled at the site collection and site levels respectively) pick up the page layouts in question and overwrite them in the target site with “bad” data. Simple yeah?
I’ve enclosed a sample code that does just this (click Download link below). It uses SharePoint 2010 server object model and has to be run on the SharePoint 2010 server. Feel free to download, modify & use it! Hope this helps out if you ever run into this issue.