Sitecore Native Wildcard Funktion

Struktur für Verwendung von Wildcard

Auf gewünschter Ebene kann in der Navigationsstruktur ein Item mit Namen: „*“ hinzugefügt werden. Damit das Abfangen der Requests funktioniert, ist es wichtig, dass der Name keine weiteren Zeichen enthält. Zur besseren Begrifflichkeit kann der DisplayName verwendet werden.

Alle Aufrufe welche über Catalog hinausgehen und kein anderes Item referenzieren, werden vom Wildcard Handler abgefangen. Bsp: http://sitecore.namics.com/de-CH/Catalog/Artikel_145792
Auf gleicher Ebene wie das WildcardItem können auch weitere Seiten angelegt werden.

Contentaufbereitung und Anzeige von Inhalten

Auf das Wildcard-Item können ein eigenes Layout und eigene Renderings gelegt werden. Im Rendering kann die Logik untergebracht werden um den Request auseinanderzunehmen und die entsprechen Ressource zu laden und anzuzeigen, oder was immer auch geschehen soll. Ein guter Tipp ist hierbei, die angeforderte Entität (Item, o.ä.) im HttpContext abzulegen, so kann immer wieder darauf zugegriffen werden (hilfreich bei Problemen mit dem LinkManager).

Probleme bei Verwendung von Wildcards

Bei der standartisierten Verwendung von Wildcards können zwei hässliche Fehler auftreten. Zu einem kann der LinkProvider bei der Auflösung der Sitecore Ressource von Requests welche von Wildcard abgefangen werden, diese nur bis zum letzten in der Solution abgebildeten Item zurückverfolgen – also bis zum „*“. Dies führt bei statischen Verweisen, wie zum Beispiel Language Selectoren, zu Weiterleitungen auf  http://sitecore.namics.com/de-CH/Catalog/,-w-.  Dadurch kann durch das entsprechende Rendering kein Inhalt aufbereitet werden und es wird einfach eine blank Page oder ein 404 angezeigt. Die Lösung für dieses Problem besteht im Überschreiben der LinkManager GetItemUrl Methode, siehe Infos dazu weiter unten.

Das zweite Problem besteht in der Verwendung von DisplayNames. Sobald bei einem ChildItem ein DisplayName hinzugefügt wurde, kann der Pfad nicht mehr aufgelöst werden und es wird ein 404 angezeigt. Dies ist ein Bug im Zusammenspiel zwischen dem Sitecore default itemResolver und der Wildcard Funktionalität. In diesem Fall hilft nur ein Ersetzen des ItemResolver Process durch einen eigenen Process. Weitere Infos dazu findest du ebenfalls weiter unten.

Umschreiben des LinkManagers

Zuerst muss der ursprüngliche LinkProvider mit einem neuen defaultProvider überladen werden. Dazu legt man am Besten eine eigene config mit folgendem Inhalt an:

 

Wichtig: nicht vergessen das Attribut defaultProvider vom alten LinkManager Provider in der SiteCore.config zu entfernen! Nachher beginnt das rewriting der eigenen GetItemUrl Methode, deren Klasse vom base LinkProvider abgeleitet werden muss. Alle Aufrufe auf gewöhnliche Site-Items werden ohne Umschweife an die native Methode des LinkProviders weitergeleitet, aber alle Anfragen auf Inhalte des Wildcard-Containers werden abgefangen. Die Requests werden in der Methode mit der Extension ergänzt und so wieder zu korrekten Verweisen zusammengesetzt.

Aus http://sitecore.namics.com/de-CH/Catalog/* soll wieder http://sitecore.namics.com/de-CH/Catalog/Artikel_145792 werden.

Dazu wird das ParentItem ausgelesen, in unserem Beispiel Catalog. Von dort wird über die LinkBuilder Methode GetItemUrl die soweit aktuelle URL geholt: http://sitecore.namics.com/fr-CH/Catalog
Nun müssen wir den gewünschten Artikel nur noch aus dem HttpContext auslesen, wo wir ihn zuvor abgespeichert haben und die Url um diesen ergänzen: http://sitecore.namics.com/fr-CH/Catalog/Artikel_145792
Wie gesagt, dieses Problem tritt nur auf, wenn eine geladene Wildcard-Ressource statisch bei Aufruf über den LinkManager manipuliert werden soll (zBsp: Mehrsprachigkeit) .

Custom ItemResolver bei Problemen mit DisplayNames

Dieser Bug ist wirklich unschön und seinetwegen muss der Sitecore Standard ItemResolver mit einer eigenen Klasse ersetzt werden.

In dieser Klasse muss der Process umgekehrt werden, so dass DisplayNames vorrangig aufgelöst werden. Im darunter abgebildeten Screenshot wurden die entsprechenden Conditions getauscht und die Funktion ResolveUsingDisplayName wird nun dritter Stelle aufgerufen. Des weiteren muss die gesamte GetSubItem Methode mit dem unteren Code Beispiel ersetzt werden.

Ansonsten kann die Standard Klasse des ItemResolvers kopiert werden.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>