Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I need to change a root site's Item Content Type settings back to the default values. I also need to do this for all other Content Types that inherit from Item. Can someone recommend a safe an efficient method to do this? It’s important that we restore the Site Content Type definitions only; we don’t want to lose any customizations.

Background:

Someone went into the root level of a SharePoint 2010 site and changed the Column settings for the Item Content Type's Title field by making it Hidden instead of Required. When they did this they updated all content types that inherit from Item. This was done via root/_layouts/ManageContentTypeField.aspx under: Site Settings > Site Content Types > Item > Change Content Type Column

After problems arose, another person went and changed it back to Required (also updating all inherited Content Types). This was not the correct solution because some of the descendant Content Types have different defaults. For example: the Document Content Type's Title Field is Optional by default.

Aside from manually going through everything listed on /_layouts/mngctype.aspx what's an efficient and safe way to restore the default values of the 'built in' Site Content Types?

Many thanks!
-- 2/8 Update --
UPDATE: Haven't had time to deal with this yet but I wanted to thank everyone for their responses. A coworker wrote a powershell script for me that iterates all content types and outputs the Title field's settings for each. Pretty sure I can modify it to re-set the defaults (after comparing the script's output from a fresh SP install). In case it may help anyone, here's the script in it's current form:


[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = new-object Microsoft.SharePoint.SPSite(“http://site:port”);
$myContentTypes = $site.rootweb.contenttypes | ForEach-Object {
     $myContentType = $_
     $myFields = $myContentType.Fields | ForEach-Object {
       $myField = $_
       if ($myField.Title -eq "Title")    {
          write-host $myContentType.Name'|'$myField.Hidden'|'$myField.Required
      }
   }
}
#>

$site = new-object Microsoft.SharePoint.SPSite(“http://site”);

$path = "c:\path\outputFile.csv"
$csv = Import-csv -path $path

foreach($line in $csv)
{
    $myContentType = $site.rootweb.contenttypes[$line.ContentType.trim()]
    $myTitleField = $myContentType.Fields["Title"]
    if ($myTitleField.Hidden.ToString().trim().ToUpper() -ne $line.HiddenAtt.trim().ToUpper() -or $myTitleField.Required.ToString().trim().ToUpper() -ne $line.RequiredAtt.trim().ToUpper())
    {
        if($line.HiddenAtt.trim().ToUpper() -eq "TRUE")
        {
            write-host $myContentType.Name: Title field is HIDDEN
        }
        else
        {
            if($line.RequiredAtt.trim().ToUpper() -eq "TRUE")
            {
                write-host $myContentType.Name: Title field is REQUIRED
            }
            else
            {
                write-host $myContentType.Name: Title field is OPTIONAL
            }
        }

    }
}

share|improve this question
add comment

4 Answers

I just randomly came across this post and although its old I wanted to give the solution since I recently ran into this issue. To "reinstall" the built-in fields (and this should fix the field issues in the ctypes) just run the following command for each of your affected site collections:

stsadm -o deactivatefeature -name Fields -url http://sitecoll -force
stsadm -o activatefeature -name Fields -url http://sitecoll -force

This will put the fields back to the state they were in when you installed. There is no other way to do this via the api or otherwise because some of the special hidden columns ca not have version attributes, even version="0" which will be automatically incremented each time you update the field by a stored procedure in the db (even if you just upate a field to be read-only).

Good luck and always make your own fields and ctypes leaving the stock ones intact.

share|improve this answer
add comment

SharePoint doesn't keep a 'version history' of content types. There's also no 'reset' option that I'm aware of. Unless you can use backups, I feel that you are faced with a laborious manual task here. I hope you have a test environment you can compare against...!

share|improve this answer
    
Right. Also note that "Reset to Site Definition" can't help here anyway. It removes 'customized pages' and doesn't affect anything else like content types - see office.microsoft.com/en-us/sharepoint-designer-help/…. –  Alex Angas Jan 14 '11 at 7:47
add comment

You could perhaps use a tool like http://moss2k7ctypesviewer.codeplex.com/ to capture the CAML for the content types, and likewise for a new site collection, and then diff the two.

You could in theory uncustomize the content types so that they revert to the site definition, but I don't know of any equivalent method to RevertContentStream for content types. I think your best plan is to manually revert the changes and check the results against an uncustomized site collection.

share|improve this answer
add comment

I feel your pain. This just happened to me two weeks ago.

We first tried restoring the ContentTypes table, as described here: http://msmvps.com/blogs/obts/archive/2007/05/25/926061.aspx, but no such luck. It fixed some errors, but introduced a HREFERENCE exception. At this point, we knew that we didn't know enough about how to fix this and we needed to stop the bleeding.

Ultimately, we cut our losses and restored from backup, from just before this problem was introduced. We mirrored the corrupted but up-to-date backup on a dev site, so we at least could access current data that had been stored in SharePoint between the time of this problem and the time we restored from backup (4 business days!). From there, our database people queried and found list items and documents that had been created or edited during this time, and I manually re-created this content.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.