I received an interesting SharePoint design today where the WebPart titles had two colors. Ex: the place for News and Announcements

I wasn’t really sure how to accomplish this since SharePoint renders the WebPart titles as simple h3′s with spans in them. At first I thought I’d just type html into the title area. So, I decided to put this in my title: the place for <span> News and Announcements </span>. Then I used css to do my colors: I made the .ms-WPTitle light grey and the .ms-WPTitle span green. But, of course it wasn’t that easy. SharePoint actually wrote out the word “span” instead of rendering it as html: Ex: the place for <span>News and Announcements</span>

At this point I thought I was stuck. I figured I was going to have to add content editor WebParts on top of all my other WebParts just to build titles. It was going to be a pain. But, as I was looking at the underlying html that SharePoint produced, I had an idea. It looked like SharePoint was setting to the html to the actual text literal. So, what if I use javascript to re-write the exact same text? Javascript should write it as html, right?

Anyway, without further ado, here is my javascript. I used jquery (because I have it in my masterpage). I am sure it can be done with regular javascirpt, but this was easier for me.

$(function () {
    //Replace webpart header text with html version
    $('.ms-WPTitle span').each(function () {
        $(this).replaceWith($(this).text());
    });
});

With the above javascript referenced in my MasterPage, it renders any html I put into a WebPart header now. I think it is a pretty interesting trick that could be used for all different kinds of designs.

SharePoint adds a new site collection for every user when their MySite is created. Recently I had a requirement to add a custom WebPart into a zone on the root page when the MySite gets created. I accomplished this requirement with the following:

• Feature to create the WebPart
• Feature Receiver to add the WebPart (this feature receiver ran off of the Feature to create the WebPart)
• Feature Stapler to activate the Feature to create the WebPart when the site collection is created

The Feature to create the Webpart and Feature Stapler were easy (standard SharePoint development). The Feature Receiver to add the WebPart to a zone on the page is where it got a little tricky and is why I felt a blog is necessary.

Steps

1. Create a new SharePoint 2010 solution in Visual Studio 2010
2. Right-click on your project and choose to add a WebPart Feature (you can use a regular webpart or a visual webpart).
   1. For purposes of this blog, we will call this “MySiteWebPartFeature”
   2. Make sure this is a “Site” scoped Feature
3. Right-click on your project and choose to add an Empty Element for your Feature Stapler
   1. For purposes of this blog, we will call this “MySiteFeatureStapler”
   2. Add a FeatureSiteTemplateAssociation to the MySite templates. Please delete the Id in the example below and replace it with the Id of the feature you created in Step 2
      <FeatureSiteTemplateAssociation Id=”9f8085c2-70cb-4ce1-814b-52e3967e5c3e” TemplateName=”SPSMSITEHOST#0″/>
      <FeatureSiteTemplateAssociation Id=”9f8085c2-70cb-4ce1-814b-52e3967e5c3e” TemplateName=”SPSPERS#0″/>
4. Right-click on your Features and choose “Add Feature”. This is for your Feature Stapler.
   1. For purposes of this blog, we will call this “MySiteFeatureStapler”
   2. Set the Scope of this Feature to “WebApplication”
   3. Make sure the “MysiteFeatureStapler” element is added as an Item in this feature. Also, go back to the MySiteWebPartFeature and make sure the “MysiteFeatureStapler” element is removed from that one.
5. Right-click on the MySiteWebPartFeature and choose “Add Event Receiver”
6. Add the following code in the Event Receiver

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    ThreadPool.QueueUserWorkItem(new WaitCallback(RunProcess), properties);
}

private void RunProcess(object state)
{
    SPFeatureReceiverProperties properties = (SPFeatureReceiverProperties)state;

    using (SPSite site = (SPSite)properties.Feature.Parent)
    {
        bool provisioned = false;
        while (provisioned == false)
        {
            provisioned = site.RootWeb.Provisioned;
            Thread.Sleep(5000);
        };

        AddWebPart(site.RootWeb.Url);
    }
}

