Highlighting tabs in the top navigation

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:

nav-link

showing:

highlighted-top-nav

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.

Highlighting tabs in the top navigation

Plan Your Publishing Pages

I was reading Andrew Connell’s book ‘SharePoint 2007 Web Content Management‘ and it made something crystallize for me. I’ve been pondering this for about 8 months or so, but I believe that several of our customers are using the Publishing features of MOSS incorrectly, and that simply basing sites on out-of-box Collaboration and Publishing site templates is a mistake.

(Well, at least without additional planning) Continue reading “Plan Your Publishing Pages”

Plan Your Publishing Pages

RSA SecurID and SharePoint

I’d an interesting question from a customer the other day – they wanted Forms Authentication on extranet access to SharePoint, but using two factor authentication. The product mentioned was RSA SecurID, and this means that to authenticate yourself you need:

  • Your Username
  • A hardware device that shows a pseudo-randomly generated PIN number which changes every minute or so.

‘Cos the PIN is a pseudo-random sequence, if the token and a server are in sync, you can validate that someone has read that token inside the last minute. It’s an expensive technology – but neat!

The idea is the same as, say, a credit card. More than just saying who I am and that I have some piece of knowledge (e.g. my PIN number), I also have to have a physical object which is hard to duplicate (my credit card). This should make my identity more certain.

Anyway, how does this fit with SharePoint? Continue reading “RSA SecurID and SharePoint”

RSA SecurID and SharePoint

Pages in SharePoint VI – Forms Pages

Forms pages are not really that different to normal pages, but are worth a mention. These are hidden pages inside lists and libraries, and they provide the forms for creating new (and editing existing) items. They exist in a hidden _forms folder in the list:

As you can see, the forms folder for this document library contains quite a number of forms pages! So what do they look like?

Looking in SharePoint Designer at the form page, we see a web part zone containing a web part – in this case the ListFormWebPart. So why is this interesting? Well, we could put our own web part here, should we wish to. For example, you might be recording longitude and latitude on a list item – but that isn’t very intuitive. Instead, we could write a web part to display a map, and use that to update the list item.

In short, they’re not pages I’d expect to edit often – but there is quite a lot you can do with them!

| Intro | Master Pages | Normal Pages | Publishing Pages | Application Pages | Forms Pages |

Pages in SharePoint VI – Forms Pages

Pages in SharePoint V – Application Pages

Application pages are a pain. They exist inside the _layouts directory, and are common to all the files across the farm. This makes them difficult to change, as such changes happen thoughout the system, not just one site or site collection. They’ve also got their own master page – and it’s difficult to change, which often you want to when branding a system. Essentially, you should try not to need a new master page (application pages can be modified by Themes, so that’s one way of branding them).

So what is an application page? Well, it’s a standard ASPX page. They’re usually for site administration type tasks, though there are a number of pages that users are likely to see regularly that are also application pages – such as file upload, the recycle bin and the “View all a site contents” page. Therefore, there is a problem – you can brand up your SharePoint Site, but if a user tries to upload a file they’ll drop out of that branded experience. For example, this example shows a SharePoint Site using a custom Master page (background window), but if you try to upload a document to that site you’ll see a standard upload page (foreground window). If you look in the URL for the upload page, you’ll notice it’s in the _layouts directory:

Like I say, you can change the style of this window through themes, but really that means just changing the colours – changing the structure of the page is much, much harder. Below is an example of changing the Site’s appearance through themes – you can see that this applies to the upload page too.

You shouldn’t change application pages themselves, as they are core to SharePoint and you won’t be supported by Microsoft – but you can add your own, should you want to present your own farm-wide administration pages.

| Intro | Master Pages | Normal Pages | Publishing Pages | Application Pages | Forms Pages |

Pages in SharePoint V – Application Pages

Pages in SharePoint IV – Publishing Pages

Publishing pages are specific to MOSS, as they require the publishing features! They’re not in WSS3! A good example of a publishing page is the default.aspx of a Collaboration site – that’s right, although the default page has the same name as for a team site, it is quite different:

Looks pretty much the same though, eh? That’s because it uses the same master page, but we’ll come to that in a bit.

These pages are are stored in a ‘Pages’ library (you can see this highlighted in the URL). They aren’t really like documents though; they’re much more like list items. Basically, these pages are collections of metadata columns. Different pages have different content types, such as the ‘Press Releases’ page type of the Publishing Portal site template. The other pages types that come out of the box are the ‘Article’ and ‘Welcome’ page types of a collaboration site.

These content types have different columns of data. For example, you might have a type of page for ‘Vacancies’, and that might have columns for position, salary, etc.. You might also have a type of page for ‘Products’ which might have columns for part number, cost, stock, etc..

Okay, so I’ve said that these pages are more like collections of metadata – how does this become a web page that you can see and read? Well, each page type has one or more page layouts. Lets have a look at one in SharePoint Designer:

These are kind of like master pages – they define the layout of our metadata columns in an aspx page. In the one shown above there are only 2 metadata columns, which I’ve highlighted – Page Image and Page Content.

Okay, but what about the master page stuff? Well, out page layout the content controls to go into our master page. Confused? It is confusing, so here is a diagram to show this:

Here you can see the page metadata being put into the page layout, which in turn puts content into the master page, which finally generates the output that gets sent to the user.

One advantage of this approach is that you can change between different page layouts for a given publishing page type – for example, you might have ‘Product page with image on left’ and ‘Product page with image on right’ layouts. Changing the page layout does not require editing any of the content.

| Intro | Master Pages | Normal Pages | Publishing Pages | Application Pages | Forms Pages |

Pages in SharePoint IV – Publishing Pages

Pages in SharePoint III – ‘Normal’ Pages

‘Normal’ pages are just ASPX pages. They usually (but don’t have to) use a master page, and we’ll consider them in that way. First let’s look at a good example – the Default.aspx of a Team Site.

The Homepage of a Team Site

Looking at this in SharePoint Designer we see the following:

On the left we see that our page just exists underneath our Team site – it isn’t in a Library or anything. On the right we see SharePoint Designer shows us the master page that the page uses at the top of the page, and what the page would look like. You can see the PlaceHolderMain placeholder is highlighted, and unlike the master page, this one has content. I’ve also circled where the PlaceHolderTitleBreadcrumb placeholder is, and this is now empty. So where did this content come from?

If an aspx page uses a master page then it says so in it’s code, and it defines a number of content controls. These content controls match up with the placeholder’s in the master page, and define the content to put in there. If we look at the code (don’t panic!):

Here we see the content being defined for the our PlaceHolderTitleBreadcrumb (the new content is ‘nothing’, and so our breadcrumb is effectively being erased), and our PlaceHolderMain (which contains lots of code for 2 web-part zones, etc.).

So, just to reiterate, a typical page in SharePoint defines content that is put into a master page. The process is something like this:

| Intro | Master Pages | Normal Pages | Publishing Pages | Application Pages | Forms Pages |

Pages in SharePoint III – ‘Normal’ Pages