PowerShell – Delete field and all references

Sometimes you want to delete a site column from SharePoint and you get the nice message stating “Site columns which are included in content types cannot be deleted. Remove all references to this site column prior to deleting it.”. Really helpful that it states in which ContentTypes the field is used. It gets even worse when the column is also used in lists… You can do this via PowerShell easily:

# Add SharePoint PowerShell Snapin

if ( (Get-PSSnapin -Name Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue) -eq $null ) {
    Add-PSSnapin Microsoft.SharePoint.Powershell
}

#—————————————————————————-
# Delete Field
#—————————————————————————-
function DeleteField([string]$siteUrl, [string]$fieldName) {
    Write-Host “Start removing field:” $fieldName -ForegroundColor DarkGreen
    $site = Get-SPSite $siteUrl
    $web = $site.RootWeb

    #Delete field from all content types
    foreach($ct in $web.ContentTypes) {
        $fieldInUse = $ct.FieldLinks | Where {$_.Name -eq $fieldName }
        if($fieldInUse) {
            Write-Host “Remove field from CType:” $ct.Name -ForegroundColor DarkGreen
            $ct.FieldLinks.Delete($fieldName)
            $ct.Update()
        }
    }

    #Delete column from all lists in all sites of a site collection
    $site | Get-SPWeb -Limit all | ForEach-Object {
       #Specify list which contains the column
        $numberOfLists = $_.Lists.Count
        for($i=0; $i -lt $_.Lists.Count ; $i++) {
            $list = $_.Lists[$i]
            #Specify column to be deleted
            if($list.Fields.ContainsFieldWithStaticName($fieldName)) {
                $fieldInList = $list.Fields.GetFieldByInternalName($fieldName)

                if($fieldInList) {
                    Write-Host “Delete column from ” $list.Title ” list on:” $_.URL -ForegroundColor DarkGreen

                 #Allow column to be deleted
                 $fieldInList.AllowDeletion = $true
                 #Delete the column
                 $fieldInList.Delete()
                 #Update the list
                 $list.Update()
                }
            }
        }
    }

    # Remove the field itself
    if($web.Fields.ContainsFieldWithStaticName($fieldName)) {
        Write-Host “Remove field:” $fieldName -ForegroundColor DarkGreen
        $web.Fields.Delete($fieldName)
    }

    $web.Dispose()
    $site.Dispose()
}

#Delete the field below
DeleteField http://sharepoint “MyField”

SharePoint Connection Netherlands 2011

On 22 and 23 November 2011 the SharePoint Connections 2011 was held in Amsterdam. I gave a session on Visio Services and Visio Services Development. The presentation and the files used you can download here.

SharePoint cache settings when restyling

When restyling web applications, you have to think of the cache settings which are set to the different resource files, since you want people to see the new styles without having to clear their local cache. These files for example can be:

• Style Sheets
• Images
• Java Scripts

If we for example open a normal team site and open up Fiddler, we will see how long the files are cached (you might want to first clear your cache or use a hard refresh to force all files to download).

Figure 1: Default Team Site

Figure 2: Fiddler trace of the loading of the default Team Site

When you look at the Fiddler trace, you can see the following cache settings:

• The aspx file is not cached.
• The Java Scripts are cached for a year.
• The style sheets are cached for a year.
• The images are cached for a year.

The reason for this is that the newly created web site, the content expiration is not enabled for the web site itself, but it is enabled for the four virtual directories:

1. _controltemplates
2. _layouts
3. _vti_bin
4. _wpresources

For the virtual directories the default setting is to enable content expiration for 365 days.

Figure 3: By default the settings for the Web Site is to not use content expiration

Figure 4: The default setting for the _layouts folder is to use content expiration for 365 days

These default cache settings can be updated, but otherwise this means: You can NOT simply update your resources in the _layouts folder and expect your users to see the update immediately!

Possible solutions

To overcome the caching problems, there are multiple solutions. For example:

1. Use new filenames
2. Use new directory
3. Use a query string

Use new filenames

The first possible solution is to simply rename all the files you are changing during the restyling of SharePoint. This will allow you to bypass the client side cache. You will however need to:

1. Rename all the files you store in the _layouts folder which have changed.
2. Find and update all the filenames you refer to inside your Java Scripts, if they are stored in the _layouts folder.
3. Find and update all the filenames (f.e. images) you refer to inside your Style Sheets, if they are stored in the _layouts folder.
4. Find and update all the filenames you refer to inside your code, if they are stored in the _layouts folder.
5. Find and update all the filenames you refer to inside your master pages, if they are stored in the _layouts folder.
6. Find and update all the filenames you refer to inside your pages, if they are stored in the _layouts folder.
7. Find and update all the filenames you refer to inside your control templates, if they are stored in the _layouts folder.
8. Etc.

