Page Editor – Chrome Data erweitern

Der WYSIWYG-Editor von Sitecore bietet einem Autor ein sehr exklusives Werkzeug für die Bearbeitung seiner Seite. Diese Werkzeuge sind out of the Box sehr umfangreich und bieten dem Benutzer viele Informationen und Hilfsmittel für die Pflege des Seiteninhaltes. In diesem Beispiel zeigen wir, wie die Standard-Titel-Anzeige bei Renderings und einzelne Felder erweitert und über den PageEditor bearbeitet werden können. Weiterlesen

Neu! Sechs zertifizierte Entwickler mehr!

Wir gratulieren den sechs „Sitecore Certified Professional Developers“. Ende letzten Jahres nahmen rund sechs Software Engineers die Herausforderung an und bestanden mit Erfolg! Soeben erhielten wir die offiziellen Zertifikate! Neben den bereits erfolgreich absolvierten Projekten ist dies ein weiterer Meilenstein für unser … Weiterlesen

Eigene Berechtigungen erstellen

Das Zuweisen von Berechtigungen ist in Sitecore, wie in den meisten anderen Content Management Systemen eine grundlegende Funktion. Enwickler sollten keine redaktionellen Inhalte verändern, SEO Spezialisten lediglich suchmaschinenrelevante Informationen befüllen und Redakteure einen exklusiven Freigabemechanismus besitzen. Von Sitecore 6.6 auf … Weiterlesen

MultilistField in Kommunikation mit WebServices

Die Datenfelder von Sitecore besitzen stets einen Fokus: Items. Nur was ist, wenn ich auf Funktionen eines weiteren Dienstes zugreifen möchte, ohne dies als Itemstruktur im Sitecore zu besitzen?

Dieser Wunschgedanke kommt je nach Anforderung schnell auf. Beispielsweise wenn ich ein explizites YouTube Video aus meinem Channel selektieren möchte oder auf nicht redaktionelle Listen, welche ich später im Code weiterverarbeiten möchte. Die Grenzen hierfür sind unendlich und gehen von einer einfachen XML-Datei bis hin zu SOAP, REST-Services oder andere properitäre Schnittstellen, welche man anbinden möchte.
(mehr …)

Dynamische Informationsarchitektur mittels Dataprovider

Informationsarchitektur Dataprovider

Klassische Informationsarchitekturen mit einer klaren Strukturierung 1st, 2nd, 3rd, usw. Level Navigation funktioniert bei dynamischen Angeboten nur bedingt. So ist z.B. ein Produkt unter verschiedenen Kategorien aufzufinden. Hierbei gestaltet sich die Pflege sehr umständlich wenn z.B. für das gleiche Produkt … Weiterlesen

„Publishing-Status“ im Content-Editor anzeigen

Anzeige der Warnung im Content-Editor

Standardmässig ist im Sitecore-Content-Editor nicht ersichtlich, welche Items bereits publiziert wurden und welche nicht. Mit ein wenig Programmieraufwand kann man jedoch übersichtliche Anzeigen erstellen, welche den „Publizierungs-Status“ für jedes Item direkt darstellen. Weiterlesen

Sitecore-Tasks automatisieren mit Sitecore PowerShell Console

Einleitung/Motivation

Sitecore PowerShell Console ist ein Sitecore-Modul aus dem Sitecore-Marketplace (Link zum Modul), welches eine PowerShell-Umgebung im Sitecore-Backend zur Verfügung stellt. Sitecore-Administratoren wird mit dem Modul ein mächtiges Werkzeug in die Hand gelegt, um beispielsweise Aufgaben zu automatisieren, die „von Hand“ mühsam durchzuführen wären. (mehr …)

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.

(mehr …)

Sitecore Lock and Edit und Erstellen neuer Version unterdrücken

Ist ein User bei Sitecore nicht Administrator, muss er standardmässig jedes Item, das er bearbeiten möchte, mittels „Lock and Edit“ auschecken und nachdem er mit dem Bearbeiten fertig ist, wieder einchecken. Zusätzlich wird mit jedem Lock and Edit eine neue Version erstellt.

Lock and Edit in Sitecore

Diese Standardfunktion ist insbesondere bei grossen Content-Teams mit zahlreichen Editoren und dedizierten Workflows sehr hilfreich. Bei kleineren Teams kann dieses Feature aber zu unnötigem Mehraufwand führen, da selten mehr als ein Autor im System arbeitet. (mehr …)

Sitecore – Frontend Integration mit Terrific / Terrific Composer Teil 4

Terrific Composer Struktur

Die Struktur im Terrific Composer sieht leicht anders aus als im Terrific wie oben beschrieben. Für den Start mit dem Terrific Composer kann man alle Folder ignorieren bis auf den „/src“ Folder, darin ist sämtlicher Code für unser Frontend enthalten. Für den Frontendengineer ändert sich nichts, er kann sich normal ein Composer Projekt aufsetzen wie er es kennt. Einzige Anpassung ist die, dass im Verzeichnis „web“ ein Folder „assets“ erstellt werden muss für unseren JS- und CSS-Handler. Weiter werden in diesem „assets“-Folder auch zusätzliche Elemente wie die fonts oder images angelegt.

SVN Externals für Composer Projekt

