SharePoint Custom List template missing

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="" 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)

Site Feature – Include Custom Icon (GIF)

When creating custom SharePoint webparts using features, the ICON to show within the Site Collection Feature page is often forgotten, or developers just don’t bother with it – and leave it as the default one.

The following shows some “Out Of The Box” icons – and the Telerik icon – with the little green pencil on the right-hand side.


If you want to include a custom icon – here’s how to do it – very simple !

(1) Create an image to use

  • The image that will be included is best to be 31 x 21 in size.
  • Here’s some example ones, that you can take & use if you want – or simply create your own.


(2) Include the image in the solution

  • Within your Visual Studio project (using WSPBuilder, of course !), you will need to create an IMAGES folder
  • This is then copied into the 12 hive, when the feature is deployed.


(3) Add to FEATURE.XML file

  • Just need to add the “ImageUrl” property in the FEATURE.XML


(4) Build & deploy the WSP

That’s all that’s needed !!

You should now have a custom logo/icon when you view the features within “Site Features” – or “Site Collection Features” (as shown below)


Easy, eh ?   A quick way to differentiate your features from the OOTB ones – or to identify your company within the big list of features.



While awaiting the new Visual Studio 2010 product, and the big increase in developer support, the BEST way to create development projects is using Visual Studio extensions for SharePoint.

This gives you a swag of project templates, and easy debugging (just click F5) – and easy packaging and deployment – essentially a MUST-HAVE for any SharePoint coder – eg. webparts, event handlers, etc

There’s a new version been released as a “CTP” – basically a beta (or does that mean it pre-beta ?)

The Visual Studio extensions for SharePoint (VSeWSS) provide project templates for developers using Visual Studio 2008 to create, debug, package and deploy SharePoint projects including Web Parts, Data Lists, Content Types, Event Receivers, Templates, Modules and other SharePoint artifacts.

The v1.3 release is an incremental release of the VSeWSS including top feature requests. It is an interim release for SharePoint Developers on the roadmap until Visual Studio 2010 is released with significantly improved SharePoint development tools as outlined here.

And – has support for 64-bit, for those using SharePoint on Windows Server x64.

Will be great to check out some of the updates and new features – and was in need of support for x64 – and VS-2008.

Read the full “announcement” here (lots more info) : Microsoft SharePoint Team Blog

Restricting access to “All Site Content”

When viewing an SharePoint intranet site, there will be a bunch of WebParts, documents, links, etc – with user security applied, allowing for various levels of access – such as contributor, read-only, full control, etc.

On the top left of any SharePoint intranet portal will be a link to “View All Site Content” – above the navigation that has been configured for the site.


Recently, had a client that wanted to remove/hide this link, which would restrict certain users from being able to view the list of “libraries” within the site. 

The particular users can’t actually create new lists or libraries, but the client wanted the navigation for the site to be the only way for folk to get about – and not poke into “what’s there” – by viewing All Site Content.

Fair enough – that’s what they want !

To achieve this, the approach we took was to include some “security trimming” – meaning that certain users would not see this link – while other users (Admin) could view all site content.

Yes – I’m aware that users could simply enter the URL into the address bar – but it’s something that the general “click this and see what happens” user will not be aware of – and won’t go poking around.

The trick is to do the following :

(1) add the SPSecurityTrimmedControl tag around the elements that you want to restrict

(2) specify the particular permission-set that you want to allow to see the control/s

Note that this is added to the Master Page – and only needs to be included ONCE – not like it’s needed in each and every Page Layout.

For default.master, this is included as “ViewFormPages” – this is will be changed to “ManageWeb” – meaning that lesser level users won’t be able to see the link.

<Sharepoint:SPSecurityTrimmedControl runat=”server” PermissionsString=”ManageWeb“>

—-> tags/controls that you only want visible to folk who can “view form pages” <—-


So – the HTML/ASPX page will look like this (with the security trimming around the “SPLinkButton” – which is used for View All Site Content) :

<Sharepoint:SPSecurityTrimmedControl runat=”server” PermissionsString=”ManageWeb“>

<div class=”ms-quicklaunchheader”>

<SharePoint:SPLinkButton id=”idNavLinkViewAll” runat=”server” NavigateUrl=”~site/_layouts/viewlsts.aspx” Text=”<%$Resources:wss,quiklnch_allcontent%>” AccessKey=”<%$Resources:wss,quiklnch_allcontent_AK%>”/>



Click here to see a list of all the possible “PermissionStrings”.

After changing and updating (uploading) the new Master Page, the end result is that the link will not be shown for users who do not have “ManageWeb” permissions.

Saving Word Document in SharePoint shows blank metadata screen