The downside here is you have to search for every file individually, which can be time consuming and error prone.

Use new directories

When storing your own files in the _layouts folder, a best practice is to use your own subfolders. An option would be to rename all your subfolders in the _layouts folder. That would bypass the client side cache. For this you will need to:

1. Rename all the directories you store in the _layouts folder
2. Find and update all the filenames you refer to inside your Java Scripts, if they are stored in the _layouts folder
3. Find and update all the filenames (f.e. images) you refer to inside your Style Sheets, if they are stored in the _layouts folder
4. Find and update all the filenames you refer to inside your code, if they are stored in the _layouts folder.
5. Find and update all the filenames you refer to inside your master pages, if they are stored in the _layouts folder.
6. Find and update all the filenames you refer to inside your pages, if they are stored in the _layouts folder.
7. Find and update all the filenames you refer to inside your control templates, if they are stored in the _layouts folder.
8. Etc.

This method is easier than the one above (using new file names), since you can do a find/replace on your solutions and just replace the directory name. You will however need to update the directory naming and probably the relevant documentation.

Use a query string

Another option is to use a query string after the resource files you are using. This is actually how SharePoint internally solves the issue as well:

 
Figure 5: Page source of default Team Site

Within SharePoint you can let the query string “?rev=xxxxxxxxxxxxxx” be generated automatically by using the SPUtility.MakeBrowserCacheSafeLayoutsUrl. This function will place “_layouts/” before and “?rev=[some string here]” after a given string. This however is a server side action which would in turn be triggered for every resource you use. This is a load on the system which can be avoided. Another downside of this function is that it will only work for files stored in the layouts folder on the file system. This means it will not work for the images folder. Besides that, this might work in your code files, master pages and aspx pages, but you’ll have to jump through a couple of hoops to get this working in style sheets and java scripts!

What we in turn did was placing a string like “?rev=201003221230″ after all loaded resources. The number is actually a timestamp from when we started on the change. This means you’ll have to:  

1. Find and update all the filenames you refer to inside your Java Scripts, if they are stored in the _layouts folder
2. Find and update all the filenames (f.e. images) you refer to inside your Style Sheets, if they are stored in the _layouts folder
3. Find and update all the filenames you refer to inside your code, if they are stored in the _layouts folder.
4. Find and update all the filenames you refer to inside your master pages, if they are stored in the _layouts folder.
5. Find and update all the filenames you refer to inside your pages, if they are stored in the _layouts folder.
6. Find and update all the filenames you refer to inside your control templates, if they are stored in the _layouts folder.
7. Etc.

But the benefits are:

1. With a next rebranding you can easily do a replace all on the string “?rev=201003221230″ on your solution.
2. You don’t have to keep track of which files you actually modified.
3. No additional actions on the server are needed.
4. It works for every file type.

Self Service Site Creation through code

Note: This post only looks at SPSite.SelfServiceCreateSite from the object model.

The challenge

In most cases site collections are created by administrators with farm admin permissions, but in some cases you want to provide your users the ability to create site collections. Still a lot of developers use methods like the SPSite.Add() to create the site collections, which are actually meant for administrator task only and require you to have farm level permissions. Well, being a developer that is easily solved. Just add the web application pool account to the farm administrators and you can get the necessary permissions by simply using a SPSite.SelfServiceCreateSite method. Using this method you can allow regular users to create site collections, without giving them farm level permissions. To make this work there are two settings you must take into account: SPSecurity.RunWithElevatedPrivileges. Well, that’s something we DON’T want. Normal users should never get farm level permissions, simply because they always find a way to create havoc.

The solution

The solution is actually really simple. Microsoft provides us with the

1. Enable Self-Service Site Management
   This allows the users to actually create site collections using the SPSite.SelfServiceCreateSite
   

               Figure 1: Enable Self-Service Site Management

1. Have multiple managed paths
   Make sure you have another managed path as the (root) managed path. Sites should be created by default for most of the Web Applications, but you’ll need a managed path to be able to create new site collections.

   

               Figure 2: Create multiple managed paths

The implementation

For this example I created a WebPart which allows an user to create a new site collection. Within the code of the solution you’ll also find some other nice pieces of code, for example:

