Lookup field workaround

I have never really worked that much with lookup fields to connect lists before. Usually a choice field and/or a managed metadata field is enough. Now a customer requested a couple of lists that were connected to eachother. "No problem" was my initial response, but yet again SharePoint would take me on a journey down the road of frustration.

The customer needed one parent list and two child lists. The parent list should display the title field and some choice fields from the child lists. Sounds really simple. When I started creating the lists I quickly discovered that it is impossible to use choice fields as lookup fields. The workaround is both simple and brilliant, see http://bramnuyts.be/2011/04/05/using-a-lookup-field-on-a-choice-field-workaround/. Now it works just as the customer wanted, as long as you hide the calculated fields in the default view and the item display form.

Yet another day in SharePoint paradise...

The evolution of SharePoint

After a year of working with SharePoint Online I reflected over what SharePoint have becomed. SharePoint is now a beast. It can almost do anything, except cure cancer. It is almost impossible to be expert of every aspect of the product any more. But new capabilities are not all a good thing. I'm worried that Microsoft have come to a point where the code base have become too much to handle. The fact that Microsoft itself cannot host the product properly any more fuel my thoughts. In my project we have had, in avarage, one severe hosting problem every week. This is not acceptable.

Even though you might be frustrated out of your mind sometimes when working with SharePoint you must always remember that you are not alone. I recalled this little gem on Stack Overflow. The guy is rather bitter, but he have some valid points. Read it and you will feel better! :)

Yet another day in SharePoint paradise...

The request uses too many resources

I currently work in a project where the solution is hosted in SharePoint Online and Azure. All communication between the web applications in Azure and SharePoint Online is done with the client object model. Before the summer vacation everything was working just fine. When we came back a couple of weeks later nothing worked. Our applications got a lot of "Ther request uses too many resources" responses from SharePoint Online. After getting past the first line support at Microsoft we eventually got to speak to someone who actually knew what they were talking about. We found out that Microsoft lowered the limit for operations in an execute query call during the summer without notifying anyone. The limit is controlled by the property ClientCallableSettings, see http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spwebapplication.clientcallablesettings.aspx. Since that kind of properties are untouchable in SharePoint Online we had to add several execute query calls on strategic places throughout our code.

Yet another day in SharePoint paradise...

Thumbnail view does not work with jQuery

I started using the thumnail view on a site that I was building for a customer. All of a sudden my jQuery script stopped working, but just on the thumbnail view page. After some digging I found that the thumbnail view resets the meaning of $, which is essential in writing jQuery scripts. Thanks a lot Microsoft!

The solution is to wrap all your jQuery scripts with the following function definition:

(function ($) {

    // Your custom jQuery code

})(jQuery);

This will work for your own scripts, but if you have imported third party script libraries that does not wrap their code properly, they will fail.

Yet another day in SharePoint paradise...

RichTextField require RichImageField

Usually when you create page layouts you always have image fields on your page. Recently I created a page with just one RichTextField. The problem was that the RichTextField did not render properly. It rendered just as an ordinary FieldValue in a ms-formfieldvaluecontainer. After some extensive trial and error I found out that RichTextField required at least one RichImageField somewhere in the page layout to work properly. Apparently the RichImageField adds stuff that also is needed for RichTextField. So my solution was just to add a RichImageField for the PublishingRollupImage field, which is a field inherited from the Page content type that you never use anyway, in an empty div with display none and the RichTextField was working just fine.

<div style="display:none">
    <PublishingWebControls:RichImageField
        id="ImageFieldSharePointBugFix"
        FieldName="PublishingRollupImage"
        runat="server"/>
</div>

Yet another day in SharePoint paradise...

Overriding application pages

Previously when you wanted to override an application page you deployed your new application page to the Layouts folder, and created a http-module which redirected any requests for the old application page to the new one. This method still works in 2010, but now we also have the method UpdateMappedPage on the SPWebApplication object. This method creates a redirection without the use of a http-module. You simply define which application page you want to override and provide a new url. Sounds sweet, doesn't it? But keep your pants on. You define which application page you want to override with the enum SPCustomPage. This enum has the following values: None, AccessDenied, Confirmation, Error, Login, RequestAccess, Signout and WebDeleted. Thats it. This means that if you want to override any other application page you still have to create a http-module.

Yet another day in SharePoint paradise...

Using SPWebConfigModification

Sometimes you need to add changes to web.config during SharePoint development. This is done by using SPWebConfigModification, see http://msdn.microsoft.com/en-us/library/bb861909.aspx. But there is one very big problem with the functionality of SPWebConfigModification, and that is the ApplyWebConfigModifications method.

If you use Microsoft's example in a feature receiver, which you probably would want to do, the method ApplyWebConfigModifications will, as the comment clearly describes, reapply all the configuration modifications each time it is called. Yes, ladies and gentlemen, lets read the sentence "Reapply all the configuration modifications" again. This means that if you have configuration modifications in different features and added one, all the other configuration modifications will be written once again to the web.config file. The method ApplyWebConfigModifications does not take in to account that the configuration modifications already exist in the web.config file.

The best solution I have found is not to use SPWebConfigModification at all. Manually changing your web.config files seems to be the best way.

If you still want to use SPWebConfigModification, do not try to be fancy and remove your configuration modifications because that does not work either. It is a bug in SharePoint 2010 and will never be fixed according to this thread http://social.technet.microsoft.com/Forums/en-US/sharepoint2010programming/thread/a77a3524-775c-4d04-9920-5bc831e5607a/.

Yet another day in SharePoint paradise...