What happens to content types when you add a column to a list in SharePoint?

This is sort of relevant to an earlier post on the Document Information Panel, and showing fields in it.

The behaviour depends on if you’ve enabled ‘Allow management of content types’ on the Document Library Settings > Advanced Settings page.

If you’ve not allowed management of content types, well, you just add the column and it’ll appear in the document information panel. That’s great! The new column will not show as belonging to any content types, as the ‘Test‘ column is in the screenshot below:

Extra List Columns

However, if you have allowed management of content types for the library, things get a little more complicated. When you add a new column, in the ‘Additional Column Settings’, there will be an option for ‘Add to all content types’. If you check this, well, it’ll add that column to all the content types currently on that list. This will make it appear on the document information panel. This is what I did with the ‘Test2′ column above (but before I added the Picture content type to the library).

(As a side note, the content types on the list are actually ‘children’ of your Site content type rather than instances of it. This means that if you update the content type on that list, it won’t update the parent content type, or other lists that use that content type. Similarly, it mean that if you update the parent content type – say, you edit the site content type – you need to update child content types with those changes to affect lists that are using them already. But that really should be another post, sometime.)

If you don’t check that ‘Add to all content types’ option, well, it doesn’t add it to the document information panel. Finally, what if you have added a column all content types, and you add a new content type to the list? Well, your new content type will not have that new column applied to it – and the only way I can see of applying it to the new content type is actually to delete and recreate it. Of course, that means deleting a column that contains data, so that is less than ideal. This is what happened with the Picture content type – I added it afterwards, and you can see that it doesn’t use the ‘Test2‘ content type.

For that reason, be very careful when adding columns to library that is allowing management of content types. If possible, keep the columns in the Site Content Type (i.e. the parent).

What happens to content types when you add a column to a list in SharePoint?

Missing Content Type fields in the Document Information Panel

The Document Information Panel is great – it allows you to surface metadata to be filled in about a Word 2007 document in the client.

Document Information Panel Correct

This is great, but I had a bit of a puzzling problem. I’ve set Libraries up to use this features many times now, and it’s pretty straight forward – I’ve added columns to the library, and then the template document for the library has included those columns. Thus, you just go into your document library, click new, and you get a blank word document with the correct document information panel thing. Sometimes I’ve modified that template, but that’s pretty straight forward through the Library Settings pages (Document Library Settings > Advanced Settings > Edit Template).

This time, though, I was using content types (i.e. setting up the library properly), rather than just adding columns directly to a list. Content Types encapsulate (amongst other things) their own set of metadata to be captured – so in other words, they define columns to be added to a list. That’s fine (and very useful).

However, when I went to my document library, clicked ‘New’ and selected my Content Type, I got a blank word document with only one field in the document information panel – title. The blankness was expected (I’d not defined my own template) but none of the other bits of metadata I’d defined for my content type were there. This was a bit of a puzzle. What was different?

Well, after much thinking, I realised something – Content Types ‘inherit’ from each other. My Content Type derived from the Document content type, which specified just one field of metadata – Title. Then it hit me – content types themselves have document templates. My new content type was inheriting from Document, and it was still using the Document content type’s template document. I specified my own template document for my content type and suddenly I had all of my fields available in the document information panel.

It is interesting that there is this difference between the document information panel fields being defined by the library when just using the default ‘Document‘ content type and no others, and the fields being defined by the content type you’ve created if you’re using other types (I.e. you’ve enabled ‘Allow management of content types’ on the Document Library Settings > Advanced Settings page).

Related to this, then, is the question of what happen if you add a column to a list. However, I’ll cover this in another post.

Missing Content Type fields in the Document Information Panel

Error: "The document information panel was unable to load"

I was building a demo where I was wanting to show the document information panel in Word 2007 (which I think is one of the neatest features about it!) . It should look like:

Document Information Panel Correct

But instead I was getting “The document information panel was unable to load“.

Document Information Panel Error

I couldn’t see a reason for this, but investigation found this post which shows the same error, and a solution in the comments:

The System Event Nofication Service (SENS) uses the same communication “channels” (not the correct word, but works) as does office products do in communicating with the server.
Stop and disable the SENS service on the server and everything will work perfectly.

So, open a command prompt and type:
net stop sens

Bit strange, but that fixed it for me. Also note the comment at the bottom that the Document Conversions service doesn’t work on a single server demo system like this.

