The following post has already been published in the latest SDN Magazine number 107.

Why going mobile?

In the last few years information workers are starting to use other devices then their client computer at home to communicate, socialize and share content with others. This happens inside and outside organisations. The amount of smart mobile devices, like smart phones and tablets, has grown exponentially and is now starting to be used world-wide as a second source for information and collaboration. 

While a lot of these devices have the ability to view a website like it is on your client computer browser, in some cases the device is still to small and to difficult to control the navigation on those websites. Due to to massive amount of content on websites it is difficult to get a good overview of that content, while it also takes to long to load to your device which is depending on slow/medium wireless connections.

 You can imagine that in some cases it would be handy to have a thinner web application which is also perfectly suited for the size of your screen. SharePoint 2010 offers (just like its predecessor) the ability to view and control your web application perfectly suited for you mobile device.

Mobile access

SharePoint 2010 offers the ability to access a SharePoint website through a mobile device like smart phones by using so called mobile pages. Especially when the mobile device does not have all the neat features as today’s browsers have or when its screen is too small to actually view a complete website.

Figure 1 Example of a SharePoint website on a mobile device.

SharePoint Foundation offers the extensibility to work with pages, controls and Web Part adapters which are used for accessing SharePoint Foundation websites through mobile devices. It has an architecture to support mobile access to SharePoint pages and list data.

Mobile applications

SharePoint has an automated redirection system which detects if a request came from a mobile device and automatically changes the request URL to the mobile substitute of its nonmobile page. A nonmobile page is called the “target page” of the mobile page.

It is also possible to access the mobile page variant of a site through a web browser by appending the parameter “?Mobile=1” to the end of the URL. By using the parameter “?Mobile=0” you can force the URL to retrieve to nonmobile page for example on a mobile device.

For backward purposes SharePoint Foundation still supports the “/m” variant of the previous version. But to allow this you will need to activate a specific feature called “MobileRedirection”. You will need to use PowerShell to enable this features with the following example call:

Enable-SPFeature –identity “MobileRedirection” –URL http://www.contoso.com

Requests from a mobile device are handled in two ways, namely request via “BeginRequest” and home page redirection.

Request via BeginRequest

If the requested URL contains the website URL without a page specified or with a page specified except for the “default.aspx”, it is automatically redirected to a version of the page that is optimized for viewing on a mobile device. This way of redirecting can not be altered in any way because it is implemented by the “SPRequestModule” class in the “BeginRequest” event of the HTTP request lifecycle. This class is sealed and cannot be altered or replaced.

Home Page Redirection

If the requested URL contains the “default.aspx” explicitly defined or the parameter “?Mobile=1” or “/m”  is specified, a special way of redirection which is called “Home Page Redirection” takes place which can be modified by developers.

Mobile devices are in this case always redirected to the “default.aspx” file in the {SharePoint Root}\TEMPLATE\LAYOUTS\MOBILE folder. This file does nothing more then redirecting again to the actual page based on the current site definition.

 So how does it work?

 Inside the “default.aspx” file a control requests the runtime to look for a template with the name “MobileHomePageRedirect” and redirect to it.

<SPMobile:SPMobileForm RunAt=”Server” PageType=”HomePage”>   <SPMobile:SPMobileComponent Runat=”Server”    TemplateName=”MobileHomePageRedirect” /></SPMobile:SPMobileForm>

Figure 2 Subset of the default.aspx file

 The runtime will loop through all the user controls found in the folder {SharePoint Root}\TEMPLATE\CONTROLTEMPLATES and stops when it finds a control based on the RenderingTemplate class with this name.

<SharePoint:RenderingTemplate RunAt=”Server”       id=”MobileHomePageRedirect“>  <Template>    <SPMobile:SPMobileWebUrlRedirect RunAt=”Server” />  </Template></SharePoint:RenderingTemplate>

Figure 3 Subset of the MobileDefaultTemplates.ascx file