• How to check if “Self-Service Site Management” is enabled
• How to check if multiple managed paths are created
• How to load the drop down list with the available managed paths (SPWebApplication.Prefixes)
• How to load the drop down list with the available web templates (SPSite.GetWebTemplates(uint))
• How to make use of SPLongOperation to show a nice progress window.

Figure 3: Example WebPart for the use of SelfServiceCreateSite

Once the information of the new site collection is entered and the user presses the Submit button, the site collection will be created. This might take a couple of seconds and during this time you don’t want to let the user click again on the submit button. The second time there might already be a site on the URL which is provided (since the user clicked on the button before), and they will get an exception. To prevent this problem, a progress screen is shown.

Figure 4: Creation of Site Collection is in progress

Once the site collection is created, the user will be redirected to the newly created site.

Figure 5: Newly generated Site Collection

The code

The following function shows the use of the SPSite.SelfServiceCreateSite. Basically it’s just calling the function with the correct variables, but there are a couple of pitfalls you should take into account

/// <summary>
/// This function will create a site collection using <see cref=”SPSite.SelfServiceCreateSite”/>
/// </summary>
/// <param name=”relativeSiteUrl”>
/// The relative url of a site. This should include a managed path since the root site
/// collection already exist. Example “sites/testsite”
/// </param>
/// <param name=”title”>The title of the new site</param>
/// <param name=”description”>The description of the new site</param>
/// <param name=”webTemplate”>The web template name</param>
/// <param name=”secondarySiteCollectionAdministratorLogin”>
/// The user login account of the secondary site collection administrator
/// </param>
/// <param name=”secondarySiteCollectionAdministratorName”>
/// The name of the secondary site collection administrator
/// </param>
/// <param name=”secondarySiteCollectionAdministratorEmail”>
/// The email address of the secondary site collection administrator
/// </param>
/// <returns>
/// The newly create <see cref=”SPSite”/> or null when an error has occured.
/// </returns>
private SPSite CreateNewSiteCollection(string relativeSiteUrl,
        string title,
        string description,
        string webTemplate,
        string secondarySiteCollectionAdministratorLogin,
        string secondarySiteCollectionAdministratorName,
        string secondarySiteCollectionAdministratorEmail)
{
    SPSite newSiteCollection = null;

    // The creation will only work if you set the primary administrator is set to the current user
    string primarySiteCollectionAdministratorLogin = SPContext.Current.Web.CurrentUser.LoginName;
    string primarySiteCollectionAdministratorName = SPContext.Current.Web.CurrentUser.Name;
    string primarySiteCollectionAdministratorEmail = SPContext.Current.Web.CurrentUser.Email;
    // Small change you want to set this variable on a different value as the root site collection
    uint localIdentifier = (uint)SPContext.Current.Web.Locale.LCID;
   
    try
    {
        // Make sure we are at the root site collection
        using (SPSite rootSite = new SPSite(GetAuthorityUrl(SPContext.Current.Web.Url)))
        {
            // If no secondary site collection administrator is provided, use null values
            // in stead of an empty string. Otherwise an Exception will be thrown.
            if (string.IsNullOrEmpty(secondarySiteCollectionAdministratorLogin))
                newSiteCollection = rootSite.SelfServiceCreateSite(
                        relativeSiteUrl,
                        title,
                        description,
                        localIdentifier,
                        webTemplate,
                        primarySiteCollectionAdministratorLogin,
                        primarySiteCollectionAdministratorName,
                        primarySiteCollectionAdministratorEmail,
                        null,
                        null,
                        null);
            else
            {
                // When a secundary site collection has been provided, add this account as a
                // secundary site collection administrator
                newSiteCollection = rootSite.SelfServiceCreateSite(
                        relativeSiteUrl,
                        title,
                        description,
                        localIdentifier,
                        webTemplate,
                        primarySiteCollectionAdministratorLogin,
                        primarySiteCollectionAdministratorName,
                        primarySiteCollectionAdministratorEmail,
                        secondarySiteCollectionAdministratorLogin,
                        secondarySiteCollectionAdministratorName,
                        secondarySiteCollectionAdministratorEmail);
            }
        }
    }
    catch
    {
        // You can implement some logging here. It can for example happen that you provide
        // a URL of a site that already exist, a template that not exist etc.
    }

     return newSiteCollection;
}

The pitfalls

There are a couple of pitfalls you need to be aware of when you use SPSite.SelfServiceCreateSite. There are probably more, but these issues I encountered:

