Tuesday, November 30, 2010

SharePoint commits a cardinal Document Management sin

Last night I spent time helping a colleague modify a SharePoint site home page. The objective was to speed up loading of the page. The number of lists and views on the home page was making load times really slow. At the same time we wanted to reset the theme to avoid some of the bugs that came with a poorly designed custom theme. 

Everything went well except for a couple of things. After deleting the unnecessary web parts page load times did not improve by any great margin. So I took a closer look. To do this you can open a page in Web Part Maintenance Mode. That is where you add ?contents=1 or &contents=1 to the URL.  In my case I decided to fire up SharePoint Designer 2007 and take a closer look.

Sure enough, there were web parts that had been deleted but they were still hanging around on the page. Deleting them blocks of code in Designer or Web Part Maintenance mode finally removed them.  Now the page loaded faster.

But there was still one problem...

The left navigation pane refused to adopt the style of the page. We attempted resetting the theme and various other resets to the navigation but all to no avail. 

This is where I came across SharePoint committing the cardinal sin of document management. 

The new page had a simple list of menu items that displayed as a series of buttons for users to select. The button style was accomplished by creating a list that had a calculated field that built the html for the button. In order to display the field as a button on the page it required two Content Editor Web Parts to be added to the page that incorporated some CSS and HTML code. Because these snippets of code were used in numerous places around the site so the code snippets were housed in a document library on the parent site. The two code snippets were:

1. Code to apply a box style using Cascading Style Sheets
2. Code to convert the <DIV>html code</DIV> calculated field in a list to valid html.

My keen eyed colleague noticed that when the code snippet that converted a calculated field to html was added to the page the left navigation pane changed format, no longer carrying the style of the page.

When I dug deeper into the code for the html code conversion I realized that when SharePoint saves a .html format file in to a document library it edits the document and adds a series of custom document properties. Somehow in doing this a line had been added in to the <head> section:

<title>Widget to create HTML from Calculated Fields</title><!--mstheme--><link rel="stylesheet" type="text/css" id=onetidThemeCSS" href="..//_themes/{blahblahblah}.css"><meta name="Microsoft Theme" content="{blahblahblah} 1011, default">
</head>

When I removed everything after the </title> down to the </head>, re-saved the file and reloaded the troublesome page the navigation pane stopped reformatting.

Surely this is a cardinal sin in Document Management if the system modifies the document. What appears to happen is when an item is uploaded to a document library SharePoint appends some custom Office XML to the file. In the case of a HTML file this gets incorporated in to the <HEAD> section of the file. 

What I suspect happened is that a site on which this code snippet was used changed site format. SharePoint went through the site and updated all html pages adding the theme information. This theme information was then interpreted when the code snippet was loaded by the page we were updating and over rode the default style set for the site.

The core issue is this.

  • The code snippet started as a text file with a .html extension. 
  • The only text in the file was a snippet of javascript  code contained between <script></script> tags.
  • When the file was uploaded to a SharePoint document library it was updated with custom properties in a <html></html> section of the file 
  • The <html> section then became a valid component for SharePoint to update when a theme was reset.

SharePoint shouldn't modify the content of a library item when it is saved.

Posted via email from More pre-blogspot than pre-posterous