I'm upgrading an existing 2010 Custom Field Type to work with 2013. Where possible I'm attempting to re-use code from the 2010 version, to avoid duplicate work.

The main problem I'm coming across appears to be a couple of either misunderstandings or bugs with the List View rendering in 2013:


The existing XSL stylesheet (from 2010) appears to be entirely ignored (both header and Text_body modes). When I manually move it from the 14 folder to 15 it's processed (I know this because an error is thrown if it's invalid), but still not used.

I've attempted to use this with both CAMLRendering set to TRUE and FALSE.


When using CAMLRendering TRUE, the DisplayPattern for the body is used in most instances, but appears to be ignored when viewing anything after the first page.

I've confirmed this by viewing the inplview.aspx calls: On the first page the response array contains the CAML-output values as expected, but on the second they're empty strings.

General info

  • The actual field's data is empty, as the values are generated b the CAML/XSL.
  • The CFT is an actual working product on both 2007 and 2010, using CAML and XSL respectively.
  • Using SPField.JSLink isn't currently an option, due to internal constraints.

Are there any workarounds to these problems? Are these known issues/bugs? I know this is really two questions, but they're closely bound to one another.

NB: This is a cross-post from MSDN: Problems with Custom Field Type list view rendering

I'd rather get the answer here, but I'm hoping one of the MS folks will offer something useful over there. If one is answered in one place I'll add it into the other too.

  • I think that we will have a lot of issues with new rendering templates. I also have an issue with default SharePoint fields, I found out that this issue is related to JS rendering templates (they have bugs), now I write a post how to fix it. I hope that you'll find solution soon.
    – Alexander
    Dec 7, 2012 at 18:03
  • Stuart if you are at spsuk then I will look out for you and we can have a talk about solving this. Sure if enough of us take a look we can work out what's going wrong.
    – Hugh Wood
    Dec 7, 2012 at 18:59
  • @Alexander: All through the 2010 and now 2013 I just keep seeing new layers added over the top of old code. There seems to be no rework, just extra pages or another layer of JS to workaround the old problems. Reading the decompiled assemblies is like watching more and more water slowly circle the same SPRequest plughole.
    – Stu Pegg
    Dec 7, 2012 at 23:06
  • @HughWood: I'm afraid I'm not going to SPSUK. Unfortunately it seems like the only answer is going to be a rewrite so we can use the SPField.JSLink method. I can only dream that maybe 2016 will break the chain and have backwards compatible CFT rendering support.
    – Stu Pegg
    Dec 7, 2012 at 23:09
  • 1
    I did ask the question, but there wasn't knowledge of this sorry. Your solution is probably the only way now.
    – Hugh Wood
    Dec 9, 2012 at 18:38

2 Answers 2


The CAML issue with paging appears to be related to the SPField.JSLink being defined:

When it is defined, the CAML output is correct (but HTML encoded by default, e.g. < becomes &lt;).

When it isn't defined, only the first page receives the CAML output (unencoded).

Given the lack of response from MS on MSDN, I'm guessing this is a case of the Custom Field Type rendering not being backwards compatible again. :/ Oh well.


Custom Fields working with SP 2010 can easily be used with SharePoint 2013, although it is poorly documented. It took me some time to figure out.

All you need to change in your code is SharePoint DLL references: version 12 => 14.

Regarding CAMLRendering; Most likely you shouldn't enable it - it is used for Header Render Patterns only.


1) In SP 2013, create a new list and add your Custom Fields. Agreed, they currently don't render as expected.

2) Browse to your list - you should see the List View Web Part.

3) Set the page in edit mode

4) Open the WebPart properties panel for your List View WebPart

5) Expand "Miscellaneous" and check "Server render".

6) Click OK and reload the page

That's it - now the List View will use your XSL to render the display value.

This is equivalent to the following change in your XML definition for your view (usually defined in AllItems.aspx):

<WebPartPages:XsltListViewWebPart runat="server" ..... ServerRender="True" ... >

The attribute can also be modified through code: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webpartpages.xsltlistviewwebpart.serverrender.aspx


Create a new item - you will see the Web Part used for displaying, creating and editing items.

1) Set the page in edit mode

2) Open the WebPart properties panel for your Create Item Web Part

3) Expand "Miscellaneous", find "CSR Render Mode" and select "Server Render (ServerRender)"

4) Click OK and reload the page

That's it - your Custom Field is now rendered as expected when adding new items.

NOTICE: You'll have to do the exact same thing for all pages modifying or displaying your items - usually: DispForm.aspx, EditForm.aspx, NewForm.aspx. They use the same WebPart but in different control modes.

This is equivalent to the following change in your XML definition for your view/create/edit pages (usually defined in DispForm.aspx, EditForm.aspx, NewForm.aspx, as mentioned above):

<WebPartPages:ListFormWebPart runat="server" __MarkupType="xmlmarkup" WebPart="true" __WebPartId="{98AD2213-2FDA-4AD1-9AF8-7545F66257C3}" >
<WebPart xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/WebPart/v2">
  <ControlMode xmlns="http://schemas.microsoft.com/WebPart/v2/ListForm">New</ControlMode>
  <CSRRenderMode xmlns="http://schemas.microsoft.com/WebPart/v2/ListForm">ServerRender</CSRRenderMode>

The attribute can also be modified through code: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webpartpages.listformwebpart.csrrendermode.aspx

  • Ouch. That's a pretty harsh workaround. Unfortunately it isn't an option to edit the rendering method of every list view web part in many instances; including ours (we're a third party product vendor).
    – Stu Pegg
    Jan 9, 2013 at 11:16
  • Additionally, the CAMLRendering attribute doesn't alter 2013's HeaderPattern usage: The CAML HeaderPattern is never used under any circumstance that I know of in 2013. I've only seen it used in 2007, or 2010 with sites/lists imported from 2007.
    – Stu Pegg
    Jan 9, 2013 at 11:18
  • Sorry, don't think there is any other way. I wouldn't expect the List WebParts being able to handle multiple controls in different render modes. Jan 9, 2013 at 11:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.