The found control contains a template with an “SPMobileWebUrlRedirect” object. This object uses a pattern to construct the name of another RenderingTemplate control. The pattern is as follow:

Mobile_{SiteTypeID}_HomePage_Redirect

 The {SiteTypeID} is replaced by the name of an existing site definition or the ID number of a custom site definition. Existing site definitions which can be used are STS, SGS, BLOG.

 Again the runtime loops through all the user controls found in the folder {SharePoint Root}\TEMPLATE\CONTROLTEMPLATES. If the site definition name is BLOG it will find the RenderingTemplate with the name Mobile_BLOG_HomePage_Redirect. If it is not found the default will be used called Mobile_Default_HomePage_Redirect.

<SharePoint:RenderingTemplate RunAt=”Server”       id=”Mobile_Default_HomePage_Redirect“>  <Template>    <SPMobile:SPMobileHomePageRedirection RunAt=”Server” />  </Template></SharePoint:RenderingTemplate> <SharePoint:RenderingTemplate RunAt=”Server”       id=”Mobile_BLOG_HomePage_Redirect“>    <Template>     <SPMobile:SPMobileHomePageRedirection RunAt=”Server”         PageFileName=”bloghome.aspx” />    </Template> </SharePoint:RenderingTemplate>

Figure 4 Subset of the MobileDefaultTemplates.ascx file.

 In this case a redirect takes place to the file “bloghome.aspx” which is found in the {SharePoint Root}\TEMPLATE\LAYOUTS\MOBILE folder. If the site definition name was for example STS, the RenderingTemplate with the name Mobile_Default_HomePage_Redirect would be used.

 Inside the mobile pages you will find the <DeviceSpecific> en <Choice> elements used to support different kind of device specific rendering of the content. There are a lot of predefined possible choices, and in some case particular device specific choices. These choices are defined in a default Visual Studio mobile configuration file. You can extend filters with yourr own device filters inside your web.config in the same manner.

<system.web>  <deviceFilters>    <filter       compare=”capabilityName”       argument=”argument” />    <filter       type=”className”       method=”methodName” />  </deviceFilters> </system.web>

Figure 5 Example of a device filter definition in the web.config.

 The default choice must always be at the end with a <Choice> element without any filter specified. Each <Choice> element contains templates like “HeaderTemplate” and “FooterTemplate”. These templates correspond to the specific locations on the screen. Presumly the “HeaderTemplate” corresponds to the header of the screen. Inside the templates content is generated by controls defined in the namespace called Microsoft.SharePoint.MobileControls. In some cases the content of a <Choice> element references to a RenderingTemplate again.

Custom redirection

The RenderingTemplates which are out-of-the-box SharePoint are defined in “MobileDefaultTemplates.ascx” and “GbwMobileDefaultTemplates.ascx”. Take a look at this files to understand more about the different templates available. You are not allowed to change theses files because it is not supported by Microsoft and can break mobile features in SharePoint 2010.

To create your own redirection you will have to create your own custom user control in this folder. You are allowed to create as many custom user controls as possible as long as they are not stored in subfolders. The runtime will only loop through the folder itself and not through subfolders.

It is possible to have a template in your custom user control with an already existing name like Mobile_Default_HomePage_Redirect. RenderingTemplates that are part of SharePoint are always loaded first. RenderingTemplates in your custom user controls will overrule these standard templates. If multiple custom user controls are defined, templates are loaded based on the alphabetically order of the custom user controls names. Keep in mind that other mobile solutions can depend on these standard templates and will break.

<SharePoint:RenderingTemplate RunAt=”Server”       ID=”Mobile_STS_HomePage_Redirect“>   <Template>     <SPMobile:SPMobileHomePageRedirection RunAt=”Server”          PageFileName=”stshome.aspx” />   </Template></SharePoint:RenderingTemplate>

Figure 6 Example of a custom user control contents.

Above you see an example of the RenderingTemplate for the site definition with the name STS.

