Brian Caauwe

OMG where did my "Title" go?

If you have ever needed to deal with Site Columns and Content Types you probably have come across the dreaded "Title" column and maybe felt creative and changed it to a different name, and figured if I need to change it back, I can change it back... right?

I've come across many clients that have changed the column name, then tried to change it back to "Title" only to come across this taunting dialog box

"The column name that you entered is already in use or reserved.  Choose another name."  You may be thinking, you let me change it, why can't I change it back?

The good news is, with the magic that is PowerShell you can.  If you open PowerShell and get your $site and $web objects you can retrieve your "broken" field by calling $web.Fields["fieldName"] or in my case $web.Fields["PowerShell"].  Looking at the properties of that field you will notice the "Title" property is what you had previously set, along with a LOT of different properties for that field. 

In order to change it back to, simply modify $field.Title = "Title" and process a $field.Update().  Below is a sample set of calls to reset the field back to "Title".

After the you have updated the field in PowerShell you will want to make sure to push that change to all content types based on Item.  Go to your top level site and locate the Item content type where you will see the column back to "Title".

Go ahead and open up the site column from the "Edit site column in new window" link

If you had also changed the group away from the OOTB group and want it "hidden" again, change the group back to _Hidden and click OK.

NOTE: If you have a large site collection with many subwebs this process can take some time to complete.  Also if you have any workflows or any custom event that is targetted to that old name the possibility that it is now reset to Title is good, make sure to check your processes.

["Brian"]

Site Definition visibility property

I was helping a co-worker of mine today determine why the Site Directory site definition was not showing up as an option underneath a Publishing Portal and found a nice property for site definitions I never knew existed. By the way, it turns out that in order for the Site Directory to show up as an option you need to have the PortalLayouts feature enabled, which of course is a hidden feature but is also enabled as a dependency from the Office SharePoint Server Standard Site Collection feature or the Office SharePoint Server Enterprise Site Collection feature. 

Anyway, after finding the Site Directory site definition I noticed this fun new property called VisibilityFeatureDependency in the webtempsps.xml file that sets a bunch of properties for the site definition.  Here is the entry for the Site Directory definition in that file:

 <Template Name="SPSSITES" ID="34">
    <Configuration ID="0" Title="Site Directory" Type="0" Hidden="FALSE" ImageUrl="/_layouts/1033/images/template_site_dir.png" Description="A site for listing and categorizing important sites in your organization. It includes different views for categorized sites, top sites, and a site map." DisplayCategory="Enterprise" VisibilityFeatureDependency="5F3B0127-2F1D-4cfd-8DD2-85AD1FB00BFC">
    </Configuration>

With that being said, if you have a custom site definition in your environment and have seen issues where people are creating sites based off of that definition, and you only want that custom definition available in specific areas you could take a similar approach by creating hidden features that you activate either through feature stapling, site definition properties or PowerShell activation and then those types of sites will only be available for end users at the level that those hidden features are activated on. 

A good example of this would be the normal Client and Project site relationship.  You have a client sites dashboard page for which all users can see the client sites that they have access to, and you activate a hidden feature at that level for which makes the Client Site definition available in the Create Site screen.  When the client site is created, the hidden Project Site activation feature is activated and you can then choose to create Project Sites from the Client site level.  Using this method you can guarantee that the client and project sites will only be created at the level where they are supposed to live.

Update:

I just read this morning that according to MSDN the VisibilityFeatureDependency property "is not supported for Features with Web application scope".  I'm going to try this out in the next coming weeks to see if it works for web scopes or if there are some underlying issues with it.  This information could just help define what features you may need to create and at what scope level.

["Brian"]

Content Deployment Wizard

Even though this news is a little more than a month old, the SharePoint Content Deployment Wizard, created by Chris O'Brien has finally reached Release 1.0 and can be found on CodePlex.  I have recommended, and used, this tool for various migrations where we have needed to re-organize content within new sites.  The best part about this tool is it's fully used through a GUI so all types of people can use it.  To see how to use the tool visit Chris' blog here.

Since webs are always bound to their site definition (i.e. Team Site = STS#0), I have gernally used this tool to pull content out of a custom site definition and place it back into a standard definition where clients have had issues migrating these definitions in the past.  The unfortunate thing about taking just the content (lists, libraries, etc) out using this tool means that you loose all custom permissions since all of those are set on the web level.

With that being said, I still strongly recommend this tool, if for nothing else it uses the SharePoint Content Deployment API's which means everything that's going on under the hood is native to the platform and with the release of the new Infrastructure Updates for MOSS 2007 and WSS v3 which not only gives you the new Federated Search functionality (additional blog post coming soon...) but also MAJOR updates for people that have been dealing with content deployment issues in the past.

["Brian"]