Working on a project recently, we’re provisioning about 15 list templates as part of our SharePoint publishing solution. There had been a mix-up with the “Type” Id used for the ListTemplates within the XML definition – can you spot a mistake ?
<List xmlns="http://schemas.microsoft.com/sharepoint/" BaseType="0" DefaultItemOpen="0" Direction="none" DisableAttachments="False" DraftVersionVisibility="0" EnableContentTypes="True" FolderCreation="True" Name="Comments" OrderedList="False" QuickLaunchUrl="False" Title="Comments" Type="113" VersioningEnabled="False" Url="Lists/Comments" Id="e3183ba9-0b61-42dd-8ff8-f12eb3bc2d62">
We had inadvertently ‘overwritten’ some of the OOTB SharePoint list templates. Not actually written over the files on disk, but hi-jacking the Types – from 100, 101, 102 – up to 115 – and we had a multitude of problems.
One of the worst culprits had a symptom of the “Add Web Part page” being empty – none of our custom webparts were listed.
And it turned out we had a List Template with the same TypeId as the “Web Part Gallery” – yikes.
This post details all the SharePoint base List Type Id’s – and made us realise what we needed to fix – the lesson is “avoid these numbers”.
We’d eradicated most of our problems by changing the TypeId’s in the feature.xml – starting at 1000, and deleting / re-activating, etc – but one problem remained.
Within the ‘Create List’ page, there is no “CUSTOM LIST” shown. This is kinda bad don’t you think !?
Has document libraries, etc – just not the normal “title only” custom list. Dammit.
We found a way to ‘bring it back’ – from a look at another dev machine, which HAS the Custom List.
When hovering over the list template :
Have a look at the URL :
The FeatureId corresponds to the list template that can be found in the following directory :
C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12TEMPLATEFEATURESCustomListFeature.xml
And – if we look at the Element Manifest :
You can see – there’s the Type=100 list, and whoops – we’d overwritten it.
So – because it’s actually just a feature, we just thought “I wonder if we could just re-activate it ??!”
Here’s the command we tried :
stsadm -o activatefeature -id 00BFEA71-DE22-43B2-A848-C05709900100 -url http://servername –force
And yep – the custom list is back ! *phew*
Hopefully that’s a useful tip for some folk.
Of course, the best option is NOT to have ListTemplate’s with overlapping Type’s (with SharePoint OOTB ones).
🙂
I was using a codeplex tool (SPSource) to generate the feature/s – this was acknowledged as a bug, and is to be fixed in the next release (soon)
