Introducing SPUrlExpressionBuilder to resolve SharePoint URL Tokens


Introduction

One of the great things when developing with SharePoint is being able to use URL tokens such as:-

  • ~SiteCollection – this will resolve to the current site collection root
  • ~Site – this will resolve to the current web root

For an extensive list of SharePoint URL tokens, take a look at Namwar Rizvi’s SharePoint Insight blog post, http://sharepoint-insight.com/2008/12/01/list-of-sharepoint-url-tokens/.

If you have done much with creating or modifying Master Pages or Page Layouts then these tokens become very useful to locate resources such as images, XSL or CSS files.

For example, to reference an image which is stored in a SharePoint Publishing web’s Site Collection Images folder you could use something like this:-

~SiteCollection/SiteCollectionImages/myimage.png.

Recently, I have been working with multiple language user interfaces and wanted to be able to display a different image based on the language. One of the steps to do this was to work out how to process these URL Tokens.

Solution

This is where the SPUrlExpressionBuilder class comes to the rescue. This class is part of the Microsoft.SharePoint.Publishing.WebControls assembly.

To evaluate a string with a url token like ~SiteCollectionUrl/Images/MyImage.png you can use the following SPUrlExpressionBuilder class’s method EvaluateUrlExpression().

string imagePath = SPUrlExpressionBuilder.EvaluateUrlExpression("~SiteCollection/Images/myimage.png").ToString();

 

Creating List Instance: Object Reference not set to an instance of an object


Introduction

This one is a bit of an old issue but some of my posts are just to remind me of a time that I got stuck in the past. Also if it helps someone else then great.

It is possible to create a feature which creates an instance of a SharePoint List when its activated. However, sometimes you only want a list to be created on the Root Web of a site collection.

Issue

Well the XML for specifying a ListInstance as a feature has an attribute called RootWebOnly which I thought I could use to only allow the ListInstance to be created on the RootWeb.

Unfortunately when you do that you get a message like the following in your SharePoint ULS Logs when the feature is activated:-

Feature Activation: Threw an exception, attempting to roll back. Feature ‘FeatureName’(ID: ‘xxxxxxxx-xxxx-xxxx-xxxxxxxx). Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.SharePoint.SPListInstanceElement.ElementActivated(SPFeaturePropertyCollection props, SPSqlCommand sqlcmdAppendOnly, SPWebApplication webApp, SPSite site, SPWeb web, Boolean fForce)
at Microsoft.SharePoint.Administration.SPElementDefinitionCollection.ProvisionListInstances(SPFeaturePropertyCollection props, SPSite site, SPWeb web, Boolean fForce)
at Microsoft.SharePoint.Administration.SPElementDefinitionCollection.ProvisionElements(SPFeaturePropertyCollection props, SPWebApplication webapp, SPSite site, SPWeb web, Boolean fForce)
at Microsoft.SharePoint.SPFeature.ProvisionElements(SPFeaturePropertyCollection props, SPWebApplication webapp, SPSite site, SPWeb web, Boolean fForce)
at Microsoft.SharePoint.SPFeature.Activate(SPSite siteParent, SPWeb webParent, SPFeaturePropertyCollection props, Boolean fForce)

The offending Feature ListInstance element is below:-

 1: <?xmlversion="1.0" encoding="utf-8"?>
 2: <Elements
 3: xmlns="http://schemas.microsoft.com/sharepoint/">
 4: <ListInstance
 5: Id="AListId"
 6: Title="A List"
 7: Description="A List 
 8: Description”
 9: Url="Lists/ListUrlHere"
 10: OnQuickLaunch="FALSE"
 11: RootWebOnly=”TRUE”
 12: FeatureId="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx"
 13: TemplateType="45100"></ListInstance>
 14: </Elements>

Solution

To fix the feature activation remove the RootWebOnly=”TRUE” from your ListInstance element manifest file and instead move the RootWebOnly=”TRUE” into your List’s schema.xml.

To ensure that the list is only provisioned at the root web of the site collection change the Feature.xml to use Scope=”Site”

Update:

Thanks to Dennis who picked up my mistake in this post which stated that the RootWebOnly attribute should be moved to the feature.xml.

Fix: Content Editor Web Part Rich Text Editor Popup fails to display


 

Introduction

This problem has been bugging me for the past 3 days and so I thought I’d be kind and document it just in case it has been causing someone else problems.

So the issue is with the SharePoint 2007 Content Editor Web Part and when you edit the web part and click the button to show the Rich Text Editor you get a JavaScript error.

