Deploy Publishing Pages and Content Types as a feature

Aka “CAML is the bastard spawn of Satan”.

So, I’m writing a site definition to create a Publishing site. This is a bit of a first for me. One of the things I want to do is deploy a new Publishing Page Content type, and associate some layouts with it.

I started by following Andrew Connell’s instructions for a Minimal Site Definition (as in his book). This all seemed to go pretty well; testing created a new, minimal site.

Next up I wanted to deploy the Content Type and associated page layouts. Well, there wasn’t much information in his book on this – like him, I’d figured I’d write a separate Feature for deploying just the content type and page layouts – but there was very little information in his book about this. Continue reading “Deploy Publishing Pages and Content Types as a feature”

Deploy Publishing Pages and Content Types as a feature

Setting up your content types and templates…

I received a good link in one of the comments on the blog, and I thought I’d bump this up – Sensible Document and Template Management.

I’m with Mads on this – to me the killer feature of SharePoint is how it works with Offices, and template functionality is key in that. Demos of document properties, quick parts and then the list columns in Sharepoint have a very high wow-factor (rightly so – I think it’s pretty neat too!)

However, templates are something rarely used in my experience, or not use properly anyway. Often it’s seen as an unnecessary effort, and usually everyone just starts creating their own documents from blank, or deleteing the contents from an existing document and using that one, or copying and pasting across – none of which are pretty scenarios.

Then again, often the guys actually making these templates need a good course of ‘How to use Word’. No so much with Excel – I think that people accept you need a bit of training to use it – but Word seems to be an issue.

Anyway, the point is, do try and plan building templates into your project. And that there is probably a consultancy opportunity in trying to generate these…

Setting up your content types and templates…

Self Referencing Lookup columns

Came across something I’d not considered – self referencing lookup columns! I was doing some testing, and this totally caught me out (and caused my Outlook plugin to crash and die).

Basically, this is a Lookup column where the List that it is looking up onto is the same as the list where the lookup column is in use. In our case we had a list called ‘Issues’, and the lookup was a multi-choice look-up called ‘Related Issues’. It would let a user select things from the Issues list. All in all, a perfectly sensible use of a multiple lookup, and one I’d not thought of!

However, this in itself wouldn’t cause my plug-in to suffer an error. The problem was with the data I was getting back from the Web Services I’m using. I use the List Webservice‘s GetListContentType method to get information about the Content Type, and I then read the information about the fields. Lookup fields normally come through with an attribute List ; this is the list that’s being looked up onto, and normally it is a GUID. However, for self-referencing lookup instead of a GUID, you get a string ‘Self’‘. Okay, I can’t argue that it’s wrong, but it’s a smidgen annoying that it is inconsistent. Couldn’t it just give me the GUID and let me figure out if that’s the same list? Or use another attribute to denote that it’s a self-reference?

I don’t get why this was built that way.

Self Referencing Lookup columns

Document Conversion Service doesn't map column data – Part II

(For the purposes of this post, I’ll use Pages with a capital P to mean items in SharePoint of a Page content type, or a child content type of Page. I’ll also refer to all content types in italics)

Previously, I found that the document conversion service doesn’t map site column data from the Document type to the Page type. So, what are our options?

  1. Get users to fill in the metadata for the converted document
  2. Put the metadata into the Word document
  3. Bespoke coding
  4. Don’t use the conversion service

Let’s look at each in turn.

Get users to fill in the metadata for the converted document

Well, the first option is pretty obvious – get the users to fill in the Site Columns for the converted document’s Page. In my case, this would mean filling in the AWBText column on the ConvertableDocumentPage type. This will work! Unfortunately this means that the page and document’s data is not linked – a change in the AWBText field won’t be replicated between both items, or even just pushed from the ConvertableDocument the next time it’s converted. That sucks a bit, but this might be a valid option.

Put the metadata into the Word document

The second option is quite neat – Word document can have ‘Quick Parts’ – some of which are document properties, and this can be connected to the columns of the content type:

Insert a Quick part menu

You can put these into the document itself. They’re like document ‘Fields’ in Word pre-2007, but these are much, much better. For a start, you can actually type into the quickpart and it’ll update the document properties – and when you save the document to SharePoint it’ll update the columns of the library! Very cool. Anyway, I updated my Word template from my previous example…

Word document with Quickpart

I then created a new document. Note that the AWBText field in the Document Information Panel and the Quick part is linked – I typed in the value in the document and it was reflecting the Document Information Panel.

Example document for Document conversion with QuickPart

I then converted these document. This resulted in:

Converted Document - AWBText value in Page content

Okay, so I’ve scribbled on this a bit. The area outlined in the purple-pink colour is the content of our document that we converted. You can see that this includes the value of the ConvertableDocument‘s AWBText column. Hurrah! However, above this is the value of the AWBText column on the ConvertableDocumentPage – and it is still empty. In other words, the original document’s metadata is now in the page content – but it still isn’t stored against the Page as metadata. This isn’t really suitable for our customer – they need that column data against the Pages for their navigation. Bah!

Bespoke Coding

Okay, I started to wonder if I could fix this via custom code (i.e. some sort of Feature). I dug through some of the hidden properties of my source ConvertableDocument and destination ConvertableDocumentPage using SharePoint Manager. I knew that there must be some sort of connection as if you Edit the ConvertableDocumentPage is shows you that is has a source document, and lets you edit that document instead. Therefore, they must know where they came from.

In SharePointManager, I found some interesting fields. The ConvertableDocument content type I’d created had a property RcaPageID, which was a GUID. ‘Rca’ stands for ‘Rich Client Authoring’, which is what they seemed to call this page authoring technique until some decided to call it ‘Smart Client Authoring‘ instead. Certainly, internally it’s normally referred to as Rich Client Authoring, or ‘Rca’.

I then checked the ConvertableDocumentPage type, which had a property RcaSourceDocID . This was a GUID, and this ID matched the RcaPageID of the document we used to create the page. Thus, and I’m pretty sure about this, it’s the connection between the source Document and destination Page.

Therefore, I could build an event handler that (when a page is updated or created) gets the Page’s source document, sees what columns they share, and copies across the values of those shared columns. Actually, it’d probably have to exclude some (like title), but you get the idea. Also, it’d have to run a query across all the documents in the site collection, but I’m pretty sure that this is possible.

I like this solution, and think it’s a fairly straight forward, generic candidate for a feature, but unfortunately our customer is unable to make server configuration changes – like installing new features. So that rules that idea out… damn.

Don’t use the Document Conversion Service

I know, this seems a bit crazy – but you could author your content in Word and just copy and paste the content into your pages. This is what our customer was doing. I know, it seems a little crazy to me too, but if you lock down the styles available in a Word template, then the code you’ll copy will have consistent CSS styles in it, and you can prevent any inline CSS through that restriction too. It has no server footprint and no duplication of metadata – but you still have to store the documents (which might require column data too).

So those were the options I was able to come up with. I like the coding option – an event handler could be a very elegant way of dealing with this.

Document Conversion Service doesn't map column data – Part II

Take care when adding or removing columns from Site Content Types

As mentioned before the content types on a list are actually children of the site content types. I’ve also looked at adding columns to list content types, which naturally enough doesn’t affect their parent site content types. Anyway, there are issues to consider when dealing with adding and removing list content types – I suggest you refer to this post for more information.

So what about adding and removing columns from Site Content Types – are there issues with this? Well, yes, there are (unsurprisingly). If you add a new column to a Site Content Type, you have the option to ‘Update all content types inheriting from this type’

Update Child Content Types

If you select ‘no’, then the change only applies to that Site Content Type. The next time you add that site content type to a list, the new List Content Type that is created will have the new column, but pre-existing list content types that inherit from the site content type will be unchanged.

If you select ‘yes’, then the List Content Types (or other Site Content Types) that inherit from this content type will have the new column. For the List content types, this means that there will be a new column on the list. Carrying on from an earlier example, here I’ve added a new column (‘Job Title’) to the Example Travel Expenses site content type, and updated all content types inheriting from that. If we then go an look at the List Settings page, we can see our List Content Type has a new column:

Extra List Columns 2

Great! Now what happens if I remove that column from our Site Content Type? Well, again, I get the option to ‘Update all content types inheriting from this type’. If I choose no, then the existing List Content Types derived from this Site Content Type remain as they are. If I choose yes, though, I get a fairly large warning saying:

This column will be removed from all content types that are based on this type. If you are sure you want to remove this column from all content types based on this type, click OK. To remove this column from this content type only, click Cancel to close this dialog box, click No in the Update Lists and Columns section, and then click Remove.

Snappy message that:

Silly Warning Dialog

Anyway, if you click OK, that column is removed from child content types. H0wever, the column is not deleted from lists that were using those child content types. I removed the ‘Job Title’ column from my ‘Example Travel Expenses’ site content type. If we return to our list settings page, we can see that the column still exists, although it isn’t used in any content types:

Extra List Columns 3

This makes sense, as the column could actually contain data, and it could be used in multiple places throughout our sites (potentially hundreds!) However, maybe you do want to remove that column from that list, or potentially those hundreds of lists. In that case (and this is why this is important) you have to delete the ‘orphan’ column on a list by list basis. Therefore, if your content type was used in hundreds of lists, you will have to delete this extra column hundreds of times, once for each list.

Therefore, be very careful when adding or removing columns from a Site Content Type – make sure that you really want to add it (as removing it might be hard), and be aware that removing the column is not the same as deleting it in the lists that use it already.

Take care when adding or removing columns from Site Content Types

Content Types – Who's your daddy?

Content Types are great, but can cause a little confusion. Because you normally define a content type at a site level, that’s pretty much how we think of them – as centrally defined types of item. Often, we actually create these content types on the root site of a site collection, because all subsites will be able to use them then.

However, this isn’t really the case. We do have site content types – but we also have list content types. These are the content types that are actually used on the lists themselves, and they are children of those site content types. This can be most easily seen by clicking on a content type on the List Settings page.

List Content Type

Notice that our ‘Example Travel Expenses’ content type says it has a parent of… …’Example Travel Expenses’! This is our List Content Type telling us that it’s parent is the Site Content Type of the same name. Click on it, and it’ll take you to the Site content type description, and you can work on up the chain of content types until you reach Item.

Site Content type

A consequence of this is that, as our content types are actually used by lists, I can’t think of a way to use a Site Content Type directly (though I may be wrong about that).

That are also issues related to this in terms of modifying content types, but that’s the subject for another post…

Content Types – Who's your daddy?

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?