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”
We’ve got a customer who’s top navigation tabs aren’t being used as links to content in SharePoint. Instead, these tabs take users to other parts of their system, which is maybe fair enough given that the left navigation also gives them the same sort of access; indeed this duplication of navigation is often a source of consternation with clients.
Anyway, they’ve now added site that they do want linked from the top navigation bar. Therefore, if you click on this tab, they want it to appear highlighted – and it’s the only tab that would.
The site in question isn’t a subsite of the root site of the site collection, so I must confess, I didn’t think you could do this. They emailed and asked, though, and I suggested that the full URL that they were using (e.g. http://sharepoint/somesite/tabsite) wasn’t a good idea – as if they extend their web app for an extranet that link won’t work. As it transpired though, they’d thought to try a relative URL (e.g. /somesite/tabsite) and that worked nicely!
I had to check:
There we go, a site 2 levels down, highlighted in the top nav correctly!
I suppose it makes sense that the relative URL might work – but I’d sort of assumed that the manual links wouldn’t undergo the same checks as the ‘show subsites’ links would.
I came across an interesting problem today. I’m building a demo, and I wanted to use personalization site to ‘push’ a dashboard page to a certain set of users. I created a Personalization site (using the Personalization Site tempate), and then went to my SSP to set up a Personalization Link to it:
I then logged in as a user who belongs to the audience it was configured to show for:
Everything looked good – I had my ICT link that I’d just set up, so the audience was working correctly. However, when I clicked on it, things didn’t work so well…
Yup, two tabs were being shown. One was my Personalization Site link that I’d configured in the SSP, and the other was the navigation tab for the site itself. I only noticed ‘cos the name on the tab I’d added in the SSP (ICT) and the name of the site (ICT Dashboard) were different. Also, the Site’s own tab gave me the ‘Pin/Unpin Site’ option.
It’s a bit of a digression, but what’s the pin/unpin site stuff about then? Well, you don’t have to push personalization site links out to users (via the SSP). Instead, users can go to a personalization site and choose to add it to their My Site tabs; this is ‘pinning’ the site. After they’ve done this, they can remove the link (‘unpinning’).
However, that’s not what I wanted – I want the ICT audience to always have that link, and I don’t want another tab, or any pin/unpin options. So how do I get rid of that? There must be a way; it’s obvious that if I’m pushing a personalization site to a bunch of users that they shouldn’t get those options.
After much head scratching, I figured it out. My personalization site link in the SSP only pointed to the site, not to the actual page. I changed it to point to the page (default.aspx).
When I then navigated via that tab, I was shown only one tab – with no pin/unpin options:
Hurrah! What I think happens, then, is that the top navigation compares the URL of the current page in the personalization site with the URLs for the tabs in the user’s My Site. If none of them exactly match, then it adds a tab for the site itself, including the pin/unpin menu. Although my personalization site’s url did resolve to the same page (default.aspx) the URLs were not the same – and hence I was getting two tabs!
Okay, so I’m not a huge fan of the out-of-box publishing layouts. I’ll be honest – I reckon that there should be about half of the layouts, and I don’t like the ‘Welcome Page’ as a description. ‘Generic Page’ perhaps?
Anyway, some of them have pretty cacky layouts, often with Summary Links built into the page (why? Can’t I just add a web part?) – but as a rule, they keep the left hand navigation for the site. This is good – users get confused when their navigation isn’t how they expect.
New WSS Pages, however, do not keep the left hand navigation.
This has led to more than one customer asking “where has my left hand nav gone?” Not an unreasonable question – after all, did someone think that users wouldn’t need standard navigation in team site pages? Don’t get me wrong, I like that you can get rid of the left navigation menu if you want – but I think this will be the exception, not the rule.
You can get the left navigation back using SharePoint Designer (and some cynics might suggest it’s a ploy to set SPD licenses, though I don’t think so). However, I shouldn’t have to! Can’t I have a couple of out-of-box layouts that are like, well, the one used in Default.aspx on my team sites? Is there a Codeplex project for such a thing, maybe?
Even better would be if Default.aspx existed inside a library like any newly created pages I build are. I don’t like that it is separate to the other pages in a WSS3 site.