private void AddWebPart(string url)
{

    using (SPSite site = new SPSite(url))
    {
        using (SPWeb web = site.OpenWeb())
        {
            try
            {
                SPLimitedWebPartManager wpm = web.GetLimitedWebPartManager("default.aspx", System.Web.UI.WebControls.WebParts.PersonalizationScope.Shared);

                bool webpartexists = false;
                foreach (Microsoft.SharePoint.WebPartPages.WebPart webpart in wpm.WebParts)
                {
                    if (webpart.Title == "My Custom WebPart")
                    {
                        webpartexists = true;
                        break;
                    }
                }

                if (!webpartexists)
                {
                    Treasury_MySites.PrivacyStatement.PrivacyStatement privacyStatementWebPart = new Treasury_MySites.PrivacyStatement.PrivacyStatement();
                    privacyStatementWebPart.ChromeType = System.Web.UI.WebControls.WebParts.PartChromeType.None;
                    privacyStatementWebPart.Title = "My Custom WebPart";
                    wpm.AddWebPart(privacyStatementWebPart, "TopZone", 0);
                }
            }
            catch
            {
                //do nothing
            }
        }
    }
}

In the end, the Feature Stapler needs to be activated at your web application level. When a new site is created within that web application the MySiteWebPartFeature will activate. When that feature activates it will add the WebPart to the webpart gallery (because that’s the standard behavior of a SharePoint WebPart feature). In addition it will run the custom Event Receiver code upon Feature Activation.

The magic of this solution is in the Event Receiver itself. It is using a seperate thread to make sure the root web gets provisioned before adding the WebParts to the zones on the page. Why is this important?

• If you don’t use a separate thread you could hold up the web from getting provisioned and you will just hang
• If the web is not provisioned there is no page to add the WebParts to

Is there other ways of doing this? At first I thought the WebProvisioner class would accomplish the same thing. But, that only works on sub-webs, not the root. Other than that, I couldn’t think of another way other than custom master pages or custom site definitions. I’d be glad to hear if anyone else knows another way.

So, we just launched www.treasury.gov on SharePoint 2010 in the Amazon cloud. During the course of this project we came across some interesting issues with SharePoint 2010 and I want to report our findings. The first issue we had to deal with is what we called the menu sticking issue.

Before describing the issue, let me explain our menu system. The asp.net menus, in SharePoint 2010, have a property called simple rendering. If this property is true, the menu system is list based (i.e.: ul/li). If this property is false, the menu system is table based. Best practices say that this should be true (i.e.: list based). However, our menu was designed with a fixed width and each section of the menu had a different width to match the word in it. So, it is a very rigid menu in terms of styling. Unfortunately, the simple rendering (i.e.: list based) menus in SharePoint do not put a unique id on each list item. So, we couldn’t size the items for our particular design with that type of menu. Thus, we had to go with the table based menu because each section gets assigned a unique id that we can size through css. I’m not sure if there is any correlation between using table vs list based menus and the bug we found, but I thought it is important to point out.

The second thing to note about our menus is that we use the hover property of the SharePoint asp.net menu to turn the background white when the user hovers over it. Thus, the menu looks like this when a user hovers over a particular section of the menu:

Sticking Issue

The “sticking” issue was a bug that was reported that baffled us at first. We were getting reports that the menu was getting stuck in a hover state. In fact, the background was getting stuck on white and the foreground was getting stuck on white too. It looked like the section of the menu didn’t even exist. Here is an example of what the issue looked like:

The biggest problem with the issue is that we had problems reproducing it. It seemed to happen intermiddently. Eventually we found out how to reproduce it. Basically, it only happend if the user moved their mouse over the menu during the page load. For some reason, when the page loaded up, if the users mouse was moving over the menu, this would happen.

Weird, right? So, I had do dig into what SharePoint was doing to create the hover state and it all has to do with javascript. Basically, the menu system builds this javascript in the page (near the bottom):