Error: "The document information panel was unable to load"

The default locale of DateTime columns in the Dataview web part

More bugs in the dataview webpart – this time not being able to set the default locale for the page’s dates to being UK. When you add a datetime column to the view, if you look at the code, I can see the locale of 1033 (en-us), and the date formats available are only US format.

On my system, however, while the date formats appear to be US format in SharePoint designer, the code for a datatime column that I add to the view contains the 2057 locale (en-gb) , and the date formats display correctly in the page itself.

So it’s almost like SharePoint designer thinks it is working with US date formats, despite the settings of the Page Editor settings page, the Regional settings on the machine, and the Regional settings on the site all being set to UK date formats. I don’t know if I’m missing a setting somewhere, but if I am, I really don’t see it!

This problem can be fixed by resetting the locale by hand in the code, but really, you shouldn’t have to.

The default locale of DateTime columns in the Dataview web part

Fixing the comparison operators on the DataView web part filter dialog (maybe)

As mentioned previously, I was having some problems with not having the right operators in the Filter Criteria dialog of a DataForm Web Part. Although the field I was trying to filter by was a date, I was only being shown the options as if it was a string:

Broken DataForm Filter Criteria Dialog

Well, proving that invention is 99% perspiration, I managed to find a solution. On the list on my customer’s system there was a Lookup column which referred to a list that no longer existed. Note the lack of List name for where it’s getting information:

Broken Lookup Column Details on a List

When I removed that column from the list, I could filter correctly again:

Working DataForm Filter Criteria Dialog

This is despite the fact that the broken lookup column is not used either in the display on the DataForm webpart, or in it’s filter. Merely its presence is enough to screw things up. Note that this is a different solution to other ideas that have been suggested elsewhere.

Fixing the comparison operators on the DataView web part filter dialog (maybe)

Replacement Content Editors

I mentioned before about looking at other content editors for SharePoint 2007. Well, it came as a bit of a surprise for one of my colleagues to discover that you could do this!

Anyway… so I had a look at other content editors. Well, the one replacement that I could find. Telerik make a variety of controls that can be used in MOSS, including a free ‘RadEditor Lite‘ and then the full ‘RadEditor‘ (which has a free trial). A comparison is available. I’ve used their controls before – they’re pretty good, and their forums and support are very good (which is probably more important when you’re developing). Some of their controls I’ve used before had their quirks – but that’s true of all ‘rich’ controls in web applications, in my experience. The Telerik ones were better than most.

I must actually give it a go sometime. There are extensive instructions on the Telerik site.

Replacement Content Editors

Wrong comparison operators on datetime field with Dataview WebPart

This was a weird error – but I’m not the first one to see it. When using a dataview web part, and trying to do a comparison with a date column, the filter dialog wouldn’t let me choose certain comparisons. The ‘Less than’, ‘Less than or equal to’, ‘Greater than’ and ‘Greater than or equal to’ options were all unavailable, and options like ‘begins with’ were available. It’s very strange, as it’s almost like the date was a text column – except that isn’t, and that another user did get those options.

I’m not sure if this is a security related issue as the linked post seems to suggest, but it’s really weird that the two users with the same permissions looking at the same system see this field in such different ways. I don’t have a resolution, I’m afraid.

Wrong comparison operators on datetime field with Dataview WebPart

Forms Based Authentication in SharePoint

As mentioned recently, I set up an FBA SharePoint site following the instructions from Dan Attis and Andrew Connell. I tried Dan Attis’ instructions first, but they didn’t actually work – for some reason, when I’d try to log in, I’d just be returned to the “Sign in” page. I repeated setting everything up using Andrew Connell’s instructions, which worked! The only differences I could see were Andrew’s instructions to add the alternate authentication provider to both the intranet and internet IIS web sites, and that Andrew’s set up started with the intranet site. I believe that second difference a red herring – either I made a mistake following Dan’s instructions and couldn’t figure out what (most likely), or the alternate authentication provider really does need to be in both sites’ (and the central admin site’s ) setups.

Andrew’s instructions also go into the question of allowing annonymous access to parts of the site. As a big note for myself though:

You must be logged in as an administrator via Forms authentication to set the annonymous access settings.

I keep forgetting that.