My advice is always to create a custom site definition and to define your templates and mobile pages based on the ID of the site definition. It is actually very easy to create a mobile solution for SharePoint 2010. Below the steps to execute:

1. Create an empty SharePoint 2010 project
2. Add a SharePoint Mapped Folder to “TEMPLATE\LAYOUTS\MOBILE” and to “TEMPLATE\CONTROLTEMPLATES”
3. Create one or more mobile applications in the MOBILE folder. Do not create a mobile page based on an application page, but instead copy an existing mobile page.
4. Create a custom user control for the RenderingTemplates. Do not create a user control with Visual Studio controls, but create an ascx file and copy the Register parts from the existing “MobileDefaultTemplates.ascx” file.
5. Create a custom site definition with Visual Studio
6. Use the ID of the custom site definition in the names of your RenderingTemplates.
7. Build en deploy the solution.
8. Test your mobile solution using a normal browser using the “/?Mobile=1” parameter or by using a mobile device or emulator.

Pages and Lists

When the redirection takes place, the browser on the mobile device is automatically redirected to a version of the page that is optimized for viewing on mobile devices.

The view will contain navigation links to all the content of the site and to specific pages like the “list of lists” page. This page contains a overview of available lists in the site. But also the list view pages, custom site pages as the Web Part pages and wiki-enabled pages.

Finally there are mobile versions available for the forms adding, deleting, editing and displayingitems of list items in a list.

A list can only be viewed on a mobile device when one of the SharePoint list views is marked as a mobile list view. If you look a the schema.xml file for a certain list (check for example the one for “contactslist” found in the feature folder called “contactslist”) you will see that is has some View elements defined in it. You will need to specificy the attribute “MobileView” and “MobileDefaultView” on the <View> element.

<View BaseViewID=”1″   WebPartZoneID=”Main”   DisplayName=”$Resources:core,All_Contacts;”   DefaultView=”TRUE”   MobileView=”True”   MobileDefaultView=”True”   SetupPath=”pages\viewpage.aspx”   ImageUrl=”/_layouts/images/contacts.png”   Url=”AllItems.aspx”>

Figure 7 Example of a view in the schema.xml file of a list definition

Each mobile view has a simple view version and a detailed view version which is determined by the fields which are mobile supported. The simple view version only shows a single field from each item. This is by default the first field (in most cases the Title field) which is mobile supported.  This field is rendered for a mobile browser. The detailed view will show all the fields. Those fields are rendered as for a computer browser.

Limits

The amount of content which is shown on the screen is actually limited. Think about the number lists shown in the “list of lists” page, the number of items of a list shown in the list view page, the number of options available in a dropdown, the text length of a field and many more.

The reason for these limits are obviously. The amount of data transferred to the mobile device must be kept as low in bytes as possible.

Controls like dropdowns and texts uses an ellipses to indicate that the content is cut off. 

<appSettings>        …       <add key=”mobile_webtitlelimit” value=”1024″ />       <add key=”mobile_listtitlelimit” value=”1024″ />       <add key=”mobile_viewnumberlimit” value=”20″ />        <add key=”mobile_viewtitlelimit” value=”1024″  />         …     </appSettings>

Figure 8 Subset of the limits defined in the web.config of the mobile folder

The limitations are defined in a “web.config” file which is found in the folder {SharePoint Root}\TEMPLATE\LAYOUTS\MOBILE. There are over 30 different limites which you can set. You are allowed to change this file but keep the following in mind that changes will reflect all mobile appliances and you will need to change this file on each of the web servers in your farm.

It is also possible to override the limites for a specific site by using the property bag of the SPWeb object of that site.

SPPropertyBag properties =    SPContext.Current.Site.AllWebs[“Contoso”];properties[“mobile_viewnumberlimit”] = “40”;properties.Update();

Figure 9 Code example for overriding the limit using a property bag

Web Parts

