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.