Was recently investigating a problem with SharePoint 2007 (MOSS) – when saving “new” documents in a document library.   This is only a problem when using Word 2003 – relating to the completion of “meta data” (required fields).

The simple run-down of the problem is as follows :

  • Click to create a NEW Word Document
  • Using dropdown menu in SharePoint doc lib


  • Enter words/text – eg. hello world !
  • Click “Save As”
  • Enter a file name – to be saved within the document library (SharePoint)


…and here’s the problem – the next screen displays the “meta data” values to be entered.  

But – the screen is BLANK (WTF ?)   


There should be a drop down to select the content type – as well as a bunch of meta data fields.  

So – can’t save the document, as the required fields aren’t filled in.

A further quirk – this only happens when using multiple content types.   If only one content type – then all is fine.

Also – the server has been re-formatted, re-installed, etc – SharePoint environment re-built – and the problem is *STILL* happening !

NOTE – when saving from Word 2007, the document information panel is used instead – there’s a message box shown, prompting the user to enter the required metadata.




So – how to fix this ??!?

  • Use FIDDLER to determine the page url being shown – within the dialog box from Microsoft Word.
  • Note that this is an output from “OWSSVR.DLL”


  • Copy the URL, and view within Internet Explorer.
  • Can now use IE Dev Toolbar – to view the HTML, CSS and so forth.  
  • By selecting turn off “CSS”, I can see that the fields are actually there – just “hidden”

Next steps were to do some debugging (this was via Microsoft support)

  • Determine where (within JS code) the field/s are being hidden
  • Check the “IF” condition, and values


It turns out that there’s an expected field called fReadOnly – and the value is “missing” – should be either TRUE or FALSE. 

This then throws off the JavaScript (bform.js) – and the fields remain as “display:none”.   This is NOT a problem with ONE content type, as the fields are always displayed, not conditional (depending which content type chosen / refresh)

After some more poking & investigating, we determined that the “SCHEMA.XML” file buried within the SharePoint 12 Hive had been changed. 

The folder contains a “SCHEMA.XML” and also “ORIGINAL_SCHEMA.XML”.

For some reason, the “field” for fReadOnly had been removed.   And so, the JavaScript couldn’t determine the value/logic – meaning that the HTML wasn’t outputting correctly (always hidden).

So – why was the SCHEMA.XML file changed ?   What’s different ?   

After some wondering, blame-storming, and hair pulling – it ended up that the reason the SCHEMA.XML file had been modified was due to a 3rd-party add-on being installed.

The Outlook PowerTool (Echo Technology) is a free add-on that adds some extra checkboxes and options to the context menu’s within a Document Library. 

SharePoint delivers plenty of functionality out of the box that enhances the collaboration experience.

The ability to Send Links of documents directly from the interface is now provided out of the box.

However, this functionality is limited to only one file at a time.

This FREE tool from echoTechnology will allow you to select multiple documents from your document library send links and document attachments via your default browser.

Very cool – I’ve used it previously for a SharePoint 2003 installation – and it’s FREE – and very functional.   But, probably no support, as it’s FREE.

BUT – and this is what’s caused a few days of tail-chasing – the installation includes a JavaScript (JS) file – and a new SCHEMA.XML file.

The instructions for installation mention to replace the existing SCHEMA.XML file contained in this folder :

C:Program FilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATEFEATURESDocumentLibraryDocLib

And – as the MythBusters would say – “well THERE’s your problem !!”

To be fair, I haven’t checked to see if there’s an updated version (yet) – or if it’s a KNOWN issue when using Word-2003 – but, the resolution was to re-instate the old file – which means meta-data can be entered.

Luckily, was just a rename of XML files, and IISRESET.

Unfortunately, this means that some of the functionality for the Outlook PowerTool doesn’t work as expected – will have to see if we can piece together a correct SCHEMA.XML file – and/or contact Echo to see if this is a known issue.

Took a lot of fiddling (pun intended) – and some JavaScript debugging to work out the problem !  

Hopefully that helps someone out there – with a similar problem…


Successful SharePoint projects ?

Found an interesting and thought-provoking article from

Why are SharePoint projects difficult to deliver?

There are many reasons why SharePoint related projects run into difficulty and like any other IT project, they fall under the following headlines well documented by others:

  • Poor Scope Definition
  • No inherent Project Culture within the business
  • Poor Stakeholder Management
  • Poor Project Governance
  • Poor Project Management skills
  • Weak Planning (for the project and beyond once it has been deployed)
  • Lack of proper change and risk identification and management.

However, there are other reasons that organisations need to be aware of – ie. specific to SharePoint.

Read the full article here.