Probably my biggest pet peeve with SharePoint Designer, other than the occasional lock up and crash, is that frequently it will show files as being checked out when they are actually not.  This is particularily annoying, because you will have to pull up the site in a browser and check it out from there to do any edits on the file.   I still have not figured out a good reason for this, other than that the “value” for this appears to come from the user cache, rather than from the server.  Kind of a poor implementation in my opinion.  Regardless, at least it is fairly easy to resolve.  Just browse to (from Windows 7):

C:\Users\YourUserName\AppData\Local\Microsoft\WebsiteCache

Then find the site that is giving you grief and delete the associated files.  SharePoint Designer will rebuild them next time you pull up the site.

Despite deactivating the Office integration, you may still have documents that try to open in the browser.

To work around this, add a bit of script to your site:

jQuery("a[onclick*='SharePoint.OpenDocuments']").each(function (data) {
    var h = this.href;
    if (h.indexOf('http') >= 0) {
        var p = h.indexOf('/', h.indexOf('/') + 1);
        h = h.substring(p, h.length);
        p = h.indexOf('/', h.indexOf('/') + 1);
        h = h.substring(p, h.length);
    }
    this.href = '/_layouts/download.aspx?SourceURL=' + h;
    jQuery(this).removeAttr('onclick');
});

CAML can be rather hairy, and it took me some digging to find out how to query a list for items assigned to a user (of the “User” type).  It turns out the best method to do that is to query by the user profile id.  This will pull you back items for just that specific user.

<where>
<eq>
<fieldref name=”PersonFieldName” LookupId=”TRUE”/>
<value type=”int”>UserID</value>
</eq>
</where>

Alright, first post, but a rather necessary one. Every time I do a new SharePoint installation, I find myself constantly going straight to the web.config file to make a couple changes.  If you have spent any time with SharePoint you already know about these, but I find it’s always good for a reference.

I know that it’s not recommended, but I find creating an entry in the PageParserPath block to be invaluable for testing out some code against the API in a quick and dirty fashion. It beats having to pack up and deploy features every time I want to test a line of code.

1. First create a folder in your “Pages” directory (once you’ve turned publishing on)

2. Then, to add runnable ASP pages with custom code, modify the PageParserPaths block of the web config: