I’ve been writing a client side object model script to set up some sites, including setting some the navigation settings on the site. Sadly, Microsoft have written SharePoint to involve at least 3 objects in the navigation settings for a site (PublishingWeb, WebNavigationSettings, and SPNavigation. At least. It’s totally effing bonkers.), and those objects don’t work in quite the same way for CSOM. For example, it’s not clear how to set a site to ‘show subsites’ in the global navigation. Continue reading “Set Global Nav in CSOM”
In SharePoint 2007 and 2010, if you wanted a neat hierarchy of publishing pages, you had two options. Either, you structured your SharePoint site so that you got the navigation you wanted, or you built custom navigation providers. Unfortunately, customers typically want everything to be ‘out of the box’, even if that means some absurd structures just to get the navigation right. Developing custom navigation providers is a really tough sell, but I’ve also seen site structures 7 levels deep to try to avoid this – and a 7 level deep site structure is a really bad idea.
SharePoint 2013 gives us a standard alternative to structural navigation. Instead, we can use ‘Managed Navigation’. This is a Managed Metadata termset that define’s our site’s hierarchy.
That’s great, but there are some problems with this still. Continue reading “Making Managed Metadata Navigation work well”
Recently, a few of our customer’s systems that I’ve looked at have had the Publishing Infrastucture site collection feature activated, but purely for the top navigation. That seemed quite a heavyweight approach to me. Continue reading “Publishing Navigation without the Publishing…”
The Portal Site Connection can be a useful way of making your breadcrumbs link to a site collection that is ‘above’ them in the logical architecture of a site. It’s also a good way of navigating out of Search Sites and My Sites – which are kind of navigational black holes.
Unfortunately, they don’t work in Publishing sites. I investigated why. Continue reading “Portal Site Connection and Publishing Sites in SharePoint 2010″
This is a seemingly simple task – given a List or Library in SharePoint, how do I get it’s URL? The difficulty here is that a List has multiple URLs – one for each View on the list. We can get those URLs, but sometimes you really just want the URL to the list, without the /forms/something.aspx bit too.
For example, you might want http://server/siteCollection/site/lists/somelist . If you entered this URL, you’d be taken to the default View for the list, so you don’t really need the extra /forms/… bit to identify the list – that’s all about identifying the view.
This is a reminder of a couple of problems that I’ve come across a few times – that the breadcrumbs in LAYOUTS pages and central admin are a bit tricky.
Breadcrumbs in Layouts pages are driven by an XML file in your IIS web app. Now, you can add entries which are merged into that – a described by Jan Tielens’ Adding Breadcrumb to application pages in SharePoint – the easy way. However, this doesn’t cover the whole problem – he goes on to describe dealing with Central Admin too.
However, the really tricky bit of this that though we can define our own sitemap.xml file, it’s kind of hard to merge with the existing one. Specifically, the problem is that to merge ‘our additions’ and the ‘existing file’, we have to call a function ApplyApplicationContentToLocalServer, and as brilliantly described by Sean McDonough, the word ‘local’ is a problem in this method – it only forces a merge of the files on one server. Not much use in a server farm.
Sean’s article describes his attempt at a fix – using a one-time timer job, and a fair bit of reverse engineering of the ApplyApplicationContentToLocalServer function. Also, it seems like Vince Rothwell has come up with a similar solution, so it’s likely that this is a good approach.
A real pain to have to build so much to do such a simple task, though.
I recently had a customer who wanted a simple web part that just listed the subsites of a site – something like what you see in SharePoint’s “View All Site Content” page, but for a couple of levels, rather than just one. Obviously, this would be quite simple to do directly by traversing the SPWeb object and it’s children, but it struck me that there must be a better, standard way – ideally one that uses a bit of caching or optimisation.
I found myself looking at the PortalSiteMapProvider for the first time. I’ve written my own NavigationProviders before now, and I’ve used some of the out of the box ones, but the PortalSiteMapProvider is an object I’ve never really used, or become familiar with. Here’s what I found… Continue reading “Using the PortalSiteMapProvider”