10

I am using the JQueryUI Accordion control within a web part on a SharePoint 2010 site. The way I am using it is to have the content in the accordion panels held as individual pages which are then collated by javascript in the web part at run time to create the accordion.

This works well, but the issue I have is that in search results users are taken to the accordion source content pages rather than the accordion page itself. This is to be expected as the content is only pulled into the accordion page at run time.

Is there any way I can get search to index the accordion page itself rather than the source "panel" pages? I believe this is possible using Fast Search but unfortunately that isn't available to us. Is it possible to create a search rule which indexes content from a page as it appears in the browser rather than in the content database? Or any other suggestions to work around it?

Improve this question

3 Answers 3

Reset to default
2

Have you thought about adding code to detect the crawler and "unfurl" the accordion? For example you could look at the User Agent that is passed by the crawler.

Improve this answer
2
  • I'm not sure what you mean. The problem is that the search only crawls content which is available on the server whereas this page is only put together when it reaches the client. The SP search doesn't run the javascript on the page which pulls the content into the accordion. If I could detect the search User Agent wouldn't I still have the problem that I'd still have to somehow get the javascript to run in order to return the right content to the crawler?
    – Tim
    Jan 6, 2014 at 9:45
  • You would have to either make the page (or create a new page) that is more crawler friendly. You are correct that the crawler will not run the client code.
    – Matthew McDermott
    Jan 6, 2014 at 13:34
0

I don't know about how to change search, but even if you did, I expect the content page would still come up in results.

I think you should look at when a user has arrived directly at the content page (no parent or some other indication to the page that it is loaded from the accordion) and then redirect the browser to the accordion page with the appropriate section open. So to not have a bunch of content flashing to the user, you might be able to have the content page hide the text and only when on the accordion page does it do the work to unhide the content.

Improve this answer
1
  • We are considering something along these lines - probably drawing the accordion content from a list instead of separate pages and then adding either a redirect rule or some custom xslt on the search results page to take the user to the accordion page when something in the content list is returned by a search.
    – Tim
    Jan 6, 2014 at 9:51
0

For anyone who might be interested, the way I eventually solved this was to make three changes:

  1. I changed the content source for the accordion web part to be a list instead of a selection of pages
  2. I added a toolpart with a drop down of available content lists to the accordion web part which fired on ApplyChanges whenever a content source was chosen. When this ran it updated a column on the selected source list with the url of the web part in which that content was being used.
  3. I updated the search results page xslt to use the web part url instead of the list url whenever that content type came up in the results

The result of this is that the search results always go to the accordion page where the content is being displayed rather than the content list from which it is sourced.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.