Okay, this one was weird. The symptom is this – I had a custom Application page that was being used as the New and Edit forms for a particular custom list in my solution. One of the customisations was that it had an ‘Address Search’ button that, when you pressed, searched for an address based on the first line of the address, or the postcode.
That’s fine, but here’s where things got weird.
- If you were using the form as a New form, then search worked just fine the first time you clicked it.
- If you were using the form as an Edit form, the the search button didn’t work the first time you use it – but did the second time you clicked on it.
Bizarre, and I had to fix it… Continue reading
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.
The product of many evenings in hotels recently, I’m proud to present, my Application Master Page Changer.
Application master pages are tricky – out of the box in SharePoint 2007, there is no way of changing the master page used for ‘administrative’ pages. Unfortunately, those administrative pages include things like the recycle bin, file upload, and the ‘View all site content’ pages – things that users will likely see.
Well, folks have found a solution to this - using an HTTPModule to intercept pages using the normal application.master and redirecting it to use your custom one. This works pretty well, but I was always a bit uncomfortable – what if you only want this to happen for particular site collections, or specific sites within a Web Application? I’d tried knocking up an HTTPModule to do this, but matching against URLs – bit it was awkward to configure, complex, and adding new sites/site collections could be a bit annoying – basically, a nightmare to configure.
What we really need, I thought, is some way of just turning on/off the master pages being used with Features. And that’s what I’ve built. Check it out here…
SharePoint has many types of pages, but one that interests me at the moment is the Application Pages. These live in the _Layouts directory, which is a virtual directory mapped to every site.
Thus, EVERY site can have pages in the _layouts directory.
One such page, for example, is the ‘View all site contents’ page:
This page looks like a site page, but you’ll notice in the URL the _layouts part. It’s not part of the SharePoint virtual file system; it’s a physical file in 12 Hive and, for the record, you shouldn’t modify these. You can add to them though, and my question was, could I easily add a page in here myself.
The short answer – yes:
I created myself a folder in the _layouts directory (to keep my work separate), and then created this page (which might make a good template) based on the View all site content page. A good foundation for pages which might look like they’re in a site – but aren’t! Here it is as a template.
I did try adding a Web Part Manager and web part zone to the page too, but although I could swap into Edit mode and see my web part zones, I couldn’t actually add any web parts to them. To be honest, I’m not that bothered, it doesn’t seem that useful a thing to have on such 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 |
So I’ve been branding up a SharePoint system, and discovering all of the fun ‘features’ of the master pages in SharePoint. One of them is the way that SharePoint has lots of pages which use the ‘administration’ master page, which you can’t customise. And some are a bit awkward – File upload, Create Web Page, View All Site Content, Recycle bin.
Well, the View All Site content page is awkward, as everyone seems to have it on their page, but I think you’d miff site admins by removing it from the page. So, I went in and had a look at the code for it – and realised that it was security trimmed. It uses an SPSecurityTrimmedControl:
<!-- View All Site Content -->
<SharePoint:SPLinkButton id="idNavLinkViewAll" runat="server"
Hmm. Okay. But users with very few permissions were still able to see this link. What gives?
Well, the important part is the PermissionsString attribute – it’s set to ViewFormPages. That’s pretty low – users who’re able to view a library seem to have that. So I wondered, what other PermissionsStrings are there?
A quick search found Zac Smith had been wondering the same thing. And then I thought to check MSDN, and they have a nice list of the permissions and what they mean.
So, I set PermissionsString to ManageWeb, and now the ‘View All Content’ link should only appear for Site Admins.
Previously I found (in ‘David’s Blog’) a way of using an HTTP Module in SharePoint to change the master page used by ‘application’ pages. I fiddled with it a bit and made it work properly.
Unfortunately, I’ve lost my code (HD crash) and David’s blog is defunct (I think it died when the SharePoint Blogs site died).
So, some links to similar relevant pages:
Liam Cleary has been looking at it
This page proved useful
And this is a description of the same sort of thing
One of the pains about master pages in SharePoint is that when you set one for a site, it doesn’t apply to the admin pages. This can lead to a, um, interesting difference in appearance.
I started looking into overcoming this. Obviously, there is a fairly straight-forward approach – modify the application.master. Ouch. Then, any changes to design in one file have to be replicated elsewhere, with one file in the Master Page Gallery, and one on the file system.
Alternatively, I found a neat solution at David’s blog. This uses an HTTP Module to reset the master page for any pages looking for application.master.
But after following his instructions, my admin pages wouldn’t work. I just got the error page ‘Unknown Error’.
Digging into the logs, I found what was going on – there were 2 content placeholders that the application.master uses which weren’t on my ‘normal’ master page. Make sure you add place holders for:
<asp:ContentPlaceHolder id="PlaceHolderPageDescriptionRowAttr" runat="server"/>
<asp:ContentPlaceHolder id="PlaceHolderPageDescriptionRowAttr2" runat="server"/>
The full list of placeholders used in both files is:
- PlaceHolderHorizontalNav Normal master page only
- PlaceHolderPageDescriptionRowAttr Admin master page only
- PlaceHolderPageDescriptionRowAttr2 Admin master page only