Tag Archives: Search

Crawling Publishing Images in SharePoint 2010

6 Jun

Publishing images cannot be used as crawled/metadata properties, you will only get empty results. The problem with this is that you may want to use images with search as a rollup for information using XSLT. There are a few tricks that you can do to get this data.

  1. Add another site column to the content type that is plain text and get the user to add the URL in. This can then be set up as another metadata property. This isn’t a very good option however as you don’t want the users having to fill in two columns for the same information.
  2. Add another site column to the content type that is plain text. You can then add an event receiver which grabs the URL from the publishing image and places it as plain text in the new site column. This can then be set up as a metadata property. This way isn’t a very clean way of getting the data as we need an additional field, and now some extra code that needs to run when we save the item just to get an image.
  3. Use page code behind to add a Meta tag in the header section of the page to hold the information we want to crawl. This option is quick and easy to implement if you have code behind.
  4. If code cannot be used you can add a Meta tag into the header section of the page layout itself. You can then read out the value of the publishing image into the meta tag content. This is the easiest solution as it requires three lines of code added into the page layout itself, so nothing compiled.
I am going to go through setting up step 4 as it is a really easy way of getting around this issue without any code, event receivers or additional fields.Assumptions:

  • You have a working Page Layout that you can edit
  • You have access the the Search Service Application
  • You have access to the search page to update the xslt

Adding the Meta Tag into the Header

  1. Edit your page layout in advanced mode in SharePoint designer, or open in visual studio
  2. View the page layouts aspx code and add the following head section below PlaceHolderPageTitle
    <asp:Content ID=”PageHead” ContentPlaceHolderID=”PlaceHolderAdditionalPageHead” runat=”server”> </asp:Content>
  3. Add the following meta tag in the new PlaceholderAdditionalPageHead. You will need to change the FieldName to the GUID of the publishing image field. If you don’t know the GUID, an easy way of getting this is to drag the field onto the page from the tool box under SharePoint controls > Content Fields.
    <meta name=’PageImageURL’ content='<SharePointWebControls:FieldValue  FieldName=”3de94b06-4120-41a5-b907-88773e493458” runat=”server” id=”ImageFieldUrl”/>’ id=”imageMeta” />
    Your code will look like:
  4. Save the changes.
  5. If you are using SharePoint designer go back out to the Page Layouts list and check in the new changes, publishing as a major version. You will then need to approve the changes to the Page Layout in the Master Page Gallery
  6. If you are using visual studio you will need to package the wsp and do an update
  7. Go to a page that is using the page layout and view the source. You will see a new meta tag with the image value in there

Setting up Search

  1. A crawl will have to be run before we can pick up the crawled property. Go into the search service application > Content Sources and run an incremental crawl.
  2. Once the crawl is complete go into MetaData Properties on the left hand menu under Queries and Results
  3. Click on Categories then Web. The meta tag we set up should be in here under PageImageUrl – the name we gave the meta tag itself
  4.  Now that we know the property has been crawled we can set up a metadata property which we can use with our XSLT.
  5. Go to Metadata Properties on the left hand menu and click on New Managed Property. Add the name you want the property to have, leave it as text, add a mapping to the crawled property “PageImageUrl” and allow it to be used in scopes.
  6. Run a full crawl to populate the new metadata property

Setting up the XSLT for the new property

  1. Go to the search page where the image needs to be shown and edit the Search Core Results web part.
  2. Edit the web part and add the following column to the Fetch Propertys
    <Column Name=”PageImageUrl”/>
  3. Edit the XSLT being used, either here in the web part by clicking XSL Editor, or in visual studio if you are deploying the XSLT
  4. Under the template where you want to display the image, add a variable
     <xsl:variable name=”pageimageurl” select=”testpageimageurl”/> 
    Then add in the code to display the image. We need to disable output escaping as the data we are grabbing is html, not just plain text. This will ensure the image gets displayed correctly
    <xsl:value-of select=”$pageimageurl” disable-output-escaping=”yes”/>
     
  5. Save the page.

You can now see the image that was saved in your results.

Advertisements

