In one of my latest projects I was faced with the need to hide the OOTB Title column in a custom SharePoint list. Initially I thought this would be an easy job to be done within 2-3 minutes but it turned out I was wrong. I read several articles on the web, including a couple of discussions in MSDN forums dedicated to the exact same topic, but honestly none of the suggestions worked for me. Finally, I managed to find a working solution that I am glad to share with you, hoping it could be of help should you need to accomplish the same task.
The completed solution will provision a SharePoint list with a custom content type that has three fields and the Title column is hidden. For the sake of brevity I will highlight only the key artifacts comprising the sample, omitting details like the creation of custom fields and the deployment of a custom list with a feature.
Recently, we encountered an interesting and quite unexpected issue while working on a publishing site based on SharePoint 2013. Let me share some details on that particular scenario and a simple workaround in case you come to struggle with the same problem.
A client of ours has a large number of pictures that they use when authoring content for a publishing site. They store the images in the Site Collection Images library. To make it easier to classify the images and simplify the work of content authors, they added a Managed Metadata field named Category to the library. This works pretty well since a new feature in SharePoint 2013 now allows to conveniently sort and filter by taxonomy fields in the list view:
We continue our series of useful tips and common development scenarios for SharePoint Managed Metadata with an article that shows how to declaratively provision a taxonomy field and how to connect it with an existing term set. It’s a follow up of Programmatically Import Term Set into Managed Metadata Term Store where we explained in details how to import a term set into the Managed Metadata term store.
The current sample uses the Company Enterprise Industry Taxonomy term set that we created in the previous post, so today we will not spend time explaining how to create a term set.
Define Taxonomy Fields in CAML
The creation of a field definition of the taxonomy type in SharePoint is a bit different than that of other field types. The main difference is that we actually need two fields – one field is assigned type TaxonomyFieldType and the other is of type Note.
Recently in one of our projects we had to write some code to get items from a list in SharePoint 2013 using CAML. “Easy Peasy Lemon Squeezy” … I hear you say. It should be quite trivial especially given the fact that CAML has been around since SharePoint Team Services – the very first version of the platform.
Well, not so fast. If my experience as a SharePoint consultant has taught me anything, it is that even the most seemingly trivial task in SharePoint can kill you a couple of hours. That is – if you are lucky.
So let’s see where the catch is in querying Boolean fields with CAML.
This post is a sequel to the article Deploying Publishing Page Layouts and Pages Using Features in which we examined the step-by-step process of deploying publishing pages based on a page layout using SharePoint features. As we saw, apart from a few caveats, that approach was quite straightforward and beneficial, allowing us to easily move a solution between environments.
However, the previous solution had one disadvantage – the page layout and the publishing page itself were deployed within the same feature. While this works for our small sample, it is not the cleanest approach for a real-life project.
In an end-user solution it is better to package page layouts in one feature and publishing pages in another. This way we are able to deploy content separately to development or QA environments for testing purposes and a clean solution without content to production.
In the end we would like to re-structure the solution to look like this: