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.

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.

I checked that everything was published, etc., and it all looked correct. The thumbnail images really did exist and were also published. It didn’t seem to be a caching issue as the news items had been published the day before, and they seemed to have been written and published as a major version in one go; i.e. there were no previous versions.

In the end I modified the XSL. It had shown:

<xsl:variable name="ThumbnailImageUrl" select="substring-before(@ThumbnailImage, ',')"/>
<xsl:variable name="ThumbnailImageDescription" select="substring-after(@ThumbnailImage, ',')"/>
<img src="{$ThumbnailImageUrl}" alt="{$ThumbnailImageDescription}" />

I added:

<xsl:comment>
<xsl:value-of select="@ThumbnailImage"/>
</xsl:comment>

This would let me see what the raw value of the ThumbnailImage field. What I saw was interesting. For the failed images, it showed:

<!-- http://example/lists/images/example.jpg -->

For the announcements with working images it showed:

<!-- http://example/lists/images/example2.jpg, http://example/lists/images/example2.jpg -->

The latter is more like what I’d expect. As the XSL above suggests, the field value for an image field can contain both the image URL and a description. The failed images weren’t getting the Thumbnail URL as their field value lacks (somehow) the comma that the XSL is looking for.

How did that happen? For both the items, in their Edit forms they both showed the image’s URL for both the URL and description text boxes. Maybe this was a lie, though – perhaps the edit form was using the URL as the description in the absence of one.

On the off-chance we tried re-saving a failing announcement and republishing it – and suddenly it worked. The re-save had changed the field value so it included a comma and description. Looking at the version history shows the ThumbnailImage field as having been updated.

I wondered if the working new items had all been edited after creation – and they had.

Thus, I discovered that items that had been created without a thumbnail description didn’t work (due to our XSL not expecting image fields without a comma in the value). Editing that item – even if you didn’t change anything – would update the image field’s description (to the value of the URL). This would cause the value to be saved in a different format, which had a comma. This then works in our XSL.

The fix – correct the XSL to handle the ThumbnailImage field not containing a comma.