I’ve been meaning to write about this for a while – how to programmatically disable page layouts for a site in SharePoint, similar to how you’d do so with the ‘Page Layouts and Site Templates’ page in the site settings. You can also specify what page layouts are allowed, if you are defining your own Site Definition. But someday, maybe you’ll have to do it through code.
I’m pretty sure that I read something that set me going on this, but I’ve lost the link Continue reading
I had an interesting problem recently with a Site Definition. I was trying to create a publishing page, which would not create as the correct content type. I still haven’t got to the bottom of why.
However, time was limited, and we were going to have to create a feature receiver to staple to our site definition anyway, so I had a look at creating a publishing page programmatically.
We needed a feature receiver as the customer wanted the home page of their site to have a ‘Search Box’ which would ‘Search this site’, but go to a custom results page in a Search Center. My plan was to use a Search Box Web part, configured to go to a custom results page, and to append the query term:
site: [url to site]
Naturally, you don’t know the URL of the site until the site has been created – so this web part would have to be created programmatically. Continue reading
So, might not be news, but SharePoint’s out of box Page Layouts suck. I’ve already described how the page layouts have an image on branding, introducing styles to change the navigation, etc.. This has led me to the conclusion that you shouldn’t use the out-of-box publishing sites – start from a minimal publishing site, and build from the ground up.
But what of customers who have naively thought that, I don’t know, a Collaboration Site Template might be a good template to use for the collaboration site? Well, this is the problem I’ve got now; a customer has used the out-of-box page layouts extensively, and now wants the styles of the text and so on to be consistent. How can I do that? Continue reading
Aka “CAML is the bastard spawn of Satan”.
So, I’m writing a site definition to create a Publishing site. This is a bit of a first for me. One of the things I want to do is deploy a new Publishing Page Content type, and associate some layouts with it.
I started by following Andrew Connell’s instructions for a Minimal Site Definition (as in his book). This all seemed to go pretty well; testing created a new, minimal site.
Next up I wanted to deploy the Content Type and associated page layouts. Well, there wasn’t much information in his book on this – like him, I’d figured I’d write a separate Feature for deploying just the content type and page layouts – but there was very little information in his book about this. Continue reading
So, one of our customers is really keen that the new Page Layouts I’m writing show the page’s contact on the page. For those of you who perhaps haven’t had need to use this, the Contact field is a standard field on Publishing Pages (i.e. the Page content type). You can interact with it via the page settings:
… which shows a page with…
These fields are to allow you to select another SharePoint user, or manually enter someone’s details (if they’re not a SharePoint user!) Further, these fields are available in SharePoint designer:
So this looks like it’s shaping up to be a very brief blog post. Open up SharePoint designer, edit the page layout, drag the Contact field onto the page. With that, we get:
Great! Well, no, there are two problems with that…
Another thing on my long list of ‘things to do’ was have a look at the RadEditor control. Well, one of the guys at the SUGUK meeting last week finally gave me an excuse – he told me that it would detect if MS Word Formatted text was being pasted into it. Now that would be cool; all our customers have problems with users pasting Word formatted text directly into MOSS. Hell, we even had this problem with MCMS – some users insisted on writing every in Word, and copying and pasting text across
So although I might be the last dev on earth to do so, I thought I’d take a look. And I was impressed. Continue reading
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
So, a customer of ours is upgrading to SharePoint 2007. One of the things they were looking for is a hit counter, so they can see the number of times a page was requested. This was easy for them to do in SharePoint 2003 – they’d just use FrontPage, and insert a Hit Counter web component. I’d never heard of such a thing build into 2007, but over morning coffee, I decided to give it a try. Much to my surprise, it works… …sort of.
There is a hit counter (albeit with an awful set of styles). It does work too:
That’s one of the better styles, believe it or not. So, what’s the problem with this?
Well, in normal pages, nothing. It counts; ’nuff said. However, publishing pages are a bit different. They store metadata in a ‘Page Content Type‘ and then use Page Layouts to render that data. What this means is that many things that appear to the user as separate pages actually use just one ASPX file for rendering their content – and this is where the hit counter doesn’t work. It counts the number of hits on the ASPX page – so instead of getting a number of hits on that page of content, you get the number of hits on content using that page layout. Which sucks a bit.
I’ll look into this a bit more soon, and see what I find. It can’t be that hard – apart from the whole ‘Page Layout’ thing, it’s not exactly rocket science.
Right, so SharePoint uses pages and page layouts – I won’t talk about the different types, but ask a couple of questions that’ve come up a few times.
- If I create a new page layout in SharePoint, how do I get rid of the breadcrumbs?
- How can I get breadcrumbs, but like the home page?
Here’s how… Continue reading
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.