1. Current user needs to be set as primary administrator
   SPSite.SelfServiceCreateSite will only work if you set the current user as the primary site administrator. When you want to allow users to create a site “on behalf” of somebody else, that is still possible. You’ll have to create the site with the current user as the primary site collection administrator and once it is created, change the owner (don’t forget, after making that change you might not be able to let the current user change other settings!).
2. IntelliSense let you believe you have to add a secondary administrator
   When you use the
   SaveButton and use a custom control template for the list / content type.
   SPSite.SelfServiceCreateSite, IntelliSense tells you to provide string values for the secondary site collection administrator. By default my first instinct is to provide it with string.Empty (or perhaps “”). But this doesn’t work. You’ll get an error stating the user can’t be found or something like that. Instead you have to provide the function with null values.
3. This will only work on POST actions
   SPSite.SelfServiceCreateSite will only allow you to create new site collections on POST actions. When you use the function on a GET action, you’ll get a nice security exception telling you not to do that. This means you can’t easily provide this functionality in an event receiver (they are triggered AFTER the post event). If you still want to use it in an event receiver one way to get this working is to create your own
4. Not everybody may create site collections
   If you don’t want everybody to create site collections, you can prevent it by simply changing the permissions. By default the Site Permission to allow users to use Self-Service Site Creation is given to the Read role (so for all visitors!)
   
   
5. Users trying to create the site twice
   The operation to create a site collection might take a few seconds. This time will increase if you automatically want to activate features. An impatient user might want to “speed up” the process by clicking on the submit button again. This might cause the user to see a nice exception stating that the site is already created (he clicked the button twice, so he tries to create a site on the URL twice). To prevent this problem from occurring you might want to provide the user with a progress window. For this you can for example use the SPLongOperation
   

Download the code

• Source code
• WSP solution

Using SPLongOperation

The idea

Sometimes the actions triggered by users can take a while to process. This can for example happen when you create a site collection. At that time you:

• Don’t want your users to continue clicking on the button, the action should finish first. With the example of the creation of a site collection, you don’t want two attempts of creating a site collection with the same URL.
• Users must be made aware that the action might take a while and have the idea something is really happening behind the scenes.

 Microsoft provided some nice ways to have implement those long running operations. One is SPLongOperation which shows the user the “Operation in Progress” screen and it is actually pretty easy to implement.

The implementation

The implementation of the SPLongOperation is pretty easy. In a nutshell you create a new SPLongOperation, provide the different texts you want to display and you start your operation.

The next code example will be triggered by a button in a WebPart. It doesn’t actually do anything, but just let the current thread sleep for 5 seconds. In that time the “Operation in Progress” page is being displayed.

 /// <summary>
/// This test function will also call <see cref=”ALongRunningAction”/>, but it will
/// use <see cref=”SPLongOperation”/> to show a progress indication
/// </summary>
private void ALongActionWithProgressIndicator()
{
    // Determine the page to navigate to when the operation is successful
    string successUrl = SPContext.Current.Web.Url;

    // Create a new SPLongOperation
    SPLongOperation longOperation = new SPLongOperation(this.Page);

    // Provide the text displayed in bold
    longOperation.LeadingHTML = “Long running operation is being performed”;

    // Provide the normal formatted text
    longOperation.TrailingHTML = “Please wait while your request is being performed. This can take a couple of seconds.”;

    // Let’s start the code that takes a while from here
    longOperation.Begin();

    try
    {
        // The code that might take a while
        Thread.Sleep(5000);

        //When the action is performed, the page will be redirect to this url
       longOperation.End(successUrl);
    }
    catch (ThreadAbortException)
    {
        // Don’t do anything, this error can occur because the SPLongOperation.End
        // performs a Response.Redirect internally and doesnt take into account
        // that other code might still be executed
    }
    catch (Exception ex)
    {
        // When an exception occurs, the page is redirected to the error page.
        // Redirection to another (custom) page is also possible
        SPUtility.TransferToErrorPage(ex.ToString());
    }
}
 

Pitfalls

There is one thing you might want to take into account when you use the SPLongOperation. The SPLongOperation.End internally uses a Response.Redirect which doesn’t take into account that you might have other code that is executed at the same time in a different thread. In order to prevent a ThreadAbortException message to display, you might want to catch that error.

The result

I created a small WebPart with two buttons for this demonstration.

1. Button one doesn’t use the SPLongOperation and you’ll see the page loading for 5 seconds.
2. Button two uses the SPLongOperation and it displays the “Operation in Progress” progress page

Figure 1: Test WebPart

Figure 2: Operation in Progress screen

Download the code

• Source code
• WSP solution