Web Parts on a SharePoint page are made accesible to mobile devices through a so called mobile adapter. As you will notice when you access a SharePoint 2010 website through a mobile device, some of the default Web Parts like de Image Web Part already have a mobile adapter defined. The content of the Web Part is rendered specifically for that mobile device.

If you have your own custom Web Parts and need them to be available on a mobile device, you will need to write your own mobile adapter class. The name of the mobile adapter is based on the following pattern:

{Web Part class name}MobileAdapter

Lets say you have a Web Part called “WorkStatusWebPart”. The name of the mobile adapter class will be “WorkStatusWebPartMobileAdapter”. This class is inherited from the “WebPartMobileAdapter” class.

You will have the ability to override two members to influence what controls are shown. The first method is used for rendering a summary view and is called “CreateControlsForSummaryView”. The second method is used for rendering a detailed view and is called “CreateControlsForDetailedView”.

However if you require logic which is only available in the actual Web Part for which you are writing a mobile adapter, you have the ability to create a new version of the “Control” property which returns the Web Part which is being adapted. Because this property is not virtual, you will need to use the “new” cast in the property statement.

protected new WorkStatusWebPart Control{    get { return base.Control as WorkStatusWebPart; } }

Figure 10 Code example for overriding the Control property

You will also need to define the Web Part page where the Web Part resides if it does not yet exist. Don’t use the “WebPartMobilePage” class for this. This is used by the runtime to create the mobile pages during runtime of mobile device requests of Web Part pages.

To make the mobile adapter available in your solution, you will need to specify it in the “compat.browser” file. This file is found at the following location:

 \\inetpub\wwwroot\wss\VirtualDirectories\{Port Number}\App_Browsers\

 The {Port Number} is the number of the port of your web application. Find the <browser> element which has the attribute “refID “ set to “default”. It will be somewhere at the top of the file.

<browser refID=”default”>   <controlAdapters>       …       <adapter            controlType=”MySolution.WorkStatusWebPart,                                 MySolution, Version=1.0.0.0,                                 Culture=neutral,                                 PublicKeyToken=mysolutionpublickeytoken”          adapterType=”MySolution.WorkStatusWebPartMobileAdapter,                               MySolution,                               Version=1.0.0.0,                              Culture=neutral,                             PublicKeyToken= mysolutionpublickeytoken” />    </controlAdapters> </browser>

Figure 11 Example of adding a new adapter definition in the compat.browser file

Use a feature receiver to add this change to the “compat.browser” file on each server in your web farm. Do not overwrite the “compat.browser” file itself.

Conclusion

While SharePoint 2010 offers right out-of-the-box the solution for accessing SharePoint website through mobile devices, it also offers you the ability to customize this to fit your needs. By using the default mobile pages already available for viewing lists and its content, you can also create your own mobile pages for viewing content en Web Parts. The functionality for mobile device access in SharePoint 2010 has some rich features and powerfull API which allows you to create quickly your own mobile web applications or make existing business web applications via mobile device available.

Challenge

One of the biggest problems using content management in a non-publishing site of SharePoint is de way how images are inserted. This is especially a problem when editing a Wiki page in the Wiki template or a blogpost inside the Blog template. It gets even worse when using such templates in a SharePoint website which has publishing enabled. Those rich text editors have a cool asset picker for the images while your Wiki or Blog template based sites still request to fill in an Url by yourself.
 

It is a real problem and mostly a no-go explaining your customers that they will have to upload one or more images to an image library and then finding out the correct Url, copy its hyperlink and inserting it into the rich text editor “Insert image” dialog.

A solution for this problem could be getting a third-party vendor’s product to replace the existing rich text editor for a new fancy one. But in most cases you get more functionality you actuallly need or want to give to your users and licenses become expensive when your farm exist of multiple servers.

So would it be possible to replace it by something you made yourself? Actually… Yes!! That is possible. And it is even not that difficult without changing standard SharePoint files (a bad practice) or even changing to way how the image is inserted.

How does it work?