URL Rewriting and Anonymous Access with SharePoint – Part Five

23 Mar

Other Exceptions – Search and XSLT with Rewriting

There are some cases where the link will still be the full URL, if a user sets a link to “http://geeksinsuits.com/ca/pages/default.aspx” only the URL will be overwritten, not the actual text itself. So users need to name hyperlinks appropriately in a way that represents where the link is going, and not set the link text to the URL itself. An example of this would be using “About us” instead of “http://geeksinsuits.com/ca/pages/aboutus.aspx

In some cases this is unavoidable such as for search results. The XSLT will be using the actual page URL as the link text. The easiest way to get around this is by adding some JavaScript.

This post assumes that there is a search service application set up, the server standard site features have been enabled and there is a search page that is bringing back page results.

Search Core Results and Rewriting

There are a couple of tricks with search that might need to be configured. Firstly if your anonymous users cannot see search results (nothing shows up) and you can when your logged in you might not have set the right permissions on the extended site.

  1. Go to IIS
  2. Go to Geeks In Suits Public (or your extended internet site)
  3. Double click on Authentication
  4. Right click Anonymous Authentication and click Edit
  5. If the radio button has Specific User selected change it to Application pool identity. This got me earlier…

Secondly if you are using a search core results web part and are getting a 404 error when searching the page you may have to change the scopes drop down mode.

Edit the Search Box web part and set the Scopes Dropdown to “Do not show scopes dropdown, and default to target results page”. If this isn’t set an extra query string will be added onto the URL like below, this will result in a 404 error.

http://geeksinsuits.com/CA/Search?k=searchterm&cs=This%20Site&u=http%3A%2F%2Fgeeksinsuits.com%2FCA

XSLT

Most XSLT templates will show hyperlinks where the text is the URL. What we need to do to get around this is change the link on the client side as IIS cant change this content for us. We will step through making some changes to the standard search core results xslt. The same changes can apply to any XSLT however, you just need to add some JavaScript and call it via a template.

  1. The standard search XSLT shows the link text at the bottom of each result like below. We want this URL to look like the address bar in the browser
  2. Edit the Search Core Results web part
  3. Edit the XSLT by clicking on XSL Editor under Display Properties. If you cant do this untick User Location Visualisation.
  4. If you have another text editor i suggest copying this out to there for editing
  5. Find <xsl:template match=”Result”> (should be line 206)
  6. After the end of this template (line 415) add the below template and javascript. We will be able to call this template from anywhere in the XSLT<xsl:template name=”ReWriteURL”><xsl:param name=”currentId” /><script type=”text/javascript”>

    <xsl:comment>

    var id = ‘<xsl:value-of select=”$currentId” />’;

    UpdateFriendlyURLS(id);

    // javascript for replacing hyperlinks innertext to friendly urls, but only based on the url

    // that has already been set, so it doesnt matter if it has been re-written or not

    function UpdateFriendlyURLS(id)

    {

    var obj = document.getElementById(id);

    if (obj != null)

    {

    obj.innerHTML = obj.href;

    }

    }

    </xsl:comment>

    </script>

    </xsl:template>

  7. Now we need to call the template after the result has been read out. Just before the result template ends add the template call for the javascript (just before line 415), this will pass in the ID of the current result link and change the URL text.<xsl:call-template name=”ReWriteURL”><xsl:with-param name=”currentId” select=”concat($currentId,’_URLlink’)”/></xsl:call-template>
  8. Now all we need is a hyperlink that has the right ID for our JavaScript to grab and change. In the standard Search Core Results XSLT there are two places, line 274 and line 389.
  9. Delete the <xsl:choose> node so there is only an empty span
  10. Replace both instances of this code with the following<a href=”{$url}” id=”{concat($currentId,’_URLlink’)}”> <xsl:value-of select=”url”/> </a>
  11. If you had edited the code elsewhere copy this back into the XSL Editor on the web part, press save
  12. OK on the web part properties window
  13. Save and publish the page
  14. Now go to the page anonymously via the internet extended site, the URL text will be re-written like the rest of the page

Cool, what now? Next Post… (Summary yay!)