For a recent project we needed to create record libraries automatically through a deployment script. This was achieved using the following piece of code:

 using (SPSite site = new SPSite("http://sp/"))
{
	using (SPWeb recordsite = site.OpenWeb("/records")) //records site url
	{
		foreach (SPListTemplate templ in recordsite.ListTemplates)
		{
			if (templ.Type_Client == 1302)
			{
				SPListCollection listcol = recordsite.Lists;
				Guid nListGuid = listcol.Add(library[0], "", templ);
				SPList nList = recordsite.Lists[newListGuid];
				nList.OnQuickLaunch = true;
				nList.Update();
				break;
			}
		}	
	}
}

The list template is not available in the SPListTemplateType enumerable list but is available by iterating through the available templates and finding it by it’s ID 1302. The In Place Records Management feature (ID: da2e115b-07e4-49d9-bb2c-35e93bb9fca9) needs to be enabled in the site collection to be able to create these libraries.

 

Many people made SharePoint WCM Publishing sites and forgot to test it from a computer external to their network where the site would not be recognized in the trusted zone of Internet Explorer. This led to many sites displaying the dreaded yellow ActiveX bar for name.dll.

This can easily be fixed directly in your master page by using the following Javascript block placed right before the closing </head>  tag:

<script type="text/javascript">
function ProcessImn(){}
function ProcessImnMarkers(){}	
</script>

This will override internal javascript functions with blank functions that will prevent the loading of the presence indication dll.

SharePoint 2010 also has this same issue but also has a web application level fix that can be applied using the following steps:

  1. In central administration, click Manage Web Applications under the Application Management title
  2. Select your site’s web application in the list
  3. Click the General Settings ribbon button
  4. Scroll down and set the following option to No and save the settings.

Either method will make sure no more popup gets displayed on your site but my preference is the masterpage javascript method. This method allows you to deploy this as a feature and you would not need a manual change of the web application settings.

Thanks for visiting.

 

When the ribbon is used on a Publishing Site with anonymous access turned on, SharePoint still displays a blue bar at the top of the screen that does not blend in very well in heavily branded sites.

The ribbon can be removed from your master page using the following trick:

<!-- =====  Begin Ribbon ============================================================ -->
<SharePoint:SPSecurityTrimmedControl ID="SPRibbon" runat="server" PermissionsString="ManageWeb">
    //RIBBON SECTION (See details below)
</SharePoint:SPSecurityTrimmedControl>
<div id="s4-ribbonrow" class="s4-pr s4-ribbonrowhidetitle" style="display:none;"></div>
<!-- =====  End Ribbon and other Top Content ============================================================ -->

The ribbon section is everything contained in the already existing div and closing tag of your base masterpage (all 250 lines or so).

<div id="s4-ribbonrow" class="s4-pr s4-ribbonrowhidetitle">

The SPSecurityTrimmedControl essentially will only display for users that have required permissions to the site. In this case we used the ManageWeb property but you can use a different level to achieve the same result.

The div that is placed outside the SPSecurityTrimmedControl is there to allow SharePoint to properly calculate the scoll bar position, height and visibility.

That’s it for today. Stay tuned, there is a lot more on the way!

 
Out of the box, SharePoint 2010 has it’s browser file handling level set to strict. Strict mode adds headers that force the browser to download certain types of files. The forced download improves security for the server by disallowing the automatic execution of Web content that contributors upload.
If you try to open a file that is in the restricted list of file formats, pdf or xml for example, you get prompted to save or open the file. The browser does not handle the loading of that file using your default preferences.
In most cases there are only a few file types that you would prefer not be prompted, but you want to keep the strict browser file handling security feature of SharePoint 2010.
The workaround is to programmatically add the file types you want SharePoint 2010 to consider as safe. The code to achieve this is:
using Microsoft.SharePoint.Administration;
using Microsoft.SharePoint;

using (SPSite site = new SPSite(SPContext.Current.Site.Url.ToString()))
{
	string pdftype = "application/pdf";
	SPWebApplication webapp = site.WebApplication;
	if (!webapp.AllowedInlineDownloadedMimeTypes.Contains(pdftype))
	{
		webapp.AllowedInlineDownloadedMimeTypes.Add(pdftype);
		webapp.Update();
	}
}

Update 28/09/2011: I decided to provide a powershell script to add these mime types:

