Limitation of Content Query Web Part (CQWP)

One of the most powerful web parts since SharePoint 2007 is the Content Query Web Part but it has some strange limitations. To be more specific not the web part has the limitation it seems more that SharePoint has, from my point of view, a big architectural failure. Let me explain why.

The mission

I wanted to create a Content Query Web Part (CQWP) that displays the content types “Events” and “Article Page” that was changed in my portal. This seams on first hand to be an easy task to accomplish. A well-known mechanism for this is to overwrite certain properties of the default content query web part. This can be done by simply exporting a default configured content query web part.

Glyn Clough has a good article about how this can be done. For more information it’s recommended to check out his blog post: CQWP #2: Aggregating items with multiple content types. Another recommended resource for this is How we did it: – Part 5: Mavention RSS by Waldek Mastykarz.

The task that needs to be done is writing a CAML Query, which is straight forward task, and using the <QueryOverride> property in the web part configuration. The Query for this will look like this:

If you want it in a more user friendly way the Content Query could also look like this:


The only difference between those two queries is that the first uses the ContentTypeId field, which requires the GUID of the Content Type to filter and the other use Content Type Field by using the display name of the Content Type. By filtering those fields with BeginsWith in case of Content Type ID will also include all child content types. Never the less both queries are from a syntactical point of view correct and should work.

To add this query to the web part it’s recommended to make it single lined an wrap it in a <![CDATA[<Where> …. </OrderBy>]]>. This helps a lot because otherwise all < and > brackets needs to be replaced with &lt; and &gt;.

All the configuration work is done so far for this first test. When the web part is placed on the page then it won’t return any result on first hand, because it needs to be configured first. In the query option of the web part indicates that the custom query is used for this web part, which is the one we entered in the web part xml.

Web part with QueryOverride Property Set

Web part with QueryOverride Property Set

I applied the default settings and what I got was a web part with no results but how can this be? In my test I let the list type to default settings which is “Page Library”. The expected behaviour would be that SharePoint will return a least all pages in my site collection. In the ULS Log the query can be found that SharePoint will execute against the database. No exception happened on this query but also no result was returned.

Content Query with no result

Content Query with no result

Next I changed the list type to calendar and the events were returned correct, but the article pages were still missing. Both were valid queries but how can it be that the query against the page library return no result and the other query returns a result? So is this a bug or by design? I will provide my answer to that a bit later.

Content Query Result with Events returned

Content Query Result with Events returned

Digging in the documentation I found a really useful article call How to: Customize the SharePoint Content By Query Web Part by Using Custom Properties (ECM). In the List Override section there are several examples that can be used to override the list behaviour on the content query web part. I also found the following xml snippet for base list type:

The name of this base type indicates that the real base type for all lists will be used. So I edited the web part again but now I modified the ListOverride property. I used the same procedure as before and imported the web part into SharePoint, edited the web part and used “Pages Library” as list template and I got events right away. The good news is that the ListsOverride work quite well, the setting of the web part, which is Pages Library, was overwritten. It works but won’t return the right result. I also checked the CAML query in the ULS Log and this truly uses the defined property.

The list types that can be used to override by the following values:

0 – Custom List (General List Type)
1 – Document Library
2 – Not used
3 – Obsolete. Use 0 for discussion boards.
4 – Surveys
5 – Issues List

Those values can be also found in the documentation:
It seems to be that this mission cannot be accomplished. No matter what you try. I spend a couple of days on this; getting different content types in a single query won’t work. I also did some testing with a coded web part using the same mechanism but this won’t work also. Some tries ended in HResult exception. At the end I don’t believe this behaviour is not a bug. I think it is more an architectural issue or limitation.

I want to give another example where this behaviour is annoying too. Imagine for example a project site where you want track project tasks and issues in a single content query web part. This also cannot be done because the list types for both content types are different. A SharePoint Task list use a custom / generic list type (Base Type 0) and an Issue Tracking List is based on Issues List Type (Base Type 5). Both List types cannot be queried in a single content query, because these content types use different list types.


Content Query Web Part is the most powerful weapon in SharePoint for aggregating content in SharePoint. You can query different Content Types but you need to make sure that the list types in your query match all content types and cannot be mixed. List Types was first introduced in SharePoint 2003 and since then there was not much architectural change. This problems / behaviours are strange anyway. It could be that Microsoft did this for performance optimization of content queries but I think a single query against the database will be much faster than to have different web parts run single queries to the database.

What I would like to see in the future of SharePoint is that the different list type will inherit from a generic list type. I think this could solve the problem with the queries and adds more flexibility to SharePoint.

Beside the problem with the content query I will also have the same base functionality on every list or document library. Currently generic lists don’t support major and minor versioning but a document library does. I find this a bit strange too.