I also have been having a look at the Community Kit for SharePoint. This is sort of a bunch of ‘bits’ that are useful in creating an online community of one sort or another, and the part I’ve been looking at is the Intranet/Extranet Edition. This provides a number of features for giving you web parts for login, membership creation, password reset, and so on. They’re very neat, but the whole thing seems to be stuck at a pre-beta stage, and I have had some issues with them. I’m hoping that they’re still under development – if all else fails and I have to, I’d look at fixing/debugging myself. It’d be good to get this to a full release.

Forms Based Authentication in SharePoint

Can't open a new window in link format settings in Dataview WebPart

I’m using a dataview web part, and have set one of the columns to be a link using the formatting tools. This works just fine! However, when I try to set a target for the link of _blank (to create a new browser window and open the link in that), well, the page doesn’t save correctly. No _blank is put into the links, and you have to reload the page in SharePoint Designer ‘cos it’s gone funny.

Again, I’ve not got a solution to this – although the customer in question might not be using SP1 yet.

Can't open a new window in link format settings in Dataview WebPart

Modify the RichHTMLField control on your page layouts

When building an intranet, it’s important to try to get consistent styling and formatting, especially if you want to be able to update this later. How do you do this?

To create Pages in SharePoint, you have two options really:

  • Create by hand though the site’s ‘Create Page’ function. Fill in and format your text using the Content Editor Control
  • Create the content in Word, InfoPath, etc., and convert to a Web page using the Document Conversion service.

I’ve been having a bit of a look at this:

Creating Pages through the Web interface

In the SharePoint site, create a new page. Depending on the layout, often they have a RichHTMLField control. In Edit mode, this displays a content editor:

Normal Content Editor Control

and when published, it just displays that content.

However, this control has a lot of options. Editors can adjust text fonts, sizes, colours, boldness – they can even get into the HTML and edit that! I quite like this, but it’s hardly conducive to having a consistent style. What would be good would be to have a number of pre-defined styles, and lock out the other control options.

First, let’s look at removing those option buttons. It turns out that the RichHTMLField control has a number of properties you can set to disable these. This works nicely:

<PublishingWebControls:RichHtmlField id="content" FieldName="PublishingPageContent" runat="server" DisableBasicFormattingButtons="True" AllowTables="False" AllowHtmlSourceEditing="False" AllowLists="False" />

Results in:

Modified Content Editor Control

What I’ve not yet been able to figure out is how to disable the ‘standard html format’ menu thing (the paragraph sign ¶ ). I know that it’s for formatting the whole of a paragraph – but we have some problems with that, as we’ll see later. Anyway, now we’ve got those buttons disabled, user’s are MUCH more restricted in the styles that they use.

Second then, how do we define our own styles for the ‘Styles’ menu in the Content Editor? Well, this is a bit more complicated, but there is good documentation out there. Ari Bakker has some good instructions, there’s another (less consise) example from MartyG and there is good documentation on MSDN – though do not believe the top comment, I’ve had my styles working from another CSS file just fine. Do pay attention to the second comment – to see the styles in the menu, you will have to Select some text.

The steps as I found them ultimately were:

1) In your RichHTMLField set the PrefixStyleSheet=”someName”

2) In your styles (whichever one you fancy, as far as I can tell) set up your styles:

.someNameCustom-Heading1 {

...

}

.someNameCustom-Heading2{

...

}

3) Publish.

4) Make sure you’ve selected some text, then choose a style:

Editor Styles Menu

Just as a sidebar, there is a fairly good article on MSDN about “How to Create a SharePoint Server 2007 Custom Master Page and Page Layouts for a Web Content Management Site

Anyway what about the next option….

Creating Pages with the Document Conversions Service

First off, this requires that your servers are setup and running the service and your content types are configured set up for it. That’s not too surprising, and I’m not going to go into that any further. I’m also going to look solely at authoring from Word only, and not InfoPath or XML.

Now, things might get confusing here between CSS styles and Word Styles. For simplicity, from here on I’m going to refer to CSS styles with small s (styles) and Word Quick Styles with a big S and italics (Styles).

Once those are services are set up running, you face the same first problem as with the web page authoring – how do we stop users mucking around with our Styles and formatting, except that this time it’s in Word. Well, Word 2007 lets you do this. First, go to the Manage Styles Menu:

Manage Styles in Word

