close
Beitragsbild-Übern-den-Wolken-fliegen-Freiheit

Site Pages in SharePoint programmatisch zu verändern wäre einfach und böte viele Möglichkeiten, wären da nicht die Publishing Pages. Sie verhindern oft konsistente Änderungen über alle Pages, da sie im Hintergrund anders verwaltet werden.

Besonders bei dynamischen Änderungen (zB über ein Http-Module) ist Vorsicht geboten. Beim Aufruf einer normalen Page sind viele Möglichkeiten offen, die bei Publishing Pages ausgeschlossen wurden. Die Unterschiede resultieren daraus, dass bei Publishing Pages im Hintergrund „TemplateRedirectionPages“ verwendet werden, die die Erstellung der eigentlichen Page kapseln.

Bei normalen Pages können alle Events, wie Init oder Load, verwendet werden. Eine Funktion kann hinzugefügt werden und wird auch anstandslos aufgerufen.

Bei Publishing Pages ist dies nicht möglich. Events sind zwar vorhanden, werden aber nicht aufgerufen, da nur auf die Events der TemplateRedirectionPage zugegriffen werden kann, aber nicht auf die im Hintergrund erstellte Page.

Um dieser Einschränkungen zu entgehen, kann man die Publishing Page überschreiben und eine eigene Custom Page in den SharePoint einbinden. Das bedeutet aber, dass die normalen Publishing Pages unverändert bleiben und immer die eigenen Pages verwendet werden müssen.

Andere Möglichkeiten bestehen darin, um die Erstellung der Publishing Page herum zu arbeiten. MasterPages können im Kontext gesetzt werden und können so direkt vor dem Aufruf der Page eine dynamische Änderung durchführen, die aber nur für den aktuellen Kontext gilt:

SPContext.Current.Web.CustomMasterUrl = CustomMasterPageUrl;
// kein Update des Webs durchführen

Es kann auch der HttpContext direkt verändert werden, ob nun vor oder nach der Erstellung der Page. Allerdings ist hier äußerste Vorsicht geboten. Publishing Pages reagieren auf Änderungen der Reihenfolgen ihrer Einträge extrem empfindlich, da Generator-Einträge die Erstellung der Pages leiten. Das Hinzufügen von Custom Actions ist eine andere, robustere Möglichkeit, über Scripte Änderungen in den Publishing Pages zu erreichen. Diese Möglichkeit ist allerdings performanzlastiger als andere und erfordert auch Updates.

01.bool allowUnsafeUpdates = web.AllowUnsafeUpdates;
02.web.AllowUnsafeUpdates = true;
03.List<SPUserCustomAction> userCustomActions = web.UserCustomActions.Where(item => item.Name == „customActionName“).ToList();
04.foreach (SPUserCustomAction userCustomActionToDelete in userCustomActions)
05.{
06.   userCustomActionToDelete.Delete();
07.}
08.SPUserCustomAction userCustomAction = web.UserCustomActions.Add();
09.userCustomAction.Name = „customActionName“;
10.userCustomAction.ScriptBlock = script;
11.userCustomAction.Location = „ScriptLink“;
12.userCustomAction.Sequence = 100;
13.userCustomAction.Update();
14.web.AllowUnsafeUpdates = allowUnsafeUpdates;

Änderungen sind zudem auch über das Page Layout möglich. Die Änderung betrifft in diesem Fall aber alle Publishing Pages bzw. deren Layout.

01.PublishingWeb publishingWeb = PublishingWeb.GetPublishingWeb(web);
02.if (publishingWeb != null)
03.{
04.   PageLayout pageLayout = publishingWeb.GetAvailablePageLayouts().Where(item => item.Name == „CustomPageLayout.aspx“).FirstOrDefault();
05.   publishingWeb.SetDefaultPageLayout(pageLayout, true);
06.   publishingWeb.Update();
07.}

Die Möglichkeiten für Publishing Pages sind trotz allem beschränkt. Damit muss jede Solution, die Pages dynamisch verändern möchte, besondere Behandlungen von Publishing Pages aufweisen.

Links:https://msdn.microsoft.com/en-us/library/microsoft.sharepoint.publishing.templateredirectionpage.aspx

Tags : Publishing PageSharePoint
Georg Selig

The author Georg Selig

Georg Selig hat sein Informatik-Studium an der TU-Wien im Jahr 2008 abgeschlossen und ist als SharePoint Senior Developer tätig. Herr Selig bringt mehr als 10 Jahre Berufserfahrung im Bereich der Software-Entwicklung mit Fokus auf Microsoft .net-Sprachen mit. Heute arbeitet er in einem SharePoint Development Team im Bereich der SharePoint Add-On und SharePoint Produkt Entwicklung in einem Wiener SharePoint und Office 365 Beratungsunternehmen. Im Zuge seiner Arbeit wurden von ihm Produkte für SharePoint 2010, SharePoint 2013, SharePoint 2016 und Office 365 SharePoint Online ins Leben gerufen. Heute beschäftigt sich Georg im Bereich der Erstellung von hybriden Software Produkten (Development) für SharePoint 2016, SharePoint Online mit und ohne Azure (PaaS).

Leave a Response