Content Type Archives

New Button Order and Default Content Type is lost after moving a site

If you have customised the new button order and/or default content type for a list or library, then expect these changes to be lost if that site is moved. SharePoint Bug! You may have done this in order to change the content types that appear under a list’s new button or change the content type that used by default (i.e. when a user just clicks the new document icon rather than selecting a content type from the drop down).

As you can see in the image above, I have a library configured with a restricted set of content types available under the new button. After moving the site (using Site Settings > Content and Structure) these customisations are lost. See the next image.

The same library having been moved to a new location

So that’s the issue but what can you do to fix the situation if moving sites is something that you need to support regularly? Firstly, this isn’t the only issue you may encounter.

With the luxury of a farm solution this can fixed using a web event receiver. Using the WebMoving event you can store list new button order information (e.g. in a web property bag) and then in the WebMoved event, this information can be read and applied. I don’t have a code example of this as in my situation it was suitable to apply a static new button order to lists based on the site definition and list template.

If you are unable to deploy a farm solution (e.g. SharePoint Online) then this issue is more difficult to solve. I assume that you can write remote event receivers for web events and apply the same logic as above (I haven’t tried this). Otherwise I can’t think of another reasonable solution beyond writing a control with client JavaScript that ensures the new button order upon viewing the page. However this would require knowledge of what the new button order needs to be, and hence would be more complex to implement if users are free to change it.

Modifying content type field properties

A SharePoint site column has a number of properties which, as a developer, you may need to alter. These properties include Name, Type, ShowInEditForm, ShowInDisplayForm, Hidden etc. Some of these properties can be changed once at the site column level and the changes can be propagated to all lists in the site collection. This is surfaced in the UI for a selection of properties:

The same (with the ability to set many more properties) can be achieved with PowerShell (or, as always, in C#):

$site = Get-SPSite $siteUrl $field = $site.RootWeb.Fields[$fieldName] # set field properties $field.ShowInDisplayForm = $false # update field - pass in true to push changes to lists $field.Update($true)

The properties that are not listed in the UI may not “update all list columns based on this site column” as you would expect if you are using content types. Content types have a collection of field references (or links) to the list columns which get updated, but the links themselves have their own set of properties which override those set for the list field. This means that if you run the PowerShell snippet above, any existing content types which reference that field will continue to show the field on edit forms. To get around this issue, one must update the content types individually. The PowerShell script below is an example of how you might achieve this.

# Set variables $webAppUrl = "http://XXX" $fieldInternalName = "MyFavouriteField" $listNames = @("Official Documents", "Liaison Statements") $contentTypeNames = @("OD Document", "CR Document", "LS Document") Write-Host "Hiding field '$fieldInternalName' from display forms" -NoNewline # Get Site Column $site = Get-SPSite $webAppUrl if($site -eq $null) { throw "Failed to find site by url: $webAppUrl" } foreach($web in $site.AllWebs) { try { foreach($listName in $listNames) { $list = $web.Lists.TryGetList($listName) if($list -ne $null) { foreach($ctName in $contentTypeNames) { $ct = $list.ContentTypes[$ctName] if($ct -ne $null) { $updateCt = $false $field = $ct.FieldLinks[$fieldInternalName] if($field -ne $null) { # Update field properties $showInDisplayForm = $false if($field.ShowInDisplayForm -ne $showInDisplayForm) { $field.ShowInDisplayForm = $showInDisplayForm $updateCt = $true } } if($updateCt) { $ct.Update() Write-Host "." -NoNewline -ForegroundColor Green } else { Write-Host "." -NoNewline -ForegroundColor Cyan } } } } } } catch [System.Exception] { $errorMessage = $Error[0] Write-Host "" Write-Host "Failed on $($web.Url), $errorMessage" -ForegroundColor Red } finally { $web.Dispose() } } $site.Dispose() Write-Host " done" -ForegroundColor Green

This is all pretty obvious when you really think about it. It is a necessity to allow for the flexibility of content types on a list to handle list data in their own way.

New Button Order ‘Bug’ and Document Sets

The Quirk

Using the SharePoint GUI to modify list or library settings with the goal of changing the ‘new button order’ or ‘default content type’ may yield unexpected results.

Under List Settings, this is the functionality in question

Confusingly (or perhaps to avoid confusion) the control which displays the ordering of the content types for the New button, along with their visibility, does not show the items in the order in which they have been set.

Initial view of the New button order control

As an example of this, I will set a content type marked as not-visible to have an order of 1.

I have am marking a non-visible content type as the default content type (position 1)

I press OK to save the form. Upon returning to the form it would be reasonable to expect to see the control rendered with the non-visible content type in position 1 as we have just set it to be this way.

I would have expected the control to render like this. IT DOES NOT!

However, this is not the case. You will see the content types listed in same order as before the change was made.

After making the change, the control is rendered in exactly the same way as it was before the change

The control always displays the visible content types at the top of the list which are then sorted by order number. The content types which are not marked as visible are then shown in alphabetical order. Importantly, this is just how they are displayed. The actual content type order may be different depending on how you have set it.

So who cares?

Most likely there are very few people who will even notice this let alone care. In fact, in nearly all scenarios it makes perfect sense to render the control this way. That is, until you want to have a default content type that is not visible under the new button. At this point the control may become very misleading. There is really just one case where the control does not accurately display the functional impact of changing the content type order. When you set a non-visible content type as the default content type (position 1), it is still treated as the default content type, despite how the control may render it.

Why would you want a default content type that is not visible under the new button?

In my case it was because in the library’s root folder only document set content types and a particular document content type (A) were allowed. However, inside the document set only a different document content type was allowed (B). By setting the document set’s allowed content type you can have the new button display content types that are not listed as visible in the list settings. All good, you can only create documents of content type B inside the document set and only create document of content type A outside the document set.

My issue arose when a user uploaded a document to the document set. An uploaded document ignores the document set’s allowed content type and is created as the first content type listed on the New button order in the list settings. To workaround this issue I set content type B as position 1, which works as expected despite how the control may render it.