The odd bit

Once is an accident, twice is a coincidence, three times is an enemy action.

The odd bit - Once is an accident, twice is a coincidence, three times is an enemy action.

Sitecore Web Service Pitfalls

I recently started an adventure involving Sitecore’s out-of-the-box web service. In fact, I didn’t know such a thing existed in Sitecore until I searched the web for information about accessing Sitecore from a process outside the ASP.NET runtime.

The good news is a web service exists. The bad news is the documentation barely exists. Apart from a document titled The Sitecore Web Service Reference Guide on the Sitecore Developer Network, you literally are on your own.

Thankfully, there’s no problem in getting it to work. The problem is actually using the web service.

Problem 1: Return values

The document describes – in nothing more than just a few words – all available methods. The return value is always of the type System.Xml.Linq.XElement but no part of the documentation shows what the return value actually looks like. After some debugging I found out the result always takes this form:


Problem 2: The documentation is wrong

Ouch! The documentation for the Save method tells us that it needs the XML representation of an item. A special note even points us in the right wrong direction:

You can obtain the XML representation by the GetXML method.

So you call GetXML, modify the XML to include your updates and then supply that XML to the Save method. Been there, done that and received the status ok reply. Woohoo!

… or not. Despite the OK from Sitecore I didn’t see my updated field value. Time to figure out what the Save method actually does using dotPeek. Upon inspection it seems the method expects an XML like:

    <field itemid="{guid-of-item-to-update}"
           fieldid="{guid-of-field-to-update}" />
    <field ... />

That XML is completely different than the XML representation of an item! I changed my methods to produce the “new” XML format and… it worked :)

I really hope I don’t need to create a follow up post!

CSS: Love Hate

The slightly odd title is there for a reason. This post exists for a reason. I’ll explain both…

I’ve always struggled to remember the order in which hyperlink styles should be defined in a stylesheet. Hyperlink styles? Order? I’m talking about these (in alphabetical order):

  • :active
  • :hover
  • :link
  • :visited

They should be specified in the right order or things won’t work the way you’d expect them to. Here they are again but this time in the correct order:

  • :link
  • :visited
  • :hover
  • :active

I could go into details why this is the right order but I won’t :-) That’s not the purpose of this post.

The good news is that there’s a mnemonic to remember the order: LoVe HAte. For those not paying attention: mind the casing of the mnemonic!

So that’s the title of this post. But why? To keep me from googling each time I forget the order 😛