Martin Hatch – SharePoint Evangelist

Sigh .. another few days of RTM development and another bug found …

This one regards the Content by Query Web Part (CQWP) and the new PageQueryString filter functionality. This is a cracking new feature which allows you to dynamically set the filter based on a query string value in the request URL… unfortunately there is a bug.

I found this when I was trying to set an aggregation of some News pages, but filter them using a query string as a poor-man’s web part connection 🙂

My Requirement: Show all custom “News” pages within the pages library of my News site, and filter the date using a query string value.

Normally this would involve custom development, but not any more in SharePoint 2010!

1. I targetted my CQWP at the Pages Library (no point querying the entire site, as it would be a performance hit).
2. I also targetted the CQWP at my custom “News Page” content type, as I didn’t want the “home” page to be returned in the aggregation
3. Finally, I added a Filter of “Article Date” is Greater Than [PageQueryString: StartDate], so that I can start to filter my news by date using the query string.

I hit the “apply” button with sweaty palms .. excited to see this new functionality in action ..

There is a problem with the query that this Web Part is issuing. Check the configuration of this Web Part and try again.

FAIL

What Went Wrong?
This was quite a shock .. I checked and double checked that my filters were setup correctly.. I spent an entire day checking and double checking all of my settings and values to make sure I hadn’t made a mistake somwhere. If I removed that filter then it worked (and returned all my news items). Bizarelly if I included a valid query string like ?Title=Home in my URL then it WORKED?? But remove the filter completely and it failed …

So What EXACTLY doesn’t work ??
I spent a good few hours investigating this in more detail, and came across the following findings. If you have the following ALL set in your CQWP then it will fail:

• Targetting a Specific List, and
• Targetting a specific Content Type, and
• Any [PageQueryString] filter in your query, and
• The [PageQueryString] variable is NOT present in the URL

If you change any one of these settings then it will start working!

How To Replicate This Bug
This is quite simple really, just follow these steps:

1. Create a new “Publishing Site” site collection
2. On the home page, add a new Content By Query Web Part
3. Set the following query properties
• Show items from the following list: /Pages
• Show items of this content type group: Publishing Content Types
• Show items of this content type: Page
• Show items when: Title > Contains > [PageQueryString: title]
4. Hit Apply. The web part will report: There is a problem with the query that this Web Part is issuing. Check the configuration of this Web Part and try again. If you add ?Title=Home to the query string then you should notice that the web part appears to work, but fails if the query string property is missing!

What is the Workaround?

If you then do ANY of the following, it will work:

• Point it at a Site, or Site Collection, instead of a specific list, or
• Do not filter by Content Type, or
• Do not use a [PageQueryString] filter

Now … for my example (bring up pages using a specific page layouts from a pages library) I chose to change the query to target the site. I don’t have a lot of other content in my News site, so it won’t be much of a problem.

I can imagine this cropping up again and again in the future though, especially with large Intranet sites with thousands (or even millions?) of documents … you don’t want to be doing site-wide queries there, the performance impact would be significant!!

Update:
Glyn Clough has come up with a workaround. It seems that adding an additional filter that is always true (such as Title != “”) makes it work. Annoying, but at least there is a workaround.