| Article Index |
|---|
| Frode's awesome list of Sharepoint Column Field ID's |
| Columns A through E |
| Columns F through P |
| Columns Q through Z |
| Conclusion |
| All Pages |
I'm working on a clients intranet redesign project and we're making our own content types. Everything was nice and peachy, until I tried to make a redirect page based on the original page layout and have it work with one of our new content types. For some reason I couldn't get the redirect form to display properly. After some digging around, I noticed that when I made a redirect page with the original content type it had a field that my new content type lacked. RedirectURL.
No problem! Let's just add that field to my custom content ID, and we'll be laughing 'till the cows come home. Or better yet! Let's make a custom content type just for the redirect page! Now let me just update this ContentTypes.xml and add a content type with the Field ID of RedirectURL and I can call it a day. Let's see... What could that ID be I wonder...
To make a long and boring story short, finding the ID took quite a bit of searching on Google. Eventually here's what I ended up with;
<ContentType ID="0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900[...]" Name="ClientXZY Intranet Redirect Page" Description="This content type defines the fields used for redirecting pages." Group="ClientXZY Intranet" Sealed="FALSE" Version="0" Hidden="FALSE"> <FieldRefs> <FieldRef ID="{AC57186E-E90B-4711-A038-B6C6A62A57DC}" Name="ClientIntranetRedirectPage"/> </FieldRefs> <DocumentTemplate TargetName="/_layouts/CreatePage.aspx" /> </ContentType>
Now I figured, there's gotta be an easier way of finding the Field ID's than looking around on Google. And there sure is. With a little help from my best friend Powershell, I connected to our dev server and compiled a neat list of all available Field IDs on our standard installation.
Update: Seems that this page has been unavailable since late March. I apologize for this. I'm not sure why this happened, but I suspect it's caused by a bug in my CMS. I've split this into several pages now and hopefully that will help mend the issue. I've kept the original table on the HTML pages, but I suggest you download the .csv or .xls files instead. They're easier to scan through than this article is.
Disclaimer: This may or may not be a complete list.





But it should really be your last option!
Often in the API you have classes to handle these field names, such as Microsoft.SharePoint.Publishing.FieldId and Microsoft.Office.Server.UserProfiles.PropertyConstants etc