Then on the ‘Restrict’ tab, set the Styles you want to limit users too. This will password protect your template, so that others can’t just undo these settings. Then get users to create their pages using these Styles – they can’t create new Styles or modify the colour/boldness/formatting of the text directly..

Okay, so what happens to the Styles when we upload and convert the document. Well, that depends on the settings you configure for the conversion:

Styles Settings

You can either strip out the Styles from the document, or keep them. Okay, but what does that mean?

Well, Word has a number of ‘default’ Styles – normal, Heading 1, Heading 2, etc. – and there are style definitions of what they should look like in a stylesheet called ‘RCA.css’ (for Rich Client Authoring). In SharePoint Designer you’ll find this in ‘style library > en-us > core styles’ . This defines a the styles for a bunch of Styles
RCA Styles
Click on the image and take a look. You’ll notice that there are css styles for Heading1-P and Heading1-H – we’ll come back to why there are two of each style.

Anyway, returning to what happens to the Styles – if you decide to ‘Remove CSS <styles> section…’ you’ll get a page where your text is formatted as per the styles in RCA.css. This might be quite different to the Styles in your original Word document! Default Styles (Normal, Heading 1, etc.) will be defined by the CSS styles in RCA.css. If you have extra Styles beyond the ‘default’ ones in Word, then they will not have any style, as they don’t have any definition in the RCA.css file. For example, if I define a Styles in Word called ‘Heading 1 Red’, then my page will use css classes called Heading1Red-P and Heading1Red-H. However, in the RCA.css file, there is no definition for these classes, and hence they’ll be unformatted. You can add them though, or you can put them in another stylesheet, etc..

What if you choose to ‘Store CSS <styles>…’? Well, then the CSS definitions for the Styles get stored with the page, and the out-of-box page layouts put this content into the header – but after the RCA.css file has been referenced, so these styles take precedence. Thus, your document will be styled as defined in the document (well, more or less).

Great! Oh, wait, what if I want to change all of my Heading 1 styles and I’m storing the CSS in the page? Well, that’s a problem – ‘cos each page has it’s own definition. Because of that, I would suggest setting up templates with known Styles , locking them down, defining the css styles for those Styles in a CSS file (like rca.css), and then making sure your document conversion ‘Removes CSS‘. If you have gone down the route of having your styles stored with your page, you might be able to fix things by simply removing the FieldValue control that inserts the styles into the page – for the PageFromDocLayout that comes out-of-box, this control is the PageStylesField.

Anyway, you can see why I’m suggesting locking the Styles on your templates – otherwise you might end up with users creating new Styles which aren’t defined in RCA.css, which is pretty painful if you’re then removing the css styles during conversion .

As a side note, what about inline changes to the format of text – what if I change the format of something without creating a new style? Well, those formats are stored inline in the converted page. If, for example, you made some ‘Normal’ Style text red, you’d get the code…

<span style="color:#FF0000">Normal Style + Red</span>

… in your page. Note that this can’t be overridden by style sheets – and doesn’t seem to be removed by either of the Remove or Store CSS options mentioned above. Best to avoid allowing this (returning us to locking down your template again!)

Now, I said I’d return to the question of why two styles for each Style. Well, the short answer is I’m not sure – but it does seem that in Word when you set up a style it applies both to a paragraph (e.g. paragraph spacing), and to a bit of text (e.g. font/colour, etc.). During conversion it appears that to account for this, two styles are required. The converted document’s HTML looks like …

<p class=Normal-P style="margin-top:3pt;margin-bottom:0pt;direction:ltr;unicode-bidi:normal">

<span class=Normal-H><span class="minorAnsiTheme Normal-H">Normal Style</span></span>

</p>

…so that might give you some idea. (The text in this paragraph is actually the phrase ‘Normal Style’, and the style applied to it is ‘Normal’).

Final note – and this really caught me out – if you convert a document to a page, then you adjust the document conversion settings and you want to reconvert that page, delete and recreate the page. Updating the page does not seem to change the page, perhaps ‘cos you’ve not updated the document itself.

What about using both?

Well, that’s tricky. The structure of the HTML and the styles are different, so you can’t just apply the same styles as is in the RCA.css file. In principle you can us both in your authoring, but you probably do need to have different definitions for the ‘Heading 1’ style in your Content Editor, and ‘Heading 1’ in your RCA.css file. I’ll blog more about this shortly, but right now I’m tired!

Modify the RichHTMLField control on your page layouts