Changing the “Insert Image” functionality is not something you do through Xml in this case. Using Xml is only the correct way when you are talking about a publishing site. By using Fiddler and the Web Developer of Internet Explorer I found out how SharePoint actually shows the popup requesting the Url and inserts the image into the field.

Lets have a look at the EditPost.aspx file of the Blog template. If you create a blog based on the Blog template it uses the EditPost.aspx file to edit the blogpost. When using the Web Developer tool you will notice that it loads the FORM.JS file from the folder {12 Hives}\TEMPLATE\LAYOUTS\{LCID}.

This JavaScript file has an enormous amount of functions which are addressed to build the rich text editor and to handle the diversity of functions. For the “Insert image” button two functions are important:

• RTE_InsertImage(strBaseElementID)
• RTE_AdvancedModalDialog(strBaseElementID, strDialogName, width, height, dialogArg);

The important parameter is “strBaseElementID”. This is the id of the <textarea> element in the page used for the field. The RTE_InsertImage calles the RTE_AdvancedModalDialog to show the RteDialog.aspx dialog found at {12 Hives}\Template\LAYOUTS.  After the “OK” button is pressed inside the dialog the function RTE_InsertImage injects a piece of HTML based on the <IMG> element  at the current location inside <textarea> .

The solution

In the following example we have extended the rich text editor of the Blog template. The first step we need to do is making sure that we extend the JavaScript called by the button. But we do not want to change the existing FORM.JS file. To accomplish this we need to “override” the functions defined in the FORM.JS using a new separate JavaScript file. The fun thing about JavaScript is that when your overrides are loaded after the initial functions, they replace the initial functions.

Custom RTEAdvancedDialog.js

So first we need to create our own JavaScript file called RteAdvancedDialog.js.  We place the file in the following location {12 Hives}\Template\LAYOUTS\AdvancedDialog. The contents of the file is as follow:

var g_RTE_Advanced_Dialog_Width = “400″;
var g_RTE_Advanced_Dialog_Height = “125″;

function RTE_InsertImage(strBaseElementID) {
    RTE_SaveSelection(strBaseElementID);
    var opts = RTE_AdvancedModalDialog(strBaseElementID, ‘InsertImage’, g_RTE_Advanced_Dialog_Width, g_RTE_Advanced_Dialog_Height, null);

 if (opts != null) {
        var href = STSHtmlEncode(opts[1]);
        var altText = STSHtmlEncode(opts[0]);
        var fAllowRelativeLinks = false;
        var variables = RTE_GetEditorInstanceVariables(strBaseElementID);

        if (variables != null && variables.aSettings != null) {

            fAllowRelativeLinks = variables.aSettings.fAllowRelativeLinks;
        }

        if (IsSafeHrefAlert(href, fAllowRelativeLinks)) {

            var imgHtml = ‘<IMG SRC=”‘ + href + ‘” ALT=”‘ + altText + ‘”>’;
            RTE_GetSelection(strBaseElementID).pasteHTML(imgHtml);
        }

        if (RTE_UseDynamicHeightSizing(strBaseElementID)) {

            RTE_DocEditor_AdjustHeight(strBaseElementID);
        }
    }
}

function RTE_AdvancedModalDialog(strBaseElementID,strDialogName, width, height, dialogArg) {
    var variables = RTE_GetEditorInstanceVariables(strBaseElementID);

    return showModalDialog(variables.aSettings.urlWebRoot + “/_layouts/AdvancedDialog/RteAdvancedDialog.aspx?Dialog=” + strDialogName + “&LCID=” + RTE_GetWebLocale(strBaseElementID), dialogArg, “resizable: yes; status: no; help: no; ” + “center: yes; dialogWidth:” + width + “px; ” + “dialogHeight:” + height + “px;”);
}

We override both functions RTE_InsertImage and RTE_ModalDialog  by copying them into our own JavaScript file. Secondly we rename the function RTE_ModalDialog  to RTE_AdvancedModalDialog. The third step is to change the call from RTE_InsertImage to the function RTE_ModalDialog to RTE_AdvancedModalDialog.  And as last step we need to call a different aspx file for the dialog.

