SharePoint Lessons Learned

If you are creating a new site in a site collection, and inadvertently create a publishing site while the publishing feature is not enabled at the site collection level, I've noticed some strange functionality.

An Error message will be displayed that states:
"The Office SharePoint Server Publishing Infrastructure feature must be activated at the site collection level before the Publishing feature can be activated."

The site that you have attempted to create will still be viewable from the View All Site Content link (then look under Sites and Workspaces) but will generate a 404 error if you attempt to browse to the root (either by clicking the link under view all site content, or manually browsing to the site name you've chosen). This is because the site was created, but was not given a default.aspx page. I've found that the only way to delete this broken site, is to browse manually to the site's settings page (which does exist).

This can be navigated to like such:

http(s)://portal_url/site_collection_name/broken_site_name/_layouts/settings.aspx

UPDATE:

Apparently, stsadm does not create this broken site.

Problems with SPFeatureCollection.Add

#1) SPFeature.Add ignores access denied failure

My major problem with SPFeatureCollection.Add is that it does not report failure due to access denied.

In the case of attempting to add a site collection feature, when the current user is not a site collection administrator, SPFeatureCollection.Add will create a new SPFeature object in the collection and return it, although the feature has not actually been activated on the site collection. I expected to be able to work around this by creating a new SPSite object (pointing to the same site collection) and checking its features collection, but no -- the new feature appears there as well.

For this reason, SharePoint Solution Installer does not report activation failures -- because they seem undetectable at the API level.

 

#2) SPFeatureCollection Add & Remove act differently than GUI if feature receiver not found

My second problem with SPFeatureCollection, Add and Remove both, is that they succeed silently in the face of feature receiver misconfiguration. From the GUI, activating or deactivating a feature missing its feature receiver assembly will fail, with a fairly descriptive error message (if custom errors are disabled). However, SPFeatureCollection Add and Remove will both actually succeed in this case.

This can be useful; it is a workaround to deactivate a feature which cannot be deactivated from the GUI.

SharePoint site settings GUI will not let you create a column with a display name already in use (as an existing site column, even inherited from higher level site)

SharePoint site settings GUI will adjust the field's InternalName and StaticName both to make them unique among site columns.

When adding columns to a list, it is possible to get two fields with the same StaticName, but not with the same InternalName.

SharePoint seems to append a 0 at the end to make list columns InternalName unique, but a 1 at the end to make site column InternalName (& StaticName) unique

Installing a solution with a field with all 3 matching names xml-Title (DisplayName), xml-StaticName (StaticName), xml-Name (InternalName), will succeed but silently fail to install that field.

But it is possible to successfully install a solution a field with the same xml-Title (DisplayName), xml-StaticName (StaticName), as long as the xml-Name (InternalName) is unique.

Summary:

Site Column GUI: DisplayName must be unique. SharePoint will adjust StaticName & InternalName to keep them unique.

Feature installation of site column: xml-Name (InternalName) must be unique. SharePoint will allow duplicate DisplayName & StaticName.

List Column GUI: DisplayName must be unique. SharePoint will adjust StaticName & InternalName to keep them unique.

Adding site columns to list columns via GUI: DisplayName and StaticName don't have to be unique. SharePoint will make InternalName unique.

SharePoint 2007 site columns have three names.

XML Element	SPSite.SPField	SPList.SPField	Site GUI	List GUI
Title
Name	InternalName	InternalName*	in edit URL	in edit URL*
DisplayName	Title	Title	Name	Name
StaticName	StaticName	StaticName

I don't know what use the XML element Title is, as it does not appear in the deployed site column or list column.

The list instance InternalName is marked with an asterisk above because it cannot be updated afterward.

Using only the GUI, the StaticName and InternalName are normally created the same as the Name. Thereafter, via the GUI, only the Name of the site and list columns can be edited, and the StaticName and InternalName do not change.

Using a "Field" feature, the InternalName, StaticName, and Name of the site column can all be updated; the key is the GUID. But, the site column must not have been customized (or else it will not receive any updates from the feature XML).

Updated values in the site column can be pushed to the list column via the SPField.Update method, with the caveat that this does not propagate the InternalName.

The list column InternalName is the one used by CAML queries and XSLT references for webparts.

My solution to updating feature-based columns is to use a feature receiver, with code in both the FeatureActivated and FeatureDeactivating methods.

1. The FeatureActivated method calls SPField.Update on any fields which are in use, to push any changes down to list columns. This call causes the site column to become customized.
2. The FeatureDeactivating method calls SPField.Delete on all of its site columns. This removes the customized site columns, so that at the next update, they will again be installed from the feature xml.

Each time you create a list view web part on a page (Edit Page/Add Web Part from Lists and Libraries), SharePoint 2007 adds a new hidden view with empty title to the source list's views.