tips & tricks

  • Inconvenient Content Query Web Part and provisioning it to the right place

    Content Query Web Part is one of the most frequently used Web Parts available out of the box with SharePoint Server 2010. Thanks to its flexibility, great performance and rich configuration possibilities it’s a great solution for aggregating content. Because the presentation layer of the CQWP is based on XSLT, the possibilities are virtually unlimited, but as soon as you start using custom XSLT stylesheets some strange things start to happen.

  • Inconvenient User Tasks Web Part and how to make it display all tasks

    The out of the box available User Tasks Web Part allows you to show tasks assigned to the current user. This Web Part is a great building block for end users since it doesn’t require any configuration whatsoever. All you have to do is to add it to a page and it will automatically display all tasks assigned to the current user. Unfortunately by default the User Tasks Web Part displays only tasks assigned to the current user located in tasks lists in the current Site.

  • View installed Site Definitions using PowerShell

    A while ago I wrote about a little tool I’ve made that help you discover the ID’s of all Site Definitions installed on the server. SharePoint requires you to provide unique ID’s for custom Site Definitions and using a tool is definitely easier than manually browsing through all the WebTemp files and noting which ID’s are already used. But who wants a tool if you can do the same with PowerShell?

  • Inconvenient Content Query Web Part and server-relative URLs

    Content Query Web Part is probably the best solution for creating dynamic content rollups in SharePoint 2010. It’s lightning fast and because it’s using XSLT it allows you to easily change layout without touching your data. And although changing the presentation in Content Query Web Part is a matter of a few mouse clicks, it gets quite inconvenient when you start using custom XSLT files.