There does seem to be another post on MSDN (http://social.msdn.microsoft.com/Forums/en-NZ/sharepointcustomization/thread/90e14ff3-7003-44fd-9b4c-d9e654f7d8e1 that was showing the same issue and although the fix was related, the fixes that were specified in this post didn’t help me.

 

Issue

So as I have already mentioned when using the SharePoint 2007 Content Editor Web Part’s Rich Text Editor Dialog you get the following JavaScript error:-

Invalid Argument in HtmlEditor.js at line 5740, character position 2

On further investigation it is this line in the HtmlEditor.js file that is causing the problem.

elem=document.getElementByid(containerId);

Actually if you follow the JavaScript code then the issue seems to be down to the piece of JavaScript where the web parts are registered on the page. At the bottom of each SharePoint page is a section of JavaScript that looks something like this:-

 1: <script LANGUAGE='Javascript'>


 

 2: <!--


 

 3: WPSC.Init(document);


 

 4: var varPartWPQ1 = WPSC.WebPartPage.Parts.Register('WPQ1','[GUID]',document.all.item('WebPartWPQ1'));


 

 5: WPSC.WebPartPage.WebURL = 'http:\u002f\u002fsharepointurl';


 

 6: WPSC.WebPartPage.WebServerRelativeURL = '\u002f';


 

 7: //-->


 

 8: </script>

It seems that the JavaScript which creates the varPartWPQ1 variable does not work properly as the varPartWPQ1 is created without populating its ID property. This ID property is the value that is assigned to containerId in the line:-

elem=document.getElementByid(containerId);

 

The Solution

After a lot of trial and error I found that it was to do with the master page and a <meta> tag within the master page’s <head> tag.

The tag causing the problem is this one:-

 1: <meta http-equiv="X-UA-Compatible" content="IE=8" />

Removing this line and redeploying the master page fixed the JavaScript error.

This meta tag tells IE to run in IE 8 Standards mode which seems to cause a problem with the browser when its trying to get a document item using the function document.all.item([itemid]).

For more information on the <meta> tag please see the following article on Defining Document Compatability (http://msdn.microsoft.com/en-us/library/cc288325(VS.85).aspx)

 

Further Information

The reason for this happening was actually that the master page was being ported back from a SharePoint 2010 master page to a SharePoint 2007 master page.

This tag was left in from the SharePoint 2010 master page.

I really do hope this helps someone as it drove me mad for a while.

SharePoint Utility to manage Content Type and List Event Receivers


Introduction

Recently I have been building a solution which makes use of Content Type Event Receivers. The event receivers were being deployed using declarative xml for example:-

<ContentType ID=”[Removed]” Name=”My Content Type” Group=”My Content Types” Version=”0″>
<DocumentTemplate TargetName=”/_layouts/CreatePage.aspx” />
<XmlDocuments>
<XmlDocument NamespaceURI=”http://schemas.microsoft.com/sharepoint/events“>
<Receivers xmlns:spe=”http://schemas.microsoft.com/sharepoint/events“>
<Receiver>
<Name>MyEventHandler</Name>
<Type>ItemUpdated</Type>
<SequenceNumber>10000</SequenceNumber>
<Assembly>MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=000000000000</Assembly>
<Class>MyAssembly.EventReceivers.ContentTypeEventReceiver</Class>
<Data></Data>
<Filter></Filter>
</Receiver>
……

Now this normally works great, except when you make a mistake. Its quite well known that upgrading Content Types that have been defined using declarative xml can be tricky.

This is one of the reasons why Microsoft released Feature Upgrades in SharePoint 2010 (if you haven’t seen this then please check out Chris O’Brien’s set of blog posts (http://www.sharepointnutsandbolts.com/2010/06/feature-upgrade-part-1-fundamentals.html) on the subject).

In this case the development was on a SharePoint 2007 environment and I found myself in a situation with deploying Content Type Event Receivers.

It seems that once the Content Type had been deployed and the feature switched on its quite difficult to make certain changes to the content type. This includes changes like the following:-

  • changing a field’s default value
  • changing whether a field is required
  • changing the event receiver definition
    However, unfortunately Gary LaPointe’s stsadm commands would not working correctly for my content type and Gaetan Bouveret’s utility only manages list event receivers but does look very good at that!

Solution

Therefore I started to write my own command line utility. The first version was quickly written to get what I needed to do, done.

I have updated it so that at least its a bit more intuitive but it still only allows you to modify event receivers at a content type or list level.

Please be careful because if you ask it to delete an event receiver then guess what it will delete the event receiver!

As with all these utilities please do not try using this on your production environment without performing some testing on a development environment beforehand.

If you have any comments, problems with the utility please leave a comment and I’ll take a look..

Utility System Requirements:-

  • SharePoint 2007 SP2 (Tested on April 2010 and April 2011 Cumulative Update)
  • Utility must be run from machine which is connected to the SharePoint farm that is being modified.

Usage:-

Console application name: ITSP.EventReceiverConfig.exe

Command Line Arguments:-

  • -url : full url of site that hosts content type or list
  • -mode : [list | add | remove]
  • -targettype : [list | contenttype | assembly]
  • -targetname : [name of list | name of content type | name of assembly]
  • -assembly : [full assembly name including version number etc]
  • -class : [fully qualified class name that is implementing the event receiver]
  • -type : [itemadding | itemadded | itemupdating | itemupdated]
  • -sequence : [number bigger than 1]

The utility with releases, document and source code can be found on Codeplex.

Codeplex Project: http://itspeventreceiver.codeplex.com

Documentation can be found here: http://itspeventreceiver.codeplex.com/documentation

Issue with Updating SharePoint Publishing Page Layouts and Ghosting


Introduction

This post has come about due to some challenges when upgrading a publishing site page layout.

Before we delve into the issues I best explain how the Page Layouts are setup. The page layouts are all contained within a feature called “Company.Intranet.Publishing” which are deployed to the folder:

SharePointRoot\Template\Features\Company.Intranet.Publishing\PageLayouts.

Each of the page layouts are deployed into the master page gallery (/_catalogs/masterpages) using a Module. The page layouts are deployed as uncustomised or ghosted files.

The fact these resources are deployed as ghosted files is very important as you will see in the next section.

Finally the feature is deployed using the SharePoint Solution framework as a single SharePoint WSP using WSP Builder.

What do you mean by Ghosted / UnCustomised files?

There has been quite a lot of information published about this and the following are good resources:-

My understanding is that a ghosted file is where the binary content is actually stored on the file system of the server and a pointer to that binary content is held in the content database. If a user modifies the content of a page layout in a site collection by a tool such as SharePoint Designer then a copy of that binary content is taken from the file system and merged along with the changes made by the user and stored in the content database.

Hence when you retrieve an uncustomised file its binary content is being pulled from the content database.

Why are Ghosted / Uncustomised files preferred?

Recently at the SharePoint Best Practices conference, Eric Shupps and Rob Foster did a great presentation on Fine Tuning and Optimising SharePoint Performance. One of the key points in improving performance is to ensure that files are ghosted/uncustomised for the following reasons:-

  • Ghosted files all point to a single file and hence they all point to the same binary content. This means only one file needs to be cached and the load on the database is significantly reduced.
  • Actually Unghosted files cannot be cached within a BlobCache. Unghosted files are therefore slower to load and render (10% slower on average) than a ghosted file.

Upgrading Page Layouts

The method used to upgrade page layouts is simply by redeploying the files through an updated wsp solution file. We have also been careful through training and guidance with users to ensure that page layouts are not edited through SharePoint Designer.

Therefore if a change to a page layout is required, then the page layout is updated within the feature directory using Visual Studio and the WSP solution file is rebuilt.

The solution is then ready to be updated using the command:-

stsadm –o upgradesolution –filename [solutionname.wsp] –name [solutionname.wsp] –allowgacdeployment –allowcaspolicies –immediate

The change to the page layout is then reflected within the SharePoint site.

Why are my changes are not seen?

More history, our last deployment required that we tidied up the page layout’s title and description.

One of the problems with using a Module to deploy files within a feature is that with SharePoint 2007 it is difficult to make changes to existing files deployed by a module without resorting to code. Any changes to the filenames or properties that are deployed by the Module are not reflected until the file is deleted from the site collection.

As there were not that many site collections, we took the decision not to write any code and we modified the page layout titles and descriptions through the SharePoint UI.

Unfortunately when we did our next release into our testing environment the changes to the page layout markup were not seen within the site.

After checking that the page layouts were being deployed correctly to the the WFE’s file system we started thinking of the reason. Finally I thought it must be due to unghosting of the files.

Normally you can use SharePoint Designer to revert page layouts to their site definition. So I fired up SharePoint Designer and browsed to the /_catalogs/masterpages document library but could see that the Page Layouts were not customised.

I started to search for tools to find out which files are customised. The legendary Gary LaPointe (@glapointe) came to the rescue.

If you don’t deploy Gary LaPointe STSADM tools on your Production/UAT environments then I plead with you that you start to do so as soon as possible. Time and time again I have been in a bind and Gary’s STSADM commands have got me out of trouble.

The commands that saved the day this time are:-

The commands give a lot of flexibility, though I will warn you that you need to be a bit careful as you could quickly reghost all the files within your site collection if you are not careful.

I performed the following command:-

stsadm –o gl-enumghostedfiles –url http://sharepointsite.domain.com/

This displayed a list of files that were unghosted. Funnily enough all the page layouts that we had modified and changed their Title and Description fields had become unghosted!

Once we had a list of the unghosted page layouts we could reghost each of them in turn using the command:-

stsadm –o gl-reghostfile –url http://sharepointsite.domain.com/_catalogs/masterpage/RandomPageLayout.aspx –Scope File

This command would reghost each of the files, there were occasions where the page layout reghosting would fail, using the –force option for the gl-reghostfile would ensure that the page was ghosted.

Now looking at the site the page layouts had been updated and reflected the changes that had been deployed by the update solution.

Hope that helps!

Corrupted List Url Fix: Link to SharePoint List points to /_layouts/listedit.aspx?List=[ListGuid]


Issue

Had an issue at a client where a SharePoint task list got corrupted.

The issue had come about due to the list being copied using Metalogix SharePoint Migration Manager within the same site. The copy of the list had been corrupted so that if you clicked on “View All Site Content”, then clicked on the list name you were taken to the Edit List Settings page (/_layouts/listaspx.aspx?List=[GuidOfList]). Once in the list settings page, clicking on the breadcrumb to take you back to the list would take you to the web application homepage.

Solution

The fix was actually quite straightforward, if you typed in the url of the list correctly, http://sharepointsiteurl/sites/site/lists/My%20List%20Name, you could access the default list view with no problem. So I used a similar method to fix that I have used in this blog post, Manage Content and Structure error.

To fix:-

  • Delete the list using List Settings->Delete this list.
  • Restore the list from the recycle bin

Voila! The link within “View All Site content” is now working as expected.

Synchronization for Shared Services Provider ‘xxxx’ has failed.


Introduction

Recently we had an issue on a client’s SharePoint farm. The issue only occured on one SharePoint web front end and the following message was displayed within the server’s event log:-

Event Type: Warning
Event Source: Office SharePoint Server
Event Category: Office Server Shared Services
Event ID: 5783
Date:  dd/mm/yyyy
Time:  hh:mm:ss
User:  N/A
Computer: XXXXXX
Description:
Synchronization for Shared Services Provider ‘xxxx’ has failed. The operation will be retried.

Reason: Collection was modified; enumeration operation may not execute.

Technical Support Details:
System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
   at System.Collections.Hashtable.HashtableEnumerator.MoveNext()
   at Microsoft.Office.Server.Administration.SharedResourceProvider.SynchronizeConfigurationDatabaseAccess(SharedComponentSecurity security)
   at Microsoft.Office.Server.Administration.SharedResourceProvider.SynchronizeAccessControl(SharedComponentSecurity sharedApplicationSecurity)
   at Microsoft.Office.Server.Administration.SharedResourceProvider.Microsoft.Office.Server.Administration.ISharedComponent.Synchronize()
   at Microsoft.Office.Server.Administration.SharedResourceProviderJob.Execute(Guid targetInstanceId)

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Solutions

There were a number of solutions around including this thread, http://social.technet.microsoft.com/Forums/en/sharepointadmin/thread/d2d0e939-2e29-462e-a2f0-6f5e54f6e8fd

The thread talks about running the following commands:-

stsadm -o sync

This will force Sync on all Databases. Wait for some time may be an hour before running following commands.

stsadm -o sync -ListOldDatabases <Days>

This command will list out the databases which are out of sync for number of days specified.
You can also runfollowing command

stsadm -o sync -DeleteOldDatabases <days>

This will Remove Databases which it is unable to sync for number of days specified

stsadm -o sync

However when the command: stsadm -o sync -ListOldDatabases 1 was run then the following message was returned:

“No Databases met the criteria specified”.

Fix

The fix was to restart the Windows SharePoint Timer Job using:-

  • net stop sptimerv3
  • net start sptimerv3

No further error messages were received in the event log.