I am happy to release Calendar CQWP for MOSS for use when trying to roll-up calendars or re-use calendars within a site collection. In essence, I created a view for the default content query web part that is relevant for calendars – it presents events by start date, title, and description. The content query web part (CQWP) is central to SharePoint’s content re-use story.
In fact, when building modern digital marketing web sites on SharePoint, like HedKandi.com, content query web parts let authors manage content centrally while re-using content in multiple locations. Unfortunately, the out of the box styles aren’t useful outside of the document management use case – so light customization is often required. While customizing content query web parts is more difficult than setting up content types – it’s within reach even if you have no coding or branding experience.
Working with content query web parts has three distinct parts: building the query, communicating query results, and presenting the results. The content query web part is made up of an XML .webpart file that handles building the query and communicating the results. Presenting the results is handled by a style sheet (the default style sheet can be found at [site collection root]/Style%20Library/XSL%20Style%20Sheets/ItemStyle.xsl).
While the governing MSDN content is great for details, I thought I’d walk through the basic approach I used for the Calendar CQWP. It is important to note that content query web part functionality is dependent on the Site Collection feature “SharePoint Server Publishing Infrastructure”.
Building the Query
Building a query is configured through the browser by “Modifying Shared Web Part” properties for the content query web part. When site columns are used in multiple content types or exist in multiple categories, managing filters and grouping and sorting settings can get challenging. In addition, complexity increases if a site column is renamed. An easy way to identify how a field is referenced is to edit the respective column in the document library and look at the URL for the value of “Field”. When all else fails, create your own custom columns and custom content types (Good information architecture trumps all).
Communicating Query Results
Most fields that will be used in presentation need to be explicitly defined (by default Title, ImageUrl, and LinkUrl fields will render). In order to define the fields, export a content query web part to your desktop and modify it in notepad. Fields are defined in the “CommonViewFields” property. In addition, you can define the governing XSL (so you don’t have to modify the default style sheet) by using the “ItemXslLink” property. After you’ve made the required changes you’ll need to import the updated web part for use.
For reference, below are snippets from the Calendar CQWP:
<property name=”CommonViewFields” type=”string”>EventDate;Description</property>
<property name=”ItemXslLink” type=”string”>/sites/avisuj-team/Style Library/XSL Style Sheets/calendar.xsl</property>
Presenting the Results
This is controlled by the XSL file governing the Content Query Web Part. I typically start by copying a template that best matches what I am trying to achieve. Most often, I modify the html that follows variable declaration. Fields defined by the “CommonViewFields” property can be reference by @FieldName even if they are not defined as a variable. Common HTML rules apply.
In summary, you don’t need to be a coder to create your own content query web parts. Making your own web parts will make it easy to re-use and aggregate content throughout a SharePoint site collection. In addition, this skill becomes critical when you start using SharePoint as Web Content Management engine.