spBodyOnLoadFunctionNames.push(‘enableFlyoutsAfterDelay’);
Menu_HoverStatic = overrideMenu_HoverStatic;

Those two javascript methods can be found in the dynamic axd script that the SharePoint menu creates and they look like this:

function overrideMenu_HoverStatic(item)
{ULSxSy:;
       if (!flyoutsAllowed)
       {
              setTimeout(delayMenu_HoverStatic(item), 50);
       }
       else
       {
              var node=Menu_HoverRoot(item);
              var data=Menu_GetData(item);
              if (!data) return;
              __disappearAfter=data.disappearAfter;
              Menu_Expand(node, data.horizontalOffset, data.verticalOffset);
       }
}

function enableFlyoutsAfterDelay()
{ULSxSy:;
setTimeout(“flyoutsAllowed=true;”, 25); }

So, to simplify what they are doing, they are basically putting the mouse hover into an endless loop that only works when the attribute “flyoutsAllowed” gets set to true. That attribute gets set to true on a 25 millisecond delay after the page onLoad event happens.

It seems like they are trying to enforce the entire page gets loaded before the hover event takes place. Now, here in lies the issue. They don’t use a similar technique on the unhover. So, technically, the unhover can happen before the hover because of this technique used.

I went through this code a bunch of times and for the life of me I couldn’t figure out “why” they were doing it. It was pretty obvious “what” they are doing. But, I never found a reason “why”. You don’t need to wait for the page to load for hovers to work. One could assume they wanted to ensure all the html was there for the hover. But, this javascript gets ran at the end of the file, so it is a pretty good assumption it will be there. I came to the conclusion that there was no reason for this hover delay and that this is causing our menu “sticking” issue.

Luckily, SharePoint used a javascript override technique to build their function. So, all I had to do was copy their override method, take out the check for flyoutsAllowed, and the issue was fixed. I just put the following code into my custom .js file on my SharePoint site:
function overrideMenu_HoverStatic(item)
{
var node=Menu_HoverRoot(item);
var data=Menu_GetData(item);
if (!data) return;
__disappearAfter=data.disappearAfter;
Menu_Expand(node, data.horizontalOffset, data.verticalOffset);
}

That was it, the menu “sticking” issue was fixed. We tested this in all major browsers (even the dreaded IE6). We found no issues caused by this fix. I’m not sure why this bug hasn’t been reported yet. Maybe it has to do with out specific situation (SharePoint 2010, table based menus, with background changing on hover state). So, if anyone has a similar issue with this situation, mabye this blog will help you out.

When developing SharePoint components we often times get an error screen with this message:

Server Error in ‘/’ Application.

——————————————————————————–

Runtime Error

Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed.

Details: To enable the details of this specific error message to be viewable on the local server machine, please create a <customErrors> tag within a “web.config” configuration file located in the root directory of the current web application. This <customErrors> tag should then have its “mode” attribute set to “RemoteOnly”. To enable the details to be viewable on remote machines, please set “mode” to “Off”.

Server Error in ‘/’ Application.——————————————————————————–
Runtime Error Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed.
Details: To enable the details of this specific error message to be viewable on the local server machine, please create a <customErrors> tag within a “web.config” configuration file located in the root directory of the current web application. This <customErrors> tag should then have its “mode” attribute set to “RemoteOnly”. To enable the details to be viewable on remote machines, please set “mode” to “Off”.

In SharePoint 2007 we would go into IIS, find our virtual directory and change the CallStack from false to true and the customErrors mode from On to Off.  (reference)

However, that doesn’t seem to work for SharePoint 2010. I made those changes and I still got that annoying generic error message. As it turns out, SharePoint 2010 has a second web.config file located:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\web.config

That second web.config file contains the customErrors section that needs to be set to Off.

Central Administration has a second web.config file too if you need to see error descriptions their:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\ADMIN\web.config

This was very frustrating for me to find, so hopefully this helps someone else.