Custom RteAdvancedDialog.aspx

Create a copy from the RteDialog.aspx , rename it to RteAdvancedDialog.aspx and move it to the location {12 Hives}\Template\LAYOUTS\AdvancedDialog. Add the following Register statement at the top of the file.

<%@ Register Tagprefix=”CMS” Namespace=”Microsoft.SharePoint.Publishing.WebControls” Assembly=”Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %>

Replace the second <input> element in the table inside the body with the following code:

<td><CMS:AssetUrlSelector runat=”server” /></td>

Now reassign the arr[1] value inside the script for the onclick event of the OKButton to the next value:

arr[1] = document.getElementById(“ImageSelector_AssetUrlInput”).value;

Remove the type=”submit” property from the <button> element of the OKButton like this:

<button id=”OKButton” class=”ms-ButtonHeightWidth”  type=”submit” >

Finally add a <form> element around the HTML inside the body like this:

<body …>
    <form runat=”server”>
    …
    </form>
</body>

Changing the pages of the blog

To get it to work we need to create our own custom template based on the Blog template by copying it. Inside the site definition  {Blog Template Name}\Lists\Posts you will find the EditPost.aspx and the NewPost.aspx files for changing and adding blogposts.

Add the JavaScript to the pages at the moment the FORM.JS file is already loaded. This is done by adding them inside the content placeholder called “PlaceHolderAdditionalPageHead”. Add the following code to the files:

<asp:Content ContentPlaceHolderID=”PlaceHolderAdditionalPageHead” runat=”server”>
    <script src=”/_layouts/Rabo/RteAdvancedDialog.js”></script>
</asp:Content>

Now run your SharePoint site and open the blog and try to add a new blogpost or edit an existing blogpost. As soon as you select the “Insert Image” button the new dialog appears:

Instead of having a textbox to fill in the Url, you get a nice “Browse…” button behind it. Clicking on that button we popup the asset selector dialog.

This dialog will allow you to upload new images and select an image from one of the image libraries. When after an image selection the “OK” button is clicked the Url is copied inside the textbox.

You are still able to change the Url by hand but thanks to the new dialog you have the ability to select one of the images. By pressing on the “OK” button the image is inserted into the blogpost.

Because we do exactly it as SharePoint did everything will work the same. Keep in mind that you need to have the Microsoft.SharePoint.Publishing.dll installed. But if you are working with WSS 3.0 you can create your own cool custom code to select an image from one of the libraries by replacin the AssetUrlSelector control we were using.

Conclusion

 By adding your own custom JavaScript and dialog you are able to create a nifty cool new Advanced “Insert Image” dialog which allows you to upload and select images from image libraries. Imagine what other stuff is possible by just overloading the RTE functions inside the FORM.JS file. Creating new buttons with new functionality or remove existing buttons. Everything is possible.

The example code can be downloaded here.

When you create an internet web application using SharePoint 2010 you are probably using the Publishing Portal site definition or a custom site definition / site template based on the Publishing Portal.

And if you are just like me, setting up your SharePoint environment as clean as possible, with the minimal required services activated you will run into the following problem.

When you have created a publishing page which has the approval mechanism turned on, and you publish it by clicking on the “Publish” button at the ribbon or the right contextual menu in the pages list the following error is generated:

“the form cannot be rendered. This may be due to a misconfiguration of the Microsoft SharePoint Server State Service. For more information, contact your server administrator.”

This error is caused by the workflow which is in desperate need of the state service. And as you can guess, that state service is not running. The state service does not appear under the “manage services on server” and “manage service applications” in Central Administration. There are two ways to activate the state service:

using PowerShell cmdlets

By using PowerShel cmdlets you are able to start the state service on for your web application.

$stateName = “State Service”
$stateDBName = “StateServiceDB”
$stateDB = New-SPStateServiceDatabase -Name $stateDBName
$state = New-SPStateServiceApplication -Name $stateName -Database $stateDB

New-SPStateServiceApplicationProxy -Name “$stateName Proxy” -ServiceApplication $state -DefaultProxyGroup

using the Configuration Wizard

The second way is using the Configuration Wizard. Yes, i know, that “damn” thing you never want to run after an installation because it activates all the services. But…. It is possible to deselect all the services except for the state service. Also already installed services will be grayed out.

The disadvantage of this is that you do not have any control over the database name and the service application name.

Solved

If you now have a look at the Service Applications in Central Administration you will notice that the state service is running and attached to the web application. so you now of to go and try again to publish the page.

Instead of the nasty error you will get the workflow start screen.

Since the last two tweeks I have been experiencing problems updating the navigation of a new SharePoint 2010 publishing website. As you all know it is possible to change the navigation on site level in SharePoint. Adding, deleting and hiding of headings and links is easily done through the navigation page (/_layouts/AreaNavigationSettings.aspx). It is even possible to manually override and insert the navigation complete from scratch.

But for some unknown reason any change made on this page and clicking the OK button were discarded. No error was displayed and returning to the navigation page showed us no changes.

After some research (checking your own custom stuff at first of course) I had to go to one of our customers for some troubleshooting around SharePoint issues regarding a MOSS 2007 intranet environment (using the publishing capabilities). And to my surprise they reported the same problem on some of their sites.

So we started to investigate, read a lot of articles, forums and blogs. Not any answer was to be found except some remark we found about the <NavBars> element inside the ONET.XML definition file for a site definition.

For my project I didn’t specify that element due to the standard (clean) template I used inside VS2010. Looking at the site definitions used by this customer (made by another external party) it seems that exactly those site definitions used by the failing sites seems to have also not the <NavBars> element defined. We changed on of the templates and created a new site. And yes… it worked!

It seems that when that <NavBar> element is not specificied, an entry is missing causing the SPWeb.Navigation.TopNavigationBar to be null. Resulting in the fact that when the navigation page tries to store your changes it will fail.

To fix the problem you will need to specify a <NavBar> element for the Global Navigation based on the hard-coded id=”1002”.  The following is necessary for publishing sites in your site defintion to have the global navigation work properly.

<NavBars>
    <NavBar Name=”SharePoint Top Navbar” ID=”1002″ />
</NavBars>

The problem with this fix is that you will need to recreate the site. Resetting to the site definition will not take over changes made in the ONET.XML. This will cause to lose all your content and is often not an option.

I have been looking for a solution to create a new SPWeb.Navigation.TopNavigationBar programmatically. But no solution was found by me or by somebody else. And even finding a solution will cause to create a new id in stead of the id=”1002”. The problem with that is that the global navigation looks hard-coded for the id=”1002.

There is another (not supported by Microsoft) solution to fix this problem/bug for existing publishing sites. It incorporates changes made to the content database of SharePoint. This is not supported by Microsoft and could eventually result into loss of support on future SharePoint issues which will need assistance of Microsoft. If you want to go this direction then read the following post: http://statto1974.wordpress.com/2008/04/09/beware-of-deleting-global-navigation-nodes-in-spwebnavigationglobalnodes/

The last method which could solve your problem depends on your current environment. If you have the ability to setup a new clean environment of the company works with an OTAP model this could solve your problem. You will need to do the following:

1) Setup a clean web application (on another machine)
2) Install the fixed site definitions on that machine
3) Start a content deployment from the current machine to that machine. It will regenerate the sites using the new fixed site definitions and fill it with content from the current.
4) Clean the current machine
5) Reinstall the fixed site definitions on the current machine
6) Start a content deployment back.

This problem (or actually SharePoint bug) is found in MOSS 2007  and SharePoint 2010 publishing solutions. Hopefully will Microsoft solve this and create a patch (if they haven’t done already).

If anyone has suggestions or other solutions do not hesitate to contact me. I will then update this post accordingly.