“Starter Master Pages for SharePoint are a clean, commented starting point for creating your own SharePoint 2010 branding”

— Thanks to Randy Drisgrill for such an informative contribution.

Inspired from Starter.master, evolved StarterCorev4.css which gives you detailed description about the Corev4.css file that comes within SharePoint 14 hive.

Corev4.css – Corev4.css is the core style sheet that is shipped within the 14 hive (%Program Files%\Common Files\Microsoft Shared\Web Server Extensions\14) of SharePoint, which is referred by default in all SharPoint OOTB( Out of the Box) controls.

StarterCorev4.css file when attached to your Master page, will enhance your Master page css reading capabilities and is NOT intended to override any class files for SharePoint for development. Clicking on any of the css class links in the Master page will lead you to the class definition in the css file. Follow the below steps to include StarterCorev4.css

1. Open and Edit your custom master page in SharePoint Designer.

2. Download StarterCorev4.css from CodePlex – http://startercorev4.codeplex.com

3. Either upload the css file into your Site Style library or keep it in a local file location for reference.

3. Attach the downloaded StarterCorev4.css into the head section of your master page as shown below.

4. Notice that a tag has been added to the head section with the path of the css file.

5. Now Clicking on any of the css class defined in your master page, which usually refers to Corev4.css would redirect to the class files in StarterCorev4.css (Use Ctrl + Click for redirection). For eg:- I have clicked on the id “s4-ribboncont” defined for the ribbon, which leads me to an explanation as below.

After all your development activities and css changes for the master page and before moving the custom master page for deployment or testing, you should remove the reference link added on the head section of your master page for StarterCorev4.css. This would revert the usage of StarterCorev4.css file to the default corev4.css file in the 14 hive.

NOTE : You should never modify your Corev4.css file in the 14 hive which comes by default with SharePoint. Follow the best practices in over riding the default SharePoint css references.

Watch out the codeplex page for updates and improvements to the StarterCorev4.css project. Your feedback and comments are much appreciated.

Here is the online demo for the style switcher which looks pretty neat – http://demos.net.tutsplus.com/03_jQueryStyleSwitcher/demo/

Click on Day and Night tabs to switch over the effects. You can notice that the jquery fading effect makes it a perfect switching.

Now, why don’t we have the same in SharePoint for our Master Pages. This would be an excellent add-on for sites that need Accessibility features, basically style sheet switching for people who are color blind. You will be able to understand it better visiting this BBC site – http://www.bbc.co.uk/accessibility/index.shtml .

On the top right hand side of the page, you can see icons where it mentions diferent colours possible for the site dynamically.

Click on the icons and you will notice what I meant. These are one of the accessibility feature that I was talking about

Ok, Now how about adding all these into a SharePoint master page, so that you can switch your styles dynamically on a button click.

1. First of all, you need to upload the jquery.js and the styleswitcher.jquery.js file into the SharePoint Style library. Download all the files at the bottom of the post. Also add the loading.gif file into  the path - /Style Library/Images/ inside your root site.

2. Add the js file references in the head section of your master page.

<script src="/Style Library/en-us/js/jquery.js" type="text/javascript"></script>
<script src="/Style Library/en-us/js/styleswitcher.jquery.js" type="text/javascript"></script>

3. Add the div tags in your master page. As a demo, you can add the div inside the PlaceHolderPageDescription, just below the s4-pagedescription css class. This will be added in your master page just below your Site title. Make sure that the div id name is style-switcher always, or you will have to change the final call in Step 5.

The css classes whiteandblue.css and blackandyellow.css should be added in the path - /Style Library/en-us/Core Styles/ in your SharePoint site. These styles are the one that will be switched finally.

<div id="style-switcher">
 <h4>Choose your style:</h4>
 <ul>
 <li id="day"><a href="" name="whiteandblue.css">White and Blue</a></li>
 <li id="night"><a href="" name="blackandyellow.css">Black and Yellow</a></li>
 </ul>
 </div>

4.  Now its the main script that is called within the styleswitcher.js file. The function onClickStyleChange below adds the css link for the master page. This is the place where the switching takes place.

<script type="text/javascript">
 function onClickStyleChange(strvalue)
 {
 var headID = document.getElementsByTagName("head")[0];
 var cssNode = document.createElement('link');
 cssNode.type = 'text/css';
 cssNode.rel = 'stylesheet';
 cssNode.href = '/Style Library/en-us/Core Styles/' + strvalue;
 cssNode.media = 'screen';
 headID.appendChild(cssNode);
 }
 </script>

5.  Add the below script in the master page which ultimately calls the function inside the jquery. This gives the fade in and fade out effect for our master page which is really cool.

<script type="text/javascript">
 $('#style-switcher a').styleSwitcher(); // Calling the plugin...
 </script>

6. Save, checkin and publish your master page. You are good to go.

For convenience I have zipped all the necessary js files and loading.gif file over here. Special thanks to the person who initially created this in Php.

Each code sample consists of a standalone project created in Microsoft Visual Studio 2010 and demonstrates a distinct feature or feature set. Each sample includes comments describing the sample and the expected results. Each sample also contains comments that explain how to set up your environment so that the sample code runs, where necessary.
Read more and download the code samples from here.

So , when we need to create a SharePoint Search content source, using Powershell, we use the following commands-

$searchapp = Get-SPEnterpriseSearchServiceApplication "Search Service Application"
New-SPEnterpriseSearchCrawlContentSource -SearchApplication $searchapp -Type SharePoint -name ContentSourceWithTypeSharePoint -StartAddresses http://localhost:6001/

This would create a content source

Clicking on the “ContentSourceWithTypeSharePoint” would open up the content source which we have created using the default settings as below:

This was a simple scenario. Now consider creating the content source of type “Web” which would be

$searchapp = Get-SPEnterpriseSearchServiceApplication "Search Service Application"
New-SPEnterpriseSearchCrawlContentSource -SearchApplication $searchapp -Type Web -name ContentSourceWithTypeWeb -StartAddresses http://localhost:5000/

And this would create a content source with type “Web” as below

Here, we can see that the crawl behavior is set to custom and there would be no direct parameters in Powershell to change these options.

So, I recently had a research into this and found out that adding the parameters, MaxPageEnumerationDepth and MaxSiteEnumerationDepth , could bring you these options.

ie, To bring the crawl option to the second option -”Only crawl the first page of each start address”, the Powershell script would be 

$searchapp = Get-SPEnterpriseSearchServiceApplication "Search Service Application"
New-SPEnterpriseSearchCrawlContentSource -SearchApplication $searchapp -Type Web -name ContentSourceWithTypeWeb -StartAddresses http://localhost:5000/ -MaxPageEnumerationDepth 0 -MaxSiteEnumerationDepth 0

This actually means that the Page depth and the Site depth that you expect is zero, which defaultly means that you would be crawling only the first page of your start address and hence this option is selected.

and to bring the crawl option to the first option -”Only crawl within the server of each start address“, the Powershell script would be 

$searchapp = Get-SPEnterpriseSearchServiceApplication "Search Service Application"
New-SPEnterpriseSearchCrawlContentSource -SearchApplication $searchapp -Type Web -name ContentSourceWithTypeWeb -StartAddresses http://localhost:5000/ -MaxSiteEnumerationDepth 0

This actually means that the Site depth that you expect is zero and it can go any pages deep if it is within the server, which definitely means you would be crawling only within the server of the start address.

This post was inspired from a question asked in SharePoint.Stackexchange.com - http://sharepoint.stackexchange.com/questions/27901/how-to-create-a-content-source-of-type-web-with-the-option-only-crawl-within/27908#27908

As you may know, changing core SharePoint files is unsupported and can lead to problems when patching.

The best way to clean up modified SharePoint installations is to pull out the customizations and move them into new files as part of a solution package (WSP file). That makes it easy to re-deploy customizations and ensures your environment will stay clean.

Read more here and download CSSCompare here.

Check out more about the project in Codeplex Project Home Page.

1. Go to this site and download Snowstorm.js file and upload it to some Document Library

2. Open your SharePoint page and add a Content Editor WebPart.

3. Edit the HTML Source for the content Editor WebPart

4. Add the following code and set the Chrome Type for the Web Part as none

<script src="{Path}/snowstorm-min.js"></script>

5. Save and Exit Edit mode and that’s it!

It’s always a good idea to have a “Stop Snowing” link for those who find this annoying. Simply edit the JavaScript code in the Content Editor WebPart and add the following code.

<script type="text/javascript" src="/Docs/snowstorm-min.js"></script>
<a onClick="javascript:snowStorm.stop();" href="#">Stop Snowing</a>

There are many other customization available. Check this page for more options.

Error Scenarios:

These are the possible errors that can occur:

1. SharePoint Designer popping up correlation ID with detailed error something like this

Error while executing web part: System.StackOverflowException: Operation caused a stack overflow.  

2. Error while saving site as template

System.InvalidOperationException: Error generating solution files in temporary directory.
at Microsoft.SharePoint.SPSolutionExporter.ExportWebAsSolution()

This issue might appear for just one site or subsite in the whole site collection. Basically it could be assumed that this occurs with a particular site that has a DataForm web part or any web part that inherits from this DataForm web part. Removing the DataForm webparts from the site or page might bring things to normal.

Why errors all of a sudden?

Recently, the following Security Update KB 2494001, http://support.microsoft.com/kb/2494001 and the June 2011 cumulative update for SharePoint 2010 has updated the timeout for the Data Form web part and the web parts that inherit from the Data Form web part.

Basically farms that have recently been upgraded with cumulative updates might find these issues.

Possible Solution

The only workaround for the web parts timing out is to apply one of the solutions listed in KB 2639184, released by Microsoft.

http://support.microsoft.com/kb/2639184

There are 3 solutions provided in this article and I believe the 3rd solution would be an ideal solution for large Data Form XSLT transformations. Here are the details -

1.) Sub class the DataForm Web Part. Override the following methods. Then Deploy the assembly.
Example:

 public class customDFWP : DataFormWebPart
    {
        public override bool IsGhosted
        {
            get
            {
                return true;
            }
        }
        public override bool CanHaveServerControls
        {
            get
            {
                return true;
            }
        }
    }

2.) Add a safe control entry to the web.config
Example:

<SafeControl Assembly="customDFWP, Version=1.0.0.0, Culture=neutral, PublicKeyToken=963f869a440db619" Namespace="customDFWP" TypeName="*" Safe="True" AllowRemoteDesigner="True" SafeAgainstScript="False"/>

3.) Add the following to the <tagMapping> element of the web.config
Example:

<add tagType="Microsoft.SharePoint.WebPartPages.DataFormWebPart, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" mappedTagType="customDFWP.customDFWP, customDFWP, Version=1.0.0.0, Culture=neutral, PublicKeyToken=963f869a440db619" />

4.) Register the assembly on the form page.
Example: 

<%@ Register tagprefix="customDFWP" namespace="customDFWP" assembly="customDFWP, Version=1.0.0.0, Culture=neutral, PublicKeyToken=963f869a440db619">

5.) On the form page find <WebPartPages:DataFormWebPart > and replace it with the new custom tag.
Example:

<customDFWP:customDFWP>

Again, if nothing goes right remove the Data Form web part and try to accommodate the same logic differently, may be using a custom web part with css.

You can also follow us in Twitter @allaboutmoss.

There are organizations were numerous workflows are created that are developed using, either out of the box features or SharePoint Designer or Visual Studio developed or even third party tools like Nintex or K2.

What is a workflow ? - A workflow is comprised of a sequence of events such as workflow initiation, task creation, and task completion. When you add a workflow, you specify a task list and history list that workflow instances of that workflow association will use to track the events for the workflow. The task list contains the items that users interact with and enter data into while interacting with the workflow. The workflow history contains key information about each event including date, status, participant, and description.

Workflow history list – This is a hidden list in all SharePoint sites and this could be accessed by appending /Lists/Workflow History/ to the address of the SharePoint site. Many of the organisations would like to keep these lists as long as possible to maintain as a backup for the workflows created. But what about the bulk amount of database space that it occupies?

Workflow Auto Cleanup timer job – The Workflow history list is deleted by default using the Workflow Auto Cleanup job. This job should delete all workflow instances and related task entries that exist 60 days after the workflow is completed or cancelled. Thank God!!! All those unwanted entries could be deleted automatically by running the timer job. If you wish to keep the workflow history list, it could be done by disabling the timer job. Go to Central Admin -> Operations Tab (SharePoint 2007) -> Timer job definitions -> Find the timer job, click open and just disable.

There are also patches available from Microsoft technical support to increase the number of days from 60 to a larger number, thus increasing the amount of time that the workflow histories could be retained - http://blogs.msdn.com/b/nishand/archive/2007/09/10/changing-the-spworkflowassociation-autocleanupdays-property.aspx

Workflow history list never gets deleted

Wonder why the database space is still getting eaten up even though the workflow history list are scheduled for auto cleanup. Recently there was an msdn post which described that even though the timer job is enabled, the Workflow history lists are infact not getting deleted. As the post explains, Workflow history items themselves are not deleted, but the entry point to view them on the status page for a particular instance will no longer be available.

The post has a code sample that could be used to actually delete all the Workflow history list items. Those who would be running workflows on K2 or Nintex could also check with the vendors, how these lists are managed by them.