While I was testing building some mashups using SharePoint 2010, Web Parts and SharePoint Designer I found an interesting bug.
Here’s what I did; I set up a Wiki Content Page (the new kind of Web Part Pages) in SharePoint 2010 that was supposed to be called with Query String parameter named ID which should be used by a Web Part. Another page contained items linking to this page using different integer values for the ID query string parameter like this:
My wiki pages was located in the Site Pages library within a Team site and when I clicked on one of the items I did not end up on my landing page (
Item.aspx in the sample above). Instead I ended up on random other pages in the library or received an
SPException that the item did not exist. It took me a minute before I realized what really happened.
I was redirected to the item (page) in the library that had the Id of passed query string parameter. Strange! I did the same test but used a standard Web Part Page and then it worked as intended.
So I did a new test by creating a new Team Site. On the home page of the site
/SitePages/Home.aspx I added a Web Part displaying just the Shared Documents library. This page has the Id=1. A second page is automatically created when you create the site, the How to use this library page, with an Id=2.
If I pass this request
/SitePages/Home.aspx?ID=2 then I get the content of page 2 and vice versa. The strange is though if I call
/SitePages/How%20To%20Use%20This%20Library.aspx?ID=1 I expected to see the contents of
Home.aspx including the Web Part I added, which I did except for that the Web Part on that page was not present.
I opened up the Developer Dashboard which verified what I saw. When I called the
/SitePages/Home.aspx?ID=2 I saw the contents of page #2 but It loaded the Web Parts from page #1. The image to the right proves that it added the Web Part to the page.
When passing the ID as a query string the Wiki Pages uses the Wiki content from the page with that ID provided in the Query String but uses the Web Parts from the page in the URL.
This certainly must be a bug…