existentia

I was never really convinced by Pownce when it was launched last year. I was signed up for awhile but it arrived a bit late to the social networking party and I don’t think it really knew what it wanted to be. Was it a social networking site (ala Facebook) or a micro-blogging tool (aka Twitter)? I think it tried to do both, but wasn’t really good at either and just couldn’t compete with what was already there.

Six Apart (Vox, Typepad et al) have annouced they have purchased Pownce but it sounds like it is just a technology and staff grab as they intend to close the site down later this month.

In the current economic climate I think we’re going to see a lot more Web 2.0 start-ups either getting swallowed up by bigger neighbours or simply closing down.

There are plenty of other blog posts out there covering this same issue, but I’d like to add this “me too!” post anyway. As I like to think that the more people complain about something then the likelier it might get resolved. Well, I can hope anyway!

The Problem

So we’ve got this custom SharePoint timed job that performs a Collaborative Application Mark-up Language (CAML) query across a SharePoint site collection using the SPSiteDataQuery class in the SharePoint API. The query looks across document libraries only and checks to see if any documents, within any of these document libraries, within any of the SharePoint sites in the collection, has a custom property set to “1”. It then does a bunch of stuff with the documents returned by the query.

The problem we saw is where some documents that had this custom property set were not being dealt with by our custom SharePoint job. Upon further investigation we discovered that the CAML query used by our job was not returning all the results we were expecting. In fact, it wasn’t returning documents held in any other document libraries but for the first document library it came across. So what was the problem?

The Workaround

It transpires that this is a known problem with both Windows SharePoint Services 3.0 and Microsoft SharePoint Office Server 2007 and there is no fix (as yet). For our scenario we used Method #1 as discussed in the following Microsoft KB Article, which also describes the cause of this problem: http://support.microsoft.com/kb/946484

We re-configured the relevant document libraries so that the columns (both standard and custom) on each where completely identical and created in the same order. This then got the CAML query returning all the expected results.

Will this be fixed in the forthcoming Service Pack 2 for WSS & MOSS? I doubt it, as this to me sounds like a SharePoint design problem to me. Hopefully I’ll be proved wrong though.

I’ve been working with Windows SharePoint Services (WSS) and Microsoft Office SharePoint Server (MOSS) quite a bit in the last few months. I’ve learned many things over this time (and plenty of things I should have already posted in this blog!) and here is one of them. This is actually something I worked on nearly six months ago, but I had to remind myself of how I did recently and so while it’s still fresh in my mind…

My Problem

I’ve got a number of pages within a MOSS publishing site that display a customised view of an existing Document Library using the very useful Content Query Web Part (CQWP). This web part comes as standard with both WSS 3.0 and MOSS 2007.

My client had a simple request. They wanted the documents listed within this web part to display in a separate web browser window when they were clicked on by the user - the default behaviour is to display the document within the same browser window. Simple I thought – the Summary Links Web Part has the “Open in a new window” option and so I’m sure the Content Query Web Part must have a similar option somewhere. Oh, SharePoint, how you tease me so…

My Solution

The Content Query Web Part has no such option. That would just be far too convenient! And so after a quick search I discovered (and in a couple of cases, tried) all sorts of solutions to this and similar problems. Blocks of custom JavaScript code added to the master page, creating a customised version of the Content Query Web Part, modifying the default SharePoint XML schemas…all sorts of things. So what did I do? Well, I added a custom style to SharePoint’s ItemStyle.xsl file.

Warning: This solution is still far from ideal, as if you edit the ItemStyle.xsl file and leave it in a malformed state then this can cause all sorts of problems across your SharePoint site collection. If the contents of this file isn’t valid XML then you’ll see the nasty “Unable to display this Web Part” error in SharePoint. Make sure to at least make a copy of this file before you start editing. You can also revert this file back to how it was originally by right-clicking on the file and selecting “Reset to Site Definition” within Microsoft SharePoint Designer.

I discovered this solution when I noticed that when you Modify the Content Query Web Part that you’ve added to a page, you should see that under Presentation there is the Styles section:

The style selected here dictates how SharePoint will generate the HTML for each item on the page within the Content Query Web Part. I already knew that in HTML if I want a link to launch in a new browser window then I want to add target=”_blank” property to the opening anchor tag. It’s finding where this is within SharePoint that proved to be the challenge.

So where is it? Fire up SharePoint Designer and open the root of your SharePoint site collection. You should hopefully see a Style Library folder and so expand this and browse down to the XSL Style Sheets folder. Within there you should find the magic ItemStyle.xsl file. Check this file out so we can make an addition to it and open it in Microsoft SharePoint Designer for editing:

Once this file is open in SharePoint Designer, you want to scroll to the end of the file and before the closing “</xsl:stylesheet>” tag we want to paste in our custom item style. Here is my example of a custom item style:

<xsl:template name="NewWindowLink" match="Row[@Style='NewWindowLink']" mode="itemstyle">
	<xsl:variable name="SafeLinkUrl">
		<xsl:call-template name="OuterTemplate.GetSafeLink">
			<xsl:with-param name="UrlColumnName" select="'LinkUrl'"/>
		</xsl:call-template>
	</xsl:variable>
	<xsl:variable name="DisplayTitle">
		<xsl:call-template name="OuterTemplate.GetTitle">
			<xsl:with-param name="Title" select="@Title"/>
			<xsl:with-param name="UrlColumnName" select="'LinkUrl'"/>
		</xsl:call-template>
	</xsl:variable>
	<div id="linkitem" class="item link-item bullet">
		<xsl:call-template name="OuterTemplate.CallPresenceStatusIconTemplate"/>
		<a href="{$SafeLinkUrl}" target="_blank" title="{@LinkToolTip}">
			<xsl:value-of select="$DisplayTitle"/>
		</a>
	</div>
</xsl:template>

If you now save this file and go back to your web browser then you should hopefully see this new style (called “NewWindowLink”) listed under the Item Style drop-down menu. You may need to refresh the page and open the Content Query Web Part settings again. Although there should be no need to restart any of the IIS or SharePoint services in order for this change to take effect.

Now the links returned by your Content Query Web Part (wherever you have this custom style selected) should open in a new browser window!

Is this the best solution to this problem? I honestly don’t know - this way works for me hence I thought I’d share it. If someone knows of a better way or has any other questions then please post a comment below!