Site Templates gehören praktisch zu jeder SharePoint Lösung. Sobald man zwei Sites mit derselben Struktur erstellt, kommt der Ruf nach Templates Microsoft hat verschiedene Möglichkeiten vorgesehen, mit denen man SharePoint Site Templates erstellen kann. Wie immer im SharePoint Business, hat jede Variante ihr Vor- und Nachteile. Nachfolgend möchte ich euch einen Überblick und ein paar Erfahrungen aus dem Projektgeschäft der isolutions AG mitgeben.
Zuerst definieren wir, was SharePoint Site Templates abdecken sollen.
- Complete: Das SharePoint Template deckt sämtliche Bereiche einer SharePoint Site ab. Neben Listen und Document Libraries werden nach die Views, die Web Parts, die Workflows und die Navigation übernommen.
- Clickable: Power User können Site Templates im Web zusammenklicken.
- Deployable: Site Templates können über verschiedene Site Collections und SharePoint Farms verteilt werden.
- MUI enabled: Die Mehrsprachigkeit von SharePoint funktioniert in den Site Templates.
- Publishing enabled: Die Publishing Features sind aktiviert.
- Updateable: Änderungen können auf bestehende Sites appliziert werden.
- Upgradable: Beim Upgrade auf die nächste SharePoint Version sollen die Templates weiterverwendet werden können.
Save As Template
Die Option “Save As Template” in den Site Actions erlaubt es einem Power User eine bestehende SharePoint Site als Template abzulegen. Dabei wird ein WSP Paket erstellt, welches als Sandbox Solution auf der aktuellen Site Collection deployt wird. Während die Site schnell erstellt ist, sind einige Anforderungen nicht abgedeckt.
Das Site Template enthält nicht alle Konfigurationen der Site. Gewisse Web Part Properties oder die Navigation werden nicht immer übernommen. Die Mehrsprachigkeit geht verloren und auf Publishing Site steht die Option nicht zur Verfügung. Auch gestaltet sich das Deployment auf mehrere Site Collection bzw. verschiedene SharePoint Farmen als schwierig.
Import WSP in VIsual Studio
Das von “Save as Template” generierte Template lässt sich in Visual Studio importieren und kann hier weiterbearbeitet werden. Leider kommen dabei eine Menge SharePoint Items mit, welche gar nicht verwendet werden. So sind z.B. alle Out of the Box Site Columns vorhanden. Weiter fehlt die Mehrsprachigkeit – die Ressourcen werden hardcoded eingefügt – und die Möglichkeit, Site mit Publishing Feature so zu importieren.
Bevor man das WSP weiterbearbeitet, müssen diese nicht genutzen Elemente bereinigt werden. Danach verfügt man aber über ein Paket, welches sich als Farm Solution deployen lässt und somit auf verschiedenen Site Collection und SharePoint Farmen deployt werden kann. Da das Überarbeiten des importierten WSPs viel Zeit in Anspruch nimmt, wird dieser Schritt meist nur einmal ausgeführt.
Site Definition
Mit Visual Studio kann eine eigene Site Definition erstellt werden. Dabei wird die Konfiguration der Site im ONET.XML abgebildet. Dieser Ansatz ist anspruchsvoll und verursacht Probleme beim Upgrade. Mittlerweile rät sogar Microsoft vom Erstellen von Custom Site Definition ab. Lasst uns diesen Rat befolgen.
Customizations als Features
Mit Features kann jede beliebige Einstellung einer Site verändert werden. Der Code wird nach der Erstellung der Site ausgeführt und verändert die Site nach den Vorgaben. Aufgeteilt in mehrere Features und aufgerufen mit verschiedenen Konfigurationen können damit viele Anforderungen abgedeckt werden. Damit die Users auf neu erstellen Sites die Features nicht manuell aktivieren muss, müssen die Features entweder auf bestehende Templates gestapelt werden oder aber die Sites mit einem eigenen Mechanismus erstellt werden.
Jede zusätzliche Einstellung erfordern aber Anpassungen am Code. Der Power User kann seine Änderungswünsche nicht selbst umsetzen. Dafür können – mit entsprechendem Code – bestehende Sites angepasst werden.
Web Templates
Mit SharePoint 2010 kamen auch die Web Templates. Leider ist diese Möglichkeit bis heute in der SharePoint Welt relativ unbekannt. Web Templates werden auch in Visual Studio erstellt und als WSP deployt. Ein Web Template leitet von einer Out of the Box Site Definition (z.B. Team Site) ab und definiert nur die Änderungen. Es bestehen aus einem Elements.xml, welches Name, Beschreibung und Ableitung enthält sowie einem minimalen ONET.XML mit dem “Configuration” Node. Darin wird angegeben, welche Listen und Document Libraries erstellt werden und welche Features geladen werden. Änderungen müssen also auch grösstenteils als Feature implementiert werden, dafür können neue Sites über den normalen “Create Site” Dialog erstellt werden.
Ein neues Web Template wird erstellt, in dem ein neues “Empty SharePoint Element” hinzugefügt wird.
Das Elements.xml enthält die Informationen, von welcher Site Definition abgeleitet wird und wie das neue Template heisst. Wichtig ist, dass das Attribute "Name” denselben Wert trägt wie das SharePoint Element (siehe oben).
Als Beispiel habe ich das ONET.XML der Team Site aus C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\SiteTemplates\sts\xml kopiert und alles bis auf das Configuration mit ID = 0 gelöscht.
Die Web Templates erfüllen auch nicht alle Bedinungen: User können sie nicht selbst ändern und sie sind nicht updatable. Dafür ist die Enterprise readiness gegeben: die Funktionen lassen sich als Features aufteilen, die Mehrsprachigkeit und die Publishing Features werden unterstützt und ein Upgrade auf SharePoint 15 scheint wahrscheinlich.
Seit einiger Zeit vertrete ich isolutions als Moderator für SharePoint Online im deutschsprachigen Forum der Office 365 Community. Durch meine schnellen und unkomplizierten Hilfestellungen will ich anderen Firmen einen einfacheren Einstieg in SharePoint Online ermöglichen und den Wissens- und Erfahrungsaustausch in der Community fördern.
