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
I’ve seen a few questions on Twitter over the last few weeks about how to show properties from Sites or Publishing pages within pages. Actually, this is very easy.
Obviously, if you’re working with Publishing Pages, you’ve got all your publishing controls, which you can see in SharePoint Designer…
But what about site information, such as the Site Title? Or other Page Information, such as the Last Modified time? Well, I want to introduce 4 other controls – ProjectProperty, ListProperty, ListItemProperty and FieldValue … Continue reading
I keep getting questions from customers about what statuses are used in Publishing and Content Approval, and who can see what items in what status. It’s a little complex, as it depends entirely upon your configuration of content approval and versioning settings. 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]
e.g. site:http://sharepoint/finance/
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, 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…
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, 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.
So, yesterday I was wondering about custom master pages for Meeting Workspaces. I found that Meeting Workspaces use their own master page (mwsdefault.master), which is referred to in the CustomMasterUrl property of the SPWeb object. As I noted, that sounds a lot like SharePoint publishing sites (i.e. sites with the Publishing Features enabled, like a Publishing Portal or a Collaboration Site).
This rang a bell with one of my colleagues, so he dug out some details. The publishing features let you select a Site Master Page and a System Master Page… Continue reading
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 |
An interesting question from one of my colleagues:
Can you sync the Pages list with an Outlook 2007 folder and still be able to read the HTML without the MOSS CSS and XSLT stuff?
Well, my gut feel was no, but I thought I’d take a look.
I found that the Connect to Outlook option was available on the Pages library settings, so I thought I’d give it a try.
As we can see, we do have the Pages library synched, and you can see the pages within, but Outlook doesn’t know how to display them. I’m not surprised to be honest; I suspect that the default.aspx item actually just contains the data for the page – but isn’t yet rendered by the page layout or page. Still, one way to find out – open it and take a look:
Yup, there you go – the XML of the page ListItem, and not a nice, rendered page with all the layout, master page, styles and stuff. Not really surprising, to be honest, but it would be nice if it did. I can’t think of how it might do that though – clearly the whole browser page would need to be rendered. An alternative would be to generate your pages via the Document Conversion Service, and to synch with the source documents themselves, rather than the pages.