Imagine the following scenario: you created a new Content Type in SharePoint 2010. You built the Content Type ID correctly.aspx) and even included the FieldRefs element. Still, after you provisioned your Content Type it doesn’t contain any fields:

Right after I posted my last article on using Page Layouts for dynamic body ids and issues that you stumble on, I got one more idea on how you might leverage Page Layouts for setting dynamic body ids and still deliver a great performing solution.

If you’re working with SharePoint 2010 solutions that deploy assemblies to BIN the right way (with CAS policies that is), you might have noticed that an error occurs during the deployment of the WSP to SharePoint with the new Visual Studio 2010 SharePoint Developer Tools.

While creating custom branding for SharePoint it is not only important that it looks all right, but also that it’s fully functional and that users don’t loose any of the standard functionality provided with the platform. While most elements can be easily positioned within Master Page and Page Layout some are positioned more “indirectly”. Knowing how SharePoint does the positioning can help you deliver a great User Experience.

A few weeks ago I presented you a solution for creating dynamic layouts with nothing more than some CSS definitions and a dynamic body id. Using exactly the same HTML markup you can create a different layout of your page elements what makes it an extremely efficient and easy to maintain solution. While the concept is pretty straight-forward, applying it in practice to a real-life SharePoint Server Web Content Management solution has one drawback that you should keep in mind.