PublishingpageImage: Using field value controls and edit mode panels to tweak your page rendering

When using a publishingpageImage in your pagelayout it displays a border of 1px at the side of your image. This is especially annoying when you want to display a second image next to it, and you can’t get it aligned perfectly.

Before you drive yourself nuts for hours like I did to find out where that pixel comes from look at the following post from ECM Team.

It shows that this pixel is caused by the “editing” field of the PublishingPageImage and you can avoid this by using the EditModePanel. This way you add it twice to your page, once where you want to display it (without the pixel!) and once where you want it to appear when editing the page.

<PublishingWebControls:EditModePanel runat=server id=”EditModePanelA” PageDisplayMode=”Display“>

<SharePointWebControls:FieldValue runat=”server” id=”RichImageFieldValue” FieldName=”PublishingPageImage”/>

</PublishingWebControls:EditModePanel>

<PublishingWebControls:EditModePanel runat=server id=”EditModePanelB” PageDisplayMode=”Edit“>

<PublishingWebControls:RichImageField ID=”RichImageField” FieldName=”PublishingPageImage” runat=”server”></PublishingWebControls:RichImageField>

</PublishingWebControls:EditModePanel>

Gr

Tom

0  

MOSS 2007 People search influenced by synonym list by user language and setting the rowlimit on a query greater than 50.

This post is an addition to my previous post about SharePoint people search.

While building a custom “CoreResultsWebPart” we noticed that some people were not being returned in our search results by the default search.

1) But when we searched it with our custom code it did return results.

2) When a french speaking collegue of mine searched using the same webpart he did get the result, but only when he logged into the machine, not just by signing into my IE Sharepoint.

When going to the SharePoint logs I found that the query did the following when I searched for “Leemans”:

<QueryID>0x231c0031</QueryID><RstCollection Count=”1″><RstTree><Rst Type=”Prob” Count=”3″><Rst

Type=”Synonym“><Occ>1</Occ><Keys Count=”4″><Key PID=”0x7fff7fff” len=”7″>0x00006c00650065, lee</Key><Key

PID=”0x7fff7fff” len=”13″>0x00006c00650065006d0061006e, leeman</Key><Key PID=”0x7fff7fff”

len=”19″>0x00006c00650065006d0061006e006e0065006e, leemannen</Key><Key PID=”0x7fff7fff”

len=”15″>0x00006c00650065006d0061006e0073, leemans</Key></Keys></Rst><Rst Type=”Synonym“><Occ>1</Occ><Keys

Count=”3″><Key PID=”0x7fff7fff” len=”7″>0x00006d0061006e, man</Key><Key PID=”0x7fff7fff”

len=”13″>0x00006d0061006e006e0065006e, mannen</Key><Key PID=”0x7fff7fff” len=”9″>0x00006d0061006e0073,

mans</Key></Keys></Rst><Rst Type=”And” Count=”1″><Rst

Type=”Unknown0x16777206″></Rst></Rst></Rst></RstTree></RstCollection>…
So the query automatically (also for out of the box Sharepoint people search!) used synonyms to change my queryterms.

After some Reflector work on the “SearchResultHiddenObject” class I found the following:

   1: try

   2:                 {

   3:                     if (!string.IsNullOrEmpty(this._QueryLanguage))

   4:                     {

   5:                         myRequest.Culture = new CultureInfo(this._QueryLanguage);

   6:                     }

   7:                     else if ((this.thisPage.Request.UserLanguages != null) &&

   8:  

   9: (this.thisPage.Request.UserLanguages.Length > 0))

  10:                     {

  11:                         myRequest.Culture = new CultureInfo(this.thisPage.Request.UserLanguages[0]);

  12:                     }

  13:                 }

\n

Which means if the param _QueryLanguage isn’t filled in, it used the users language which explains why my french speaking collegue did get results. The french synonym list wasn’t creating issue’s, nor was the english one, just dutch.\n

By adding the following code to my already custom webpart I could set the parameter and garanty that each user use the same, english synonym list.\n

