Contextual Search Results Page Redirection via HTTPModule

So, I’m continuing my efforts at finding a way to handling Contextual Searching.

To describe the issue again, SharePoint allows you to search ‘This List’ or ‘This Site’. Unfortunately, these searches always show the ‘OSSSearchResults.aspx‘ results page, which is built into SharePoint, can’t be modified, and this means that you can’t use your normal ‘Search Center’ experience, which is usually modified and optimized for your users.

This is a shame, so I’ve been looking at ways of overcoming this problem. Continue reading “Contextual Search Results Page Redirection via HTTPModule”

Contextual Search Results Page Redirection via HTTPModule

Contextual Searching Via Search Box AppendQueryTerms

I’ve been looking at using the Search Box web part for a light-weight contextual search.

SharePoint allows you to search ‘This List’ or ‘This Site’. Unfortunately, these searches always show the ‘OSSSearchResults.aspx‘ results page, which is built into SharePoint, can’t be modified, and this means that you can’t use your normal ‘Search Center’ experience, which is usually modified and optimized for your users.

You can add a ‘context’ to a search with some of the search query terms. “Site:http://example/sites/docs” for example would restrict results to those below that URL. So, is there any way we can add that to our query? Continue reading “Contextual Searching Via Search Box AppendQueryTerms”

Contextual Searching Via Search Box AppendQueryTerms

Programmatically create pages – and Add Web Parts

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 “Programmatically create pages – and Add Web Parts”

Programmatically create pages – and Add Web Parts

Search a single Site

Previously, I’d posted about a customer who wanted to search a single list from a Search Box web part, but have their results shown in a Search Center results page. We ended up using a custom scope to do that.

This time, I’d a slightly different requirement. Another customer had a number of links, and these links would include search terms. They wanted to be able to restrict those searches to particular sites – and not just one particular site or set of sites, but to lots of different sites.

This made adding a scope an unappealing prospect. You’d have to add lots of scopes, and it’s not very dynamic.

One thing you can do in SharePoint search is search on the value of a particular managed property. A normal search would have query parameters like:

?k=King%20Lear

That would search all of SharePoint for ‘King Lear’. Well, we could also filter by properties – so we could do a search for:

King Lear site:http://intranet/somesite

This would encode to:

?k= King%20Lear%20site%3Ahttp%3A%2F%2Fintranet%2Fsomesite

and would restrict our search to a particular site (and subsites, actually – but close enough!)

This set me wondering, though – there is a URL managed property. Could I use this to restrict my search, rather than having an additional scope? Trying to restrict the search based on this didn’t seem to work very well. My results were… strange. I can’t figure out a logic, other than I was missing a lot of results. If anyone figures out what was going on, let me know.

So, the short is, I believe the above is a good way to restrict your results to a site. However, I can’t find an easy way of restricting results to a single list via a URL. I might have, if I’d spent longer looking!

Search a single Site

Search a single list, and don't use the OSSSearchResults.aspx page…

So, we’ve got a customer who’d hit the problem of the OSSSearchResults page that I’d mentioned before. To recap:

  • Global Searches in MOSS use a Search Center page for showing the results. These are nice, configurable, and can be made do quite a lot.
  • Contextual Searches (such as a particular list or site) use the standard WSS OSSSearchResults.aspx page. This isn’t nice and configurable, and changes will affect many sites.

Now, what would be great would be if we could have the contextual scope, but the global results page. Well, we can. Continue reading “Search a single list, and don't use the OSSSearchResults.aspx page…”

Search a single list, and don't use the OSSSearchResults.aspx page…

Redirect OSSSearchResults.aspx to another page

As promised yesterday, here’s some prototype code to redirect calls to OSSSearchResults.aspx to another page:

namespace SearchRedirector
{
    public class HTTPModule : IHttpModule
    {
        public void Init(HttpApplication context)
        {
            context.PreRequestHandlerExecute += new EventHandler(RegisterPreInitRequestHandler);
        }

        void RegisterPreInitRequestHandler(object sender, EventArgs e)
        {
            Page page = HttpContext.Current.CurrentHandler as Page;
            if (page != null)
            {
                page.PreInit += new EventHandler(page_PreInit);
            }
        }

        void page_PreInit(object sender, EventArgs e)
        {
            Page page = sender as Page;
            if (page != null)
            {
                if (page.Request.Url.AbsolutePath.Contains("OSSSearchResults.aspx"))
                {
                    page.Response.Redirect("/SearchCenter/Pages/results.aspx" + page.Request.Url.Query , true);
                }
            }
        }
        public void Dispose()
        {
        }
    }
}

This seems to work pretty well, although for some reason it’s tricky getting the debugging in Visual Studio to break into the code working consistently.

The guts of this is in the page_PreInit function, where we’re checking to see if the page is the OSS Search results, and if so, we redirect, passing the appropriate query string params.

Obviously, for a production system you’ll need to add a lot more configuration around this – what page(s) we’re forwarding to, what context(s) we should forward for, and so on. There are probably more efficient ways of checking if the page is an OSS results page than a string Contains() too.

Redirect OSSSearchResults.aspx to another page

Search Scopes and Site/List Context…

Came across an interesting problem from a customer – they’ve got a customised master page which doesn’t have ‘Site’ or ‘List’ level searches. They’ve got search scopes (such as ‘People’ or ‘Documents’ or ‘All Sites’), but across their entire SharePoint system. For example, this search:

will take us to our customised results page:

Note the Document Date column, and navigation breadcrumbs – these are custom.

The customer has added the search box web part to some pages, though, and this does display ‘Site’ or ‘List’ level scopes. Running a search against these scopes:

Takes us to this search page:

Yup, that’s the WSS3 standard search results page. You can see this in the So, can I change that?

Well… no. Proving that nothing is new under the sun, Mark Arend has a good post about this problem of contextual and custom search scopes. His explanation makes sense, too, but like he says, it doesn’t really justify the issue.

One option that he doesn’t mention is that you could use an HTTPModule to intercept the call to the OSSSearchResults page and forward it to our own custom results page. I might prototype that and post about it tomorrow.

Let’s hope that SharePoint vNext fixes this, ‘cos inconsistent search results depended upon contextual vs custom scopes will just confuse.

Search Scopes and Site/List Context…