Wie das Erstellen von SVN Externals funktioniert, wissen wir nun ja. Für ein Composer Projekt müssen diese wie folgt erstellt werden. Dies passiert wieder auf dem übergeordneten Folder, sprich bei einer Einzelseite z.Bsp. auf dem Projekt Kundenname.WebApp.

Path URL Bemerkung
Layouts https://svn-url/projektname/…/src/Terrific/Composition/Resources Baselayout, CSS/JS Libraries
Modules
(Views bei MVC Projekt)
https://svn-url/projektname/Terrific/trunk/src/Terrific/Module Alle Module/Komponenten inkl. JS, CSS, LESS
Assets https://svn-url/projektname/Terrific/trunk/web/assets Alle Bilder, Fonts, Handler für JS und CSS

 

Wichtig: als nächster Schritt muss auf der WebApp ein SVN Update gemacht werden. Hier werden nun diese Folder in unserer Solution erstellt/hinzugefügt und anschliessend kann die Solution Commitet werden.

Die Handler für den Composer wurden leicht angepasst. Die Files für den CSS-Handler müssen in der richtigen Reihenfolge hinzugefügt werden, z.Bsp.

1
files.Add(GetLayoutFile("reset"));

Die Methode „GetLayoutFile“ holt sich aus dem Framework den entsprechenden RootPath und baut sich mit dem jeweiligen Filenamen die CSS Files in eine Liste.

1
2
3
4
private string GetLayoutFile(string pFileName)
{
return string.Format("{0}/Layouts/public/css/{1}.less", FrontendFileHandler.RootPath, pFileName);
}

Für den JS-Handler gibt es im Vergleich zur Terrific Integration keine grossen Unterschiede, nur dass die Pfade entsprechend angepasst werden müssen, hierzu ein Beispiel für die Methode „GetContent()“:

1
2
3
4
5
sb.Append(FrontendFileHandler.ReadFile("/Layouts/public/js/jquery-1.8.3.min.js", true));
sb.Append(FrontendFileHandler.ReadFile("/Layouts/public/js/terrific-2.0.1.min.js", true));
sb.Append(FrontendFileHandler.ReadDirectory("/Layouts/public/js/statics"));
sb.Append(FrontendFileHandler.ReadDirectory("/Views"));
sb.Append(FrontendFileHandler.ReadFile("/Layouts/public/js/bootstrap.js", true));

Sitecore – Frontend Settings
Für das Laden des aktuellen oder gewünschten Frontendfiles (JS und CSS) haben wir im Sitecore ein Template erstellt, welches bei der Site, dem jeweiligen Mandanten oder in einer allgemeinen Configuration Section platziert ist erstellt. Gemäss Frontendhandler haben wir hier die Möglichkeit, die Files dynamisch bei jedem Laden oder statisch zu holen (Checkbox „static“). Während der Entwicklungsphase ist es sinnvoll, beim Aufruf den Parameter „debug=true“ zu setzen, damit keine Komprimierung stattfindet und den Browser Cache zu deaktivieren (Checkbox „debug“). Damit beim Kunden sicher das aktuellste File geladen wird, haben wir dem Filepfad noch den Assembly-Key hinzugefügt – bei jedem Deployment wird gemäss Konzept die Assembly-Version aktualisiert. Wenn nur CSS oder JS Anpassungen stattgefunden haben, kann auch nur das Item „Version Key“ erhöht werden, damit ein aktuelles File geladen wird. Je nach Website (Mandanten z.Bsp.) benötigen wir einen Root Folder Prefix für die Frontend-Themen oder bei 2 Websites (Mandanten) mit den selben Funktionen, jedoch unterschiedlichen Farben kann gut mit Skins gearbeitet werden.

Vorteile/Nachteile – Mehrwert für Projekt

Ein Vorteil für ein Projekt ist sicher der, dass es keine Missverständnisse mehr gibt, welches CSS, JS oder Frontendtemplate aktuell ist – denn es gibt nur einen Stand. Die HTML-Files, in unserem Falle die phtml-Templates sind so an der korrekten Stelle im Projekt und können dann direkt in ein UserControl umgewandelt werden. So benötigt der Software Engineer keine lokale Terrific Installation oder Zugriff auf den Terrific-Staging – so kann das Markup direkt aus dem phtml verwendet werden. Die Filehandler können beliebig erweitert werden bei Bedarf und können aus dem Framework für alle Projekte verwendet werden – somit besteht ein geringer Projektsetup.

Next Steps und Ausblick

Für unsere Sitecore Projekte werden wir in Zukunft eine abgespeckte Terrific Version einsetzen, diese nennt sich Terrific Micro und ist massiv schlanker als das ursprüngliche Terrific. Hierfür wurde ein „Frontend Handler 2.0“ entwickelt welchen wir demnächst präsentieren werden.

Vorinformation von Mark Lowe zu dieser überarbeiteten Version:

„Überarbeitete Version vom bewährten Terrific Handler (JS / CSS) mit Performance-Verbesserung, voller LESS Unterstützung + Terrific Micro Unterstützung.“

Funktionen:

– Zusammenführen der verstreuten Files
– Reihenfolge welche in einem JSON File definiert sind einhalten
– Komprimieren
– Caching Serverseitig
– Browser Caching