+ I added some code so the maximum returned results by a query isn’t limited to 50.

\n

\n

   1: public class xxxwebpart: CoreResultsWebPart

   2:  

   3: {

   4:  

   5: ....

   6:  

   7: protected override void SetPropertiesOnHiddenObject()

   8:  

   9: {

  10:  

  11: base.SetPropertiesOnHiddenObject();

  12:  

  13: // Get Reflection info

  14:  

  15: object srho = this.GetType().InvokeMember("srho", BindingFlags.GetField | BindingFlags.Instance | BindingFlags.NonPublic, null, this, new object[] { });

  16:  

  17: Type type = srho.GetType();

  18:  

  19: //Set RowLimit

  20:  

  21: type.InvokeMember("_ResultsRequested", BindingFlags.SetField | BindingFlags.Instance | BindingFlags.NonPublic, null, srho, new object[] { ((short)1000) });

  22:  

  23: //Set Query Culture to en-GB to use this synonym list which causes no problems

  24:  

  25: type.InvokeMember("QueryLanguage", BindingFlags.SetProperty | BindingFlags.Instance | BindingFlags.Public, null, srho, new object[] { "en-GB" });

  26:  

  27: // Allow the query to be reissued

  28:  

  29: type.InvokeMember("ForceRerun", BindingFlags.InvokeMethod | BindingFlags.Instance | BindingFlags.Public, null, srho, new object[] { });

  30:  

  31: }

  32:  

\n

Seeing as the dutch synonym list was not changed but default, I think we can assume all the out of the box people searches for Dutch users will sometimes give no results because of the synonym use…\n

As a quick fix for users that don’t use a custom CoreSearchResults webpart I’ve created a simple webpart called SearchQueryOptionsWebPart that does 2 things:\n

– Sets the culture for the query so you can determine per page which Culture (read which synonymlist) should be used by all users.\n

– Sets the rowLimit for the query to return. I’ve noticed that a lot of people are also looking for an easy way to increase this above the hard limit of 50.\n

You can find the sourcecode here.\n

Just install the wsp, activate the site collection feature “MOSS2007 Search Query Options WebPart (SQOW) ” and add the webpart to any search result page where you want to set the options.\n

The default for the options are “en-GB” and 1000 (rowlimit) but you can change these easily in the webpart properties.\n

\n

Gr\n

Tom

0  

MOSS 2007 People wildcard search webpart and refine your results.

I’ve been searching for a good way to use wildcard search in combination with people search (SharePoint User Profiles) and have found a few but not 100% what I was looking for.

My colleague Steven has found a solution for wildcard search which is pretty much the same as the Codeplex solution and DotNetMaffia solution for this problem.

My problem was that these solutions are designed for wildcard content search and not specifically for people search. Normally you’d perform a people search in SharePoint by using the “People Search Core Resuls webpart” which includes some nice people specific features such as:

– Refine your search (by example refine by job title)

– Sort by social distance

– …

Now all the wildcard search solutions I’ve come across don’t include these features because they all extend the “ CoreResultsWebPart “ instead of the “ PeopleCoreResultsWebpart “ and there is a very good reason for this, being that that class is sealed so you can’t extend it!

Now in my case I just need the “refine your search” feature + I only want to search the people scope so I’ve made some adjustments to Steven Van de Craen’s original wildcard search solution.

By looking at the sealed class from the “ PeopleCoreResultsWebpart “ I found and included the methodes required for the refine feature (CollectRefinementData – SortRefinementDataForColumn – SetSortedRefinementDataOnHiddenObject – GetXPathNavigator). And off course I fixed the scope to only search for people.

So now I have all the functionality I need by simply extending the “CoreResultsWebPart”.

You can find an example of the code here as the methods are just too much to post here. Of course you can always Reflector the “PeopleCoreResultsWebPart” if you need any of the other functionality’s, it probably won’t be easy as I haven’t come across someone who reverse engineered the entire webpart.

Hope this helps someone out, I’m sure glad I figured it out so I didn’t have to choose between wildcard search or my nice people search functionality’s.

Gr Tom

0