Add-PSSnapin Microsoft.SharePoint.PowerShell –ErrorAction SilentlyContinue
$webappurl = Read-Host "Enter Web Application URL"
Write-Host "Mime Type Examples:"
Write-Host "application/pdf, text/html, text/xml, application/x-shockwave-flash"
$mimetype = Read-Host "Enter a mime type:"
$webapp = Get-SPWebApplication $webappurl
If ($webapp.AllowedInlineDownloadedMimeTypes -notcontains $mimetype)
{
   Write-Host "Adding MIME Type..."
   $webapp.AllowedInlineDownloadedMimeTypes.Add($mimetype)
   $webapp.Update()
   Write-Host "Done."
} Else {
   Write-Host -ForegroundColor Green "MIME type is already added."
}
Write-Host "Press any key to continue ..."
$x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")

This powershell script can be downloaded here.

If you need a reference to other mime types to add, Wikipedia has a good list in this article.

Thanks for visiting. Hope this helps.

 

Possible Bug in SharePoint 2010

On May 16, 2011, in Bugs, SharePoint, by matdesmarais
2

Here is an issue we ran into on the last project:

  1. On a Publishing Site, edit a page and add any webpart to an HTML Content Place Holder.
  2. In the chrome title bar, click delete on that web part
  3. Switch to view HTML Source and you should see the following HTML block that remains behind on the page:
<div class="ms-rtestate-read ms-rte-wpbox" contenteditable="false"><div class="ms-rtestate-notify  ms-rtestate-read c861ffc3-62f5-44a8-925a-a66af357e09f" id="div_c861ffc3-62f5-44a8-925a-a66af357e09f" unselectable="on"></div>
<div id="vid_c861ffc3-62f5-44a8-925a-a66af357e09f" unselectable="on" style="display: none"></div></div>

This issue is very weird. There should be nothing left behind after a web part is removed. Has anyone else out there run into this issue before?

 

One of our clients wanted his entire SharePoint 2010 site to utilise MUI but the MUI setting is at the web level and not the site collection level. On a site with 800 sub webs, this can become quite anoying. We provided them a powershell script that enables the MUI globally but this was going to be run by users that had no access to run powershell on the server so the code was repackaged in a SharePoint feature that enables MUI to all sub sites on feature activation.

The code itself is really simple and can also be repurposed in a WebProvisioned event receiver that can fire at site creation.

using Microsoft.SharePoint;
using System.Linq;
using System.Globalization;
using System.Collections.Generic;

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
	try
	{
		SPSite site = properties.Feature.Parent as SPSite;
		foreach (SPWeb web in site.AllWebs)
		{
			web.IsMultilingual = true;

			// Add support for any installed language currently not supported.
			SPLanguageCollection installed = SPRegionalSettings.GlobalInstalledLanguages;
			IEnumerable supported = web.SupportedUICultures;

			foreach (SPLanguage language in installed)
			{
				CultureInfo culture = new CultureInfo(language.LCID);

				if (!supported.Contains(culture))
				{
					web.AddSupportedUICulture(culture);
				}
			}
			web.Update();

		}
	}
	catch (Exception ex) { }
}

Update 28/09/2011: I was asked to provide a powershell script and I did but then I spent some time updating it to reflect more the C# script provided above. This powershell script will add all supported cultures to all sub sites in your environment.

Add-PSSnapin Microsoft.SharePoint.PowerShell –ErrorAction SilentlyContinue
$siteurl = Read-Host "Enter Web Application URL"

$installed = [Microsoft.SharePoint.SPRegionalSettings]::GlobalInstalledLanguages
$site = get-spsite $siteurl
foreach ($web in $site.allwebs){
$web.IsMultiLingual = 'True'
$supportedCultures = $web.SupportedUICultures ;
foreach ($lang in $installed){
$cultureinfo = [System.Globalization.CultureInfo]::GetCultureInfo($lang.LCID);
$exists = $supportedCultures | Where-Object{$_.LCID -eq $lang.LCID}
if ($exists -eq $null){
$web.AddSupportedUICulture($cultureinfo)
Write-Host "Added" $cultureinfo.Name "to url" $web.Url
}
}
$web.Update()
}
Write-Host "Press any key to continue ..."
$x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")

You can download the powershell script from here. Let me know in the comments if you like this.