sitecore
Sök

Anmärkningar

Konfiguration

Sitecore levereras med en uppsättning standardindex förkonfigurerade som du kan utöka, eller du kan definiera dina egna. Av de förkonfigurerade är sitecore_master_index & sitecore_web_index av mest intresse för din webbplatssökning. Dessa är de fördefinierade indexen för alla dina Sitecore-objekt i trädet i dina master- och webbdatabaser respektive och är konfigurerade för att lagra alla standardfält för ett Sitecore-objekt som kommer att vara vanliga bland alla mallar.

Du kan titta på denna konfiguration av standardwebindexet på den här platsen: <Your Site>\App_Config\Include\Sitecore.ContentSearch.Lucene.Index.Web.config

De viktigaste områdena av betydelse för ett indexs konfiguration är:

• Fältkonfigurationen - Vilka fält ska lagras i indexet och hur de ska lagras.
• Strategin - Hur och när ska indexet uppdateras.
• The Crawler - platsen där indexet kan få sitt Sitecore-data

Fältkonfiguration

Om du tittar på sitecore_web_index konfigurationen kan du se följande referens: <configuration ref="contentSearch/indexConfigurations/defaultLuceneIndexConfiguration" /> . Detta hänvisar till en delad indexkonfigurationsfil som hittas här: <Your Site>\App_Config\Include\Sitecore.ContentSearch.Lucene.DefaultIndexConfiguration.config . Här kan du se alla fält som ingår i standardkonfigurationen.

Det finns i princip två sätt att definiera ett fält: antingen kommer fältet direkt från ett Sitecore-objektfält, eller så är det ett datorfält. Ett datorfält låter dig skriva en kod för att göra några beräkningar och lagra resultatet i fältet. Denna kod kommer att köras när indexet är byggt / uppdaterat, inte när indexet fråges. Detta är särskilt användbart om fältet behöver lagra aggregerade data, till exempel räkningar etc.

Inom <fieldMap> -elementet ser du elementen <fieldNames hint="raw:AddFieldByFieldName"> & <fields hint="raw:AddComputedIndexField"> , som innehåller de respektive fälten direkt och de beräknade fälten.

Strategi

Strategin för ditt index avgör när ditt index ska uppdateras. Det finns följande alternativ att välja mellan:

• OnPublishEndAsynchronousStrategy (onPublishEndAsync) - När ett objekt publiceras kommer indexet att uppdateras asynkront.
• SynchronousStrategy (syncMaster) - När ett objekt är sparat kommer indexet att uppdateras direkt och synkront.
• IntervalAsynchronousStrategy (intervalAsyncCore / intervalAsyncMaster) - Kontrollera regelbundet för artikeluppdateringar och uppdatera indexet asynkront
• ManualStrategy - Inga automatiska indexuppdateringar. Index kommer bara att uppdateras manuellt (via kontrollpanelen eller programmatiskt)
• RebuildAfterFullPublishStrategy (ombyggnadAfterFullPublish) - Efter en publicering kommer indexet att byggas om i sin helhet
• RemoteRebuildStrategy (remoteRebuild) - Denna strategi är för flera instanser av Sitecore. Till exempel, om en ombyggnad krävs från innehållshanteringsservern, kommer de fjärrinnehållsservrarna att prenumerera på den här händelsen och bygga om sina egna index.

Som standard är syncMaster konfigurerat som syncMaster . Det beror på att om du är i erfarenhetsredigeraren som sparar objekt och visar på sidan visar resultaten av ett index, vill du se ändringar du har gjort på objekt omedelbart i resultaten. Webbindexet är konfigurerat som 'onPublishEndAsync', det beror på att indexen för din webbdatabas endast behöver uppdateras när objekt publiceras från huvuddatabasen till webben.

Du kan också kombinera flera strategier. Om du till exempel har separata Sitecore-instanser för din innehållshantering (CM) & innehållsleverans (CD), skulle det vara meningsfullt att kombinera onPublishEndAsync med remoteRebuild , så att CD-indexen uppdateras när artiklar publiceras och ombyggs när en användare utlöser en ombyggnad från CM-serverns kontrollpanel.

Du kan välja din strategi med följande konfigurering:

<strategies hint="list:AddStrategy">
    <strategy ref="contentSearch/indexConfigurations/indexUpdateStrategies/onPublishEndAsync" />
</strategies>

The Crawler

Detta gör att du kan ange platsen för de Sitecore-data som du vill indexera. Webbindexet har följande standardkonfiguration:

<locations hint="list:AddCrawler">
    <crawler type="Sitecore.ContentSearch.SitecoreItemCrawler, Sitecore.ContentSearch">
        <Database>web</Database>
        <Root>/sitecore</Root>
    </crawler>
</locations> 

De två viktiga bitarna är elementen <Database> och <Root> . Elementet <Root> låter dig ange startpositionen i ditt Sitecore-träd som indexet ska indexera. I verkligheten har du troligen en "Hem" -nod under innehållsnoden som du pekar på detta så att den bara indexerar faktiskt innehåll / sidor snarare än dina mallar etc.

Skapa ett inkommande filter för sökningen

Inkommande filter tillämpas när objekt läggs till i sökindexet och gör det möjligt att specificera om objektet inkluderas i indexet eller inte.

Exempel när inkommande filter kan användas - inkludera inte standardvärden och tidigare versioner av objektet i indexet.

Inkommande filter ställs in i konfiguration:

<indexing.filterIndex.inbound>
 <processor type="Sitecore.ContentSearch.Pipelines.IndexingFilters.ApplyInboundIndexFilter, Sitecore.ContentSearch"></processor>
</indexing.filterIndex.inbound>  

Kodimplementering:

public class ApplyInboundIndexVersionFilter : InboundIndexFilterProcessor   
{        
    public override void Process(InboundIndexFilterArgs args)       
    { 
        var item = args.IndexableToIndex as SitecoreIndexableItem;

        if (!item.Item.Versions.IsLatestVersion())            
        {                  
            args.IsExcluded = true;            
        }
    }
}

Fler exempel och information kan hittas på http://www.sitecore.net/learn/blogs/technical-blogs/sitecore-7-development-team/posts/2013/04/sitecore-7-inbound-and-outbound- filter-pipelines.aspx

Skapa ett utgående filter för sökningen

Utgående filter kan användas för att filtrera sökresultaten.

Ett av exemplen på utgående filteranvändning är att ta bort objekt som användaren inte har tillgång till från sökresultaten.

Utgående filter ställs in i konfigurationen:

<indexing.filterIndex.outbound>
 <processor type="Sitecore.ContentSearch.Pipelines.IndexingFilters.ApplyOutboundSecurityFilter, Sitecore.ContentSearch"></processor>
</indexing.filterIndex.outbound>

Exempel på implementering av utgående filter:

public class ApplyOutboundIndexWorkflowFilter : OutboundIndexFilterProcessor   
{        
    public override void Process(OutboundIndexFilterArgs args)       
    { 
        //You can use args.IsExcluded to remove items from the search results here
    }
}

Fler exempel och information kan hittas på http://www.sitecore.net/learn/blogs/technical-blogs/sitecore-7-development-team/posts/2013/04/sitecore-7-inbound-and-outbound- filter-pipelines.aspx

Ta bort alla tidigare versioner av objektet i indexet när du lägger till en ny version

Som standard lägger Sitecore till alla versioner av objektet till sitecore_master_index. Nackdelen med det är att om användare använder arbetsflöden och lägger till massor av versioner kommer alla att läggas till i sökresultaten i innehållsredigeraren.

Konfiguration:

<event name="item:versionAdded" >
              <handler type="FilterPatch.Library.ContentSearch.EventHandler, AssemblyName" method="Execute" />
       </event>

Implementering av hanteraren

public class EventHandler
    {
        public void Execute(object sender, EventArgs eventArgs)
        {
            var item = Event.ExtractParameter(eventArgs, 0) as Item;

            //If item has less than 2 versions - then skip
            if(item.Versions.Count < 2)
            {
                return;
            }

            var indexableItem = new SitecoreIndexableItem(item);

            var index = ContentSearchManager.GetIndex(indexableItem);

            using (var context = index.CreateDeleteContext())
            {
                foreach(var version in item.Versions.GetVersions(true))
                {
                    if(!version.Versions.IsLatestVersion())
                    {
                        var indexableItemVersion = new SitecoreIndexableItem(version);
                        context.Delete(indexableItemVersion.UniqueId);
                    }
                }
                context.Commit();                
            }
        }
    }