I’d a question from a reader (gee, I have readers!) about doing content rollup using the DataView web part. He was asking if he could use the DataView web part even though the things he was pulling into his Data Source didn’t all have the same columns. Would this work? Well, one way to find out… Read more »
One of the problems with SharePoint is that it’s very difficult to figure out what site is specified by a URL. After all, the URL to a particular page contains:
Suffice to say, with all those optional bits, decomposing a URL to find the site is really hard. There is, however, a slightly obscure way of find this. You can create a site collection (SPSite) with a full URL, and then simply call OpenWeb() without any parameters to return you the site (SPWeb):
string path = "http://example/examplesite/_layouts/settings.aspx";
try
{
using (SPSite siteCollection = new SPSite(path))
{
using (SPWeb site = siteCollection.OpenWeb())
//Do something with the site
}
}
}
I found this when looking at the MSDN docs for SPSite.OpenWeb(). Check out the examples in there.
It’s a little weird that the SPSite object remembers information about how it was opened like that. But it is useful to know.
Something I didn’t know about - the people picker shows disabled user accounts - and ‘Tales from the field’ has a solution (on a per web app basis). Just in case the blog ever goes down:
This default behavior can be changed on a per web application basis to return only enabled user accounts. In the example below I have configured this for the web application http://moss using stsadm. This command configures MOSS 2007 to use a custom LDAP query.
stsadm -o setproperty -pn peoplepicker-searchadcustomfilter -url http://moss -pv (!userAccountControl=514)If you are interested in putting together more granular filters I strongly recommend the following guide on LDAP, LDAP Query Basics - http://technet.microsoft.com/en-us/library/aa996205(EXCHG.65).aspx
Nice one Brendan
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 />
</xsl:for-each>
</div>
</xsl:template>
Knowing when to dispose of SPWeb or SPSite objects is confusing as hell. Well, Roger Lamb has an excellent page showing patterns that can leak memory, and how to avoid them. This should be mandatory reading for SharePoint devs. (Previously mentioned here - but this is a better link)
As noted previously, Meeting Workspaces use a different master page to the ‘normal’ master pages in SharePoint. This is a little annoying - if I need to apply a new master page, how would I do this?
Well, you can activate a new master page in a Feature Receiver. And we can detect the type of site we’re dealing with. Why not combine the two techniques Read more »
I was tempted to call this “The incredible case of the bust rendering of SharePoint pages”, but it seemed a bit long, to be honest. This is a bit of a detective story (and if I’d the developer who built this in the first place, there’d be a murder) so stick with me… Read more »
Previously, I’d been asked to put a web part zone below the quick nav for SharePoint pages. As it transpires, you can’t put web part zones on master pages - but there is no reason why you shouldn’t put one in an asp:Content control (indeed, that’s how you have to place them on pages). And I’d noticed this PlaceHolderLeftActions content placeholder. So I figured, why not put my web part zone into that?
To do this, I need to modify the page that I want this zone to appear for. It could be a Page Layout for publishing pages, or just a normal default.aspx on a team site. I’m using a blank site for this. I simply added a Content control, and dropped a web part zone into it:
<asp:Content ContentPlaceHolderId="PlaceHolderLeftActions" runat="server">
<WebPartPages:WebPartZone id="g_5AD648BF053647678E80875B48A60593" runat="server" title="Zone 1">
</WebPartPages:WebPartZone>
</asp:Content>
I saved the changes, and now when I go to edit that page I see:
Great! I can drop in web parts - here I’ve used a summary links web part:
But you may find the styling leaves something to be desired - but you can design that in!
Sure, you could find that you have to do this a lot of times if you want to do this for many pages, but if you’re using the publishing features, you only have to modify each Page Layout once, which is very handy.
I’ve built a feature to active branding on a site including master page, navigation and themes, which I’ve been talking about a bit over the last few weeks. One issue, though is that meeting workspaces have a different master page to ‘normal’ master pages, so I need to set them to use a different ‘custom’ master page when the feature is activated. This means that my feature receiver has to ‘know’ if the site it’s being activated on is a Meeting Workspace, or some other site.
What defines the ‘type’ of a site is the template that was used in it’s creation. Read more »
So, yesterday’s discussion of the problems with master pages for Publishing and Meeting sites raised a bit of a question with my colleagues. If a site (SPWeb object in the code) has both MasterUrl and CustomMasterUrl properties, how does a page ‘know’ which one to use? Why do publishing pages use the value in CustomMasterUrl, and other pages use MasterUrl?
Well, to find the answer to that, you’ve got to look in the code of the .aspx content page. Here’s the top of one in SharePoint Designer:
Yup, there is a MasterPageFile as per standard ASP.NET. However, the value of this isn’t normal - it’s not the URL itself, but rather a token that gets replaced at runtime.
If you look in, say, the default.aspx page on a team site, you’ll see that it uses ~masterurl/default.master.
If you look in, say, the default.aspx page on a meeting workspace, youll see that it uses ~masterurl/custom.master.
If you look in publishing pages, though, you have to look at the page layouts (which are the actual .aspx pages being used). These don’t have a have a MasterPageFile defined - what gives? Well, they inherit from the Microsoft.SharePoint.Publishing.PublishingLayoutPage class, which sets the master page file internally during OnPreInit! You can see in Reflector that it’s using CustomMasterUrl though.
RSS