SharePoint 2007: Troubleshooting ‘Unexpected Error’ while editing web parts

One of the great things about SharePoint is the ability for non-technical users to update page content without the assistance of a development team. On the other hand, one of the terrible things about SharePoint is the ability for non-technical users to update page content without the assistance of a development team.

I recently had a client that was experiencing difficulties when attempting to edit web parts on certain pages in their Intranet site, running on SharePoint 2007. For starters, clicking on the web part’s Edit menu would make the browser window scroll back to the top of the page, rather than opening the Edit menu as it should. No big deal. Who needs to edit a web part, anyway?

If that wasn’t bad enough, any time they would drag and drop a web part to a different web part zone on the page, they would receive the wonderful “An unexpected error has occurred” error, preventing them from saving the changes to the page.

To add some madness to the mayhem, the issues only occur in Internet Explorer. Since IE is the only browser officially supported by SharePoint 2007, SharePoint uses a dumbed-down page editing interface in other browsers. While much less user-friendly, the simplified interface would allow my client to successfully edit and move web parts without encountering errors.

Troubleshooting the problem

As my first step in troubleshooting the problem, I edited the web.config file, turning off Custom Errors and enabling the stack trace output. The hope was that this information would point me in the right direction to solving the problem. While the new error message is much less cryptic than “unexpected error”, it was rather unexpected and perplexing at first.

“GUID should contain 32 digits with 4 dashes.” Gee, thanks! I know what a properly formatted GUID should look like, but a GUID is never used as user input on the page. Why is it passing in an invalid GUID to the SPWebPartManager? Shouldn’t SharePoint be able to keep track of these GUIDs on its own? This got me to thinking that something must be preventing SharePoint from determining the GUID of one of the web parts, thus causing the error. Buy why?

The page contained Rich Content area at the top with user-defined content in it, as well as a couple of Content Editor web parts, so I decided to investigate. And sure enough, I found the culprit.

When the user pasted in the HTML content for the Rich Content area, it must have been copied from a Content Editor web part at some point. Unfortunately, not only was the inner content of the web part pasted into the content area, but the outer wrapping DIV was pasted as well, including the ID of the previous web part. This was creating a conflict of web part IDs, causing the JavaScript function to fail when determining the GUIDs of the web parts on the page.

After removing the extra wrapping DIV and the ID from the content area and saving the page, the web parts began to function properly. If I took one lesson away from this scenario, it’s that users aren’t always careful about their input, and SharePoint is not good at offering help to the non-technical user. As with any Content Management System, SharePoint is prone to user error, one of the most difficult types of errors to troubleshoot.