SharePoint designer is so like a wife – I love it to bits, sometimes I hate it, and I fervently hope for a cuter version in the future! No, I’m kidding.
But SPD currently has this persistence in adding a in front of my page’s title field. I don’t need that non-breaking space. I don’t want that non-breaking space. But I keep deleting it, and Designer keeps adding it back in.
For me, it’s a sign one of the two big problems with SharePoint Designer – robustness. When I’m in Visual Studio, I’m comfortable; it’s pretty reliable, normally, and behaves in ways I understand. Even the things that can blow it up are pretty well understood. Much as I hate to admit it, I do think that the reason that C# won out over Java was simpler, robust tooling – Visual Studio.
However, with SharePoint designer all sorts of weird stuff happens… Continue reading “SharePoint Designer – grrr….” →
I just had a really weird error – I’d built some search pages for a customer. There was a custom results page, and a custom ‘Advanced Search’ page. When I went into Edit mode, to change the web parts, they didn’t have a title bar – including the ‘Modify this web part’ link. WTF?
Well, they’d been customized using SharePoint Designer, so I figured I’d copy their code from the customer system into a VM of mine, and check that the pages broke on my system. They didn’t. WTF x2 ?
So, the page page code, inside the same master page, in two different systems works differently. To check I wasn’t going nuts, I tried a WinMerge compare on the two files – and found this chunk of XML in my non-working version on the customer site:
<!--[if gte mso 9]><xml>
<o:PublishingContactPicture msdt:dt="string" dt="string">, </o:PublishingContactPicture><o:PublishingContact dt="string"></o:PublishingContact>
Yes, although I’d cut and pasted the code, it was different. I came to the conclusion that this code is created or used by SharePoint Designer itself. I decided to delete it, save the changes to the customer’s page, and refresh my pages. It worked; now when I edit the page, lo, there are titles and the ‘Modify this web part’ menu. I have no idea what this XML is about, but I’m about 70% confident that it’s the culprit. I reckon that there’s a 30% chance that it was just being customized in SharePoint Designer again that fixed it, but I couldn’t see anything else related to the code that was likely to be a problem.
So, a customer of ours is upgrading to SharePoint 2007. One of the things they were looking for is a hit counter, so they can see the number of times a page was requested. This was easy for them to do in SharePoint 2003 – they’d just use FrontPage, and insert a Hit Counter web component. I’d never heard of such a thing build into 2007, but over morning coffee, I decided to give it a try. Much to my surprise, it works… …sort of.
There is a hit counter (albeit with an awful set of styles). It does work too:
That’s one of the better styles, believe it or not. So, what’s the problem with this?
Well, in normal pages, nothing. It counts; ’nuff said. However, publishing pages are a bit different. They store metadata in a ‘Page Content Type‘ and then use Page Layouts to render that data. What this means is that many things that appear to the user as separate pages actually use just one ASPX file for rendering their content – and this is where the hit counter doesn’t work. It counts the number of hits on the ASPX page – so instead of getting a number of hits on that page of content, you get the number of hits on content using that page layout. Which sucks a bit.
I’ll look into this a bit more soon, and see what I find. It can’t be that hard – apart from the whole ‘Page Layout’ thing, it’s not exactly rocket science.
A tip that much has been made of, but good nonetheless – in Internet Explorer, set the Default program for editting pages to SharePoint Designer to make life easy. Go to Tools > Internet Options > Programs > HTML Editor and select SharePoint Designer.
Then in Internet Explorer you’ll have the option to open SharePoint Designer to edit the page. And that’s what it does.
I was trying to delete a master page in SharePoint designer, and I got the error “This item cannot be deleted because it is still referenced by other pages”. This was strange, as we knew that the master page had been reset for all sites in the site collection. We simply couldn’t find a reference.
Well, it turns out that this is a bug, and that Katrien De Graeve has an answer – create a folder, move the master page into the folder, delete the folder. Bizarre, but it works. And I have no idea how the heck they figured that out…
A good article about the limitations of SharePoint Designer workflows…