Awkward SharePoint Link field text

I had a gnarly support call today. One of our customers was using Announcement lists to display news on the homepage of their intranet, and they’ve a thumbnail image they’d set for each item. Then, on the home page, they’ve got a Content Query Web Part using some custom XSL to render those announcements.

However, the Content Query Web Part would only show some of the thumbnail images.Capture

TL;DR – Saving an image field on a ‘New’ form without a descripion saves a different format to after an ‘Edit’, which sets a default even if you don’t change the image field value.

Continue reading “Awkward SharePoint Link field text”

Awkward SharePoint Link field text

Tabular Search Results with Column Filters

The customer I was with last week, like many others, wanted their search results to appear in a table form – like a List View, in fact.

List View Search Results

Now, I’ve written the XSL to do this for various solutions over the years, but they had found a CodePlex project for this – SharePoint 2010 Search Results in Tabular Format. This project has a feature I’d not managed to write, or had seen working before – column titles that were sortable and filterable:

Sorting and Filtering on Columns

That’s pretty neat. And it’s all XSL. You can, if you edit the XSL and the Columns you get back from search, show, sort, and filter other columns of data.

One observation I would make is that this XSL does not format Hit Highlighting – that is, matches aren’t shown as strong, and the summary doesn’t contain any ellipsises [ … ] characters. However, you could easily add these from the ‘standard’ XSL to get hit highlighting working again.

Tabular Search Results with Column Filters

Date Formats in XSL with ddwrt

Previously I’ve blogged about using ddwrt to format dates and datetimes. Well, today, I found myself trying to figure it out again, so here is a reminder. Remember, one of the big advantages of this (in the UK at least, where we are UTC time half the year) is that the DateFormat function accounts for daylight savings (i.e. the difference between GMT and BST)

Add this to the xsl:stylesheet tag at the top:


Then you can use something like the following (where item_date is an XSL variable with our date in it):

<xsl:value-of select="ddwrt:FormatDate(string($item_date), 2057, 15)" />

Here the FormatDate function is taking the string of the date, formating it for Great Britain’s locale (2057), and specifying an output format (15). Output formats vary by locale, and not all seem to be valid. I found that when I tried a format of ‘2’, for example, that I got an XSL error.

This is a particularly useful with the Content Query Web Part and the RSS Feed Web Part

Date Formats in XSL with ddwrt

Linking list data and summing over it with XSL and the Dataview Web Part

Thrilling title, eh? So, previously I’ve talked about merged lists in the Dataview web part. This time, I was after something slightly different – rather than merging two lists, I wanted to join them.

Joining is pretty easy, actually, but the process is a little bizarre. I ended up using the post ‘Performing Joins with SharePoint Lists‘ by Sahil Malik. The thing that confused me was that when I was I expected to provide the ‘keys’ of my lists when I created the new Datasource – but actually, you define it when you insert your ‘joined subview’.

Anyway, the scenario was that there are customer purchases for ‘Credits’ to do things. Operatives then do things for them, and these actions subtract time off those pools of credits. The need was for a way to:

  • Record purchases of pools of credits. Customers may purchase multiple times, but under different agreements (or invoices, or whatever)
  • Record actions and the number of credits that they cost
  • Remaining total.

I solved this with a Dataview web part, and two lists. Continue reading “Linking list data and summing over it with XSL and the Dataview Web Part”

Linking list data and summing over it with XSL and the Dataview Web Part

CQWP: Show the first item in each group

So, we have a customer who has a library of Newsletters.


These newsletters belong to different regions, and they have a date on which they should be ‘published’ – or at least, a date at which they’re the most recent item. So, we have two columns to capture that – News Region and Publish Date.

The customer wanted a web part on a page that would show the most recently ‘published’ item for each of those regions. Something like:


I did this with the Content Query Web Part (CQWP) – but how?

Well, first I set my CQWP to query the list of newsletters. They have a specific content type that I queried for. I filtered items with a Publish Date in the future out – although not a secure way of preventing users seeing these items, at least it doesn’t make the obvious.

Next, I set the CQWP to group by News Region, and Sort by descenting Publish Date. So far, so standard – but it would also return multiple items for each region, and display their title, not their region.

This called for a special Itemstyle, which I added using the technique mentioned before for putting ItemStyles into a different file. This made sense; we’re not going to use this style extensively, so it’s best to keep it separate.

Next, I modified my CommonViewFields to bring in the News Region column. I’ve mentioned this before.

Then I wrote my XSL:


Take a look at it – it’s cool.

Looking at the code, you can see I read the News Region that we’re looking at into a variable. I then count up the number of preceding nodes which also have the same value for their News Region.

The first node with a particular News Region value will always be the one with the latest Publish Date that isn’t in the future – therefore, the most recent one for that region. The count statement won’t count nodes for other regions, either. So, if it’s the first, we display it – using the News Region text, rather than the title. Simple!

(But a bugger of an XSL query to figure out)

CQWP: Show the first item in each group

Link the CQWP to another XSL File

I was going to remind myself of a technique that I’d seen Liam Cleary use on his blog about importing XSL files into ItemStyles.xsl, but then I noticed that he’d linked to a far better idea from Brendon Swartz – you can change the XSL file that the Content Query Web Part presents ItemStyles for. If you export the Content Query Web Part as an XML file and edit it, you’ll see a property ItemXslLink. Simply give it a url to the new ItemStyles.xsl file.

Personally, I think this is fantastic. Frequently I have been asked to do custom roll-up of content, with customised display. If you have to add to the standard ItemStyles.xsl, then before long your ‘Presentation’ setting for your standard CQWPs is full of highly specific item styles. This way, I can isolate – nearly hide – the existance of my much more specific item styles to general users.

And I’ll say more about what I was doing with it shortly.

Link the CQWP to another XSL File

CQWP: XSL to show you the fields on an item

A modification on the XSL I’d used previously – this gives a more readable presentation, and displays the values:

<xsl:template name="ShowFields" match="Row[@Style='ShowFields']" mode="itemstyle">
<div style="border:1px #aaa solid;background-color:#eee;margin:5px;padding:5px">
<xsl:for-each select="@*">
<xsl:value-of select="name()" /> = <xsl:value-of select="." /><br />

CQWP: XSL to show you the fields on an item