SharePoint error The URL ‘Pages/default.aspx’ is invalid

November 28, 2013

On a recent project I was working on an Intranet which had the publishing infrastructure feature enabled. I was working on setting up some pages and configuring web parts when I noticed an error on saving or checking in a page, see figure 1 below.

The URL ‘Pages/default.aspx’ is invalid. It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not in the current Web.

Figure 1

As with most errors in SharePoint I cracked opened the ULS logs. Its slightly more difficult to find relevant data in the ULS logs without a correlation ID but after searching for the error text I was able to locate the ULS details for the page request. Unfortunately there was no further details around what was causing the error.

I then turned to Google and had a look for the error message. I found quite a few articles but pretty much all of these related to database issues. Most talk was about space on the database server or databases being read-only, however none of this was relevant to me.

At this point I couldn’t find any details in the ULS logs or online so I decided to start stripping back my solution component by component to see at which point the error occurred. While the site was still in development there were a lot of steps to replicate. I started by spinning up a new web application and then applying the changes one by one. After each change I was creating a new page and editing an existing page to test if the site was broken.

In the end it turns out the issue was a PowerShell script which was being run to create some site columns. This had been created to quickly provision site columns which are commonly used across most projects.

Once I had identified the source of the issue I then had to figure out if it was a particular site column which was causing the issue. I started commenting out sections of the script and I was able to narrow it down to a particular column. The problematic site column was a calculated column and as soon as I commented this out and deleted the column the site started to work again. I’m not sure why this was causing an issue but it can be easily created manually so i removed it from my script.

Hopefully this helps others as all the articles I found online all pointed to a database issues so keep in mind it could be a corrupted site column as well.

Happy SharePointing 🙂


Error editing publishing page in SharePoint

November 25, 2013

While working on a recent project I was navigating our development site and when I tried to edit a page I got the standard SharePoint error screen, see figure 1. There was very little customisations on the site as it was still in the earlier stages of the development process so I was slightly confused as to what the issue could be.

image

Figure 1

As with most SharePoint errors the easiest way to get to the bottom of the issue is to check the ULS logs so I copied the correlation ID and opened up ULS Viewer on the server. I opened the latest ULS log file and filtered by the correlation ID. Looking through the log file I finally found the details of the error, see Figure 2.

Application error when access /Pages/default.aspx, Error=Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index
at Microsoft.SharePoint.SPFieldMultiColumnValue.get_Item(Int32 index)

System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index
at Microsoft.SharePoint.SPFieldMultiColumnValue.get_Item(Int32 index)

Getting Error Message for Exception System.Web.HttpUnhandledException (0x80004005): Exception of type ‘System.Web.HttpUnhandledException’ was thrown. —> System.InvalidOperationException: Failed to compare two elements in the array. —> System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index
at Microsoft.SharePoint.SPFieldMultiColumnValue.get_Item(Int32 index)

Figure 2

Looking over the details it wasn’t obvious what the actual error was but it seemed to point to an issue with the page layouts so I decided to review all custom ones to see if there was anything obviously wrong. I opened the site in the browser and navigated to the master page gallery. When I tried to edit one of the custom page layouts I got an error, see figure 3.

image

Figure 3

The error seemed to be highlighting an issue with the content type the page layout was associated with so I returned to the master page gallery and hovered over the associated content type link, see RHS column on Figure 4, and I could see the URL on the bottom of the page was “_layouts/15/ManageContentType.aspx?ctype=#VALUE!” whereas it should contain the ID of the content type.

 

screenshot2

Figure 4

Normally this would not be an issue with page layouts uploaded via the browser or SharePoint designer, however in my case the custom page layouts had been uploaded into SharePoint via PowerShell.

I checked the PowerShell script and I could see the original version uploaded a page layout into the correct location, however it was setting the associated content type property of the page layout to be a string, see figure 5. I knew from previous experience this needed to be a concatenated string but I couldn’t remember the exact format so I quickly put together a test script which got the value of an OOTB page layout. Using this script I could see the value actually had to be a concatenated string of the content type name and ID, see figure 6 for updated PowerShell.

Incorrect version
  1. $newFile.Item["PublishingAssociatedContentType"] = "Article Page"

Figure 5
Correct version
  1. $newFile.Item["PublishingAssociatedContentType"] = ";#Article Page;#0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900242457EFB8B24247815D688C526CD44D;#"

Figure 6

As the site was still in the early stages of development I was able to easily delete all pages which used the custom page layouts, delete the page layouts and re-upload them with the corrected script. I then double checked the associated content link in the master page gallery, see figure 7, and it was correctly populated. After that I was able to edit pages and content within the site.

screenshot 
Figure 7

Hopefully this saves some other people some time and I suppose the key lesson would be, as always, be careful with PowerShell and double check its actually doing what you expect.


%d bloggers like this: