Nachdem ich euch letztes Mal gezeigt habe, wie ihr schnell in Sitecore navigieren könnt, möchte ich euch heute das Publishing mit seinen Fallstricken zeigen.
Wie üblich ist der Artikel in deutsch und englisch verfügbar.
Legen wir los!
Publishing Grundlagen
Bevor wir ins Publishing einsteigen, sollten wir uns noch einmal einige Grundlagen zu dem Thema ins Gedächtnis rufen. Sitecore verwendet 2 Datenquellen für die Inhalte der Webseiten, so genannte Datenbanken. Master enthält die gesamten Informationen, während Web nur aktuell publizierten enthält. Publishing ist damit grundsätzlich einfach ein Anpassen der Datenbank Web mit Daten von Master.
Was ist hier los?
Mit dem Konzept im Hinterkopf wäre es sehr praktisch, sich den Inhalt der Web Datenbank anschauen zu können. Tatsächlich geht das, allerdings nur in der Desktopansicht.
In der rechten unteren Ecke befindet sich ein kleines Datenbanksymbol. Zum Wechseln müsst ihr einfach darauf klicken und Web auswählen.
Wahrscheinlich seht ihr auf Anhieb keinen grossen Unterschied. Im Normalfall sind Master und Web zumindest strukturell sehr ähnlich. In meinem Fall könnt ihr im Content Editor sehen, dass die gesamte Habitat Seite nicht publiziert ist.
Publishing in Sitecore
Schauen wir uns den Publishing-Dialog an und publizieren dann die Habitat-Seite. Dazu markieren wir das Habitat Item und starten den Dialog über Publish -> Publish -> Publish Item. Achtet darauf, den Bereich unter dem Icon zu klicken, sonst erscheint ein vereinfachter Dialog.
Es gibt für das Publishing einige Optionen, die wir uns genauer anschauen wollen.
- Smart publish
Diese Variante sollte bevorzugt werden. Sitecore entscheidet anhand der Revision, welche Items aktualisiert werden müssen. Die Revision ändert sich jedes Mal, wenn ein Item im Content Editor verändert wird. - Republish
Sitecore publiziert alle Items unabhängig von deren Revision. Dieser Modus sollte pur dann verwendet werden, wenn das Smart Publishing nicht funktioniert. - Publish subitems
Die wichtigste Option in diesem Dialog. Ist sie aktiviert, wird nicht nur das Item selbst publiziert, sondern auch rekursiv alle Subitems. - Publish related items
Eine recht komplexe Option. In Sitecore kann man Items publizieren, die eine Anhängigkeit auf andere Items haben. So kann man beispielsweise ein Itempublizieren, ohne das dazugehörige Template publiziert zu haben. Mit dieser Funktion versucht Sitecore, solche anhängigen Items zu finden und auch zu publizieren. Der Nachteil ist, dass man die Kontrolle über zu publizierende Items in recht hohem Masse Sitecore überlässt. In einer gesunden Sitecore-Lösung sollte diese Option keine Gefahrdarstellen.
Publishing language
Hier kann man die Sprachen wählen, welche publiziert werden sollen. Im Normalfall sind das alle.
Publishing targets
In den Meisten Umgebungen wird es nur ein Publishing Target geben. In grösseren Organisationen gibt es eventuell mehrere Cluster oder andere Umgebungen, auf die publiziert werden kann.
Los geht’s
Wir publizieren die Habitat-Site smart, inklusive Sub- und related Items und in allen Sprachen.
Nach dem Publizieren erscheint ein Zusammenfassungsdialog. Die Zahlen bedeuten folgendes:
- Items processed
Anzahl der Items, die von Sitecore betrachtet wurden - Items created
Anzahl der neu erzeugten Items in der Web Datenbank - Items updated
Anzahl der Items, die in Sitecore schon existierten und geändert wurden - Items skipped
Anzahl der Items, die schon in der Web Datenbank existierten und sich nicht geändert haben (=die gleiche Revision hatten)
Wenn wir das gleiche Publishing nochmals durchführen, sehen wir den Einfluss vom Smart Publish. Beim wiederholten Publizieren wurden in meinem Fall keine neuen Items erzeugt und an die 1200 übersprungen. Die Anzahl der tatsächlich geänderten Items war mit etwa 900 immer noch hoch. Das liegt vermutlich an Customisierungen in der Habitat Solution, die die Revision ändern. Wenn ihr im Betrieb häufiger unerwartet hohe Zahlen bei der Anzahl der aktualisierten Items seht, meldet das eurer IT. Eventuell wurden Funktionen nicht optimal umgesetzt und der Publishing-Prozess dadurch unnötig verlangsamt.
Wenn wir nun zur Web Datenbank wechseln, sehen wir unsere Habitat-Items.
“Mit grosser Macht kommt grosse Verantwortung”
Publizieren ist ein recht aufwändiger Prozess, ihr solltet euch also der Implikationen bewusst sein.
- Es kann immer nur eine Publishingoperation laufen. Wenn bereits jemand anderes publiziert und ihr ein Publishing startet, wird eure Aktion in die Publishing Queue gehängt. Erst wenn alle anderen Operationen fertig sind, wird euer Auftrag abgearbeitet.
- Das Publizieren der gesamten Seite ist vermutlich die aufwändigste und längste Operation, die ein Content-Autor durchführen kann. Die IT sollte fast allen Autoren die Rechte entfernt haben, damit das nicht aus Versehen passiert.
- In fast allen Fällen wird Sitecore nach dem Publishing den Cache der Webseite leeren. Wenn eure Lösung Caching intensiv nutzt, kann die Performance der Webseite nach einem Publish temporär recht stark einbrechen.
Einschränken des Publishings
In Sitecore kann man das Publizieren von Items mit Hilfe der Publishing Settings verhindern. Nehmen wir einmal an, wir wollen die Habitat Seite nicht verfügbar machen, aber trotzdem daran arbeiten können. Dies können wir erreichen, indem wir die Site Root unpublizierbar machen.
Dazu selektieren wir das Item und öffnen den Dialog Publishing Settings über Publish -> Change
Der Dialog hat 3 Tabs, in denen man die Publikationszeitspannen pro Item, pro Version oder für ein Publishing Target einstellen kann. In unserem Fall machen wir einfach das gesamte Item unpublizierbar, in dem wir die Checkbox unter Item abhaken.
Seht ihr jetzt ein Warn-Icon in der Quick Action Bar? Falls nicht, solltet ihr die Publishing Warnings aktivieren (Siehe meinen ersten Content Editing Blog Post für eine Anleitung).
Wenn ihr das Habitat Item nun publiziert, verschwindet es von der Web Datenbank.
Vorschau
Es gibt in Sitecore ein Werkzeug, um sich anzuschauen, wie die Webseite nach einem Publish-Vorgang aussehen würde. Dieses startet ihr über Publish -> Preview.
In diesem Modus könnt ihr nicht nur eine Vorschau für den jetzigen Zeitpunkt sehen, sondern auch für jeden Zeitpunkt in der Zukunft oder der Vergangenheit. Dazu müsst ihr einfach nur das Datum im Date-Bereich Experience Ribbons ändern.
Publishing Fallstricke
Viele Content Editoren haben Schwierigkeiten mit dem Publishing, deshalb möchte ich einige der Besonderheiten erklären und demonstrieren.
Fallstrick 1: Unpublizierbare Items
Diesen Fallstrick habt ihr eben bereits kennengelernt. Wenn man ein Item auf unpublishable setzt, wird es nicht etwa beim Publizieren ignoriert, sondern es wird gelöscht.
Fallstricke 2: Item Name vs Item ID
Diesen Fallstrick möchte ich gerne demonstrieren. Dazu habe ich ein Item Test unter dem Habitat Home angelegt und publiziert. Wir können in der Web Datenbank sehen, dass es korrekt dort angekommen ist.
In der Master Datenbank löschen wir nun dieses Item und erzeugen es erneut via Insert. Anschliessend publizieren wir es. Was glaubst du wird das Ergebnis sein?
Wie kann es ein, dass wir dasselbe Item nun zwei Mal haben? Nun ja… das tun wir nicht. Wir haben zwei Items die gleich heissen, aber das könnte ja auch Zufall sein. Sitecore erkennt Items eindeutig an ihrer Item ID. Sitecore generiert beim Anlegen eines neuen Items eine solche ID, so dass wir nun nachvollziehen können was passiert ist:
- Wir erzeugen ein Item Test mit ID X
- Wir publizieren das Item mit der ID X
- Wir löschen das Item mit der ID X
- Wir erzeugen ein Item Test mit der ID Y
- Wir publizieren das Item mit der ID Y
Wie man sieht, haben wir das Item X niemals wissen lassen, dass es nicht mehr in der Web Datenbank existiert. Item X und Item Y sind völlig unabhängig. Folgende Tipps helfen euch, diesen Fall zu vermeiden:
- Wenn ihr aus versehen ein Item löscht, holt es aus dem Papierkorb und legt kein Neues an. Die Items sehen zwar möglicherweise gleich aus, sind es aber nicht.
- Bevor ihr ein Item löscht, setzt eine Publishing Restriction und publiziert es, damit wird das Item aus der Web Datenbank gelöscht und ihr habt keine “Itemleichen”.
- Ein bereits in Master gelöschtes Item könnt ihr loswerden, indem ihr das Parent-Item mit der Option Include Subitems publiziert
Fallstrick 3: Items verschieben
Um diesen Fallstrick zu demonstrieren, habe ich ein Bild in die Media Library hochgeladen und einzeln publiziert. In der Web Datenbank sieht das dann folgendermassen aus.
Dann habe ich das Bild in den Unterordner Files geschoben und nochmals einzeln publiziert.
Wenn ich nun in die Web Datenbank schaue, existiert das Item nur noch an seinem neuen Ort.
Wie kann das Item aus dem vorherigen Ordner verschwinden, ohne dass dieser publiziert wurde? Wenn man darüber nachdenkt ist es eigentlich logisch, denn dasselbe Item kann nicht zwei mal existieren. Es muss also zwangsläufig von seinem alten Ort verschwinden, wenn es woanders publiziert wird. Der Pfad im Content Editor ist tatsächlich einfach eine Information auf dem Item und ändert sich beim Publizieren des Items. Behaltet das unbedingt im Hinterkopf, wenn ihr Items verschiebt.
Fallstrick 4: Preview
Die Vorschaufunktion scheint extrem praktisch, allerdings hat sie auch einen gewaltigen Fallstrick: Sie berücksichtigt lediglich die Master Datenbank. Was das genau bedeuten kann, soll folgendes Szenario verdeutlichen.
Nehmen wir an, wir wollen Content zum 01.01.2019 verschwinden lassen und ändern deshalb die Publish Settings so, dass das entsprechende Item nur bis 31. Dezember 2018 um 23:59 publizierbar ist. Wir verwenden die Vorschaufunktion, um zu verifizieren, dass das Item nach dem Jahreswechsel verschwunden ist. Wenn wir nun am 01.01., kurz nach 0:00 Uhr die Webseite besuchen, ist der Inhalt mit hoher Wahrscheinlichkeit noch abrufbar. Der Grund ist, dass die Web Datenbank nur bei einem Publishing-Vorgang aktualisiert wird; bis dahin bleibt der alte Content verfügbar (auch wenn er nicht mehr gültig wäre).
Behaltet also im Hinterkopf, dass die Vorschau nur eine Momentaufnahme von der Website ist, wenn genau in diesem Moment publiziert worden wäre. Das gleiche gilt auch für die Vergangenheit: Ein vergangener Status der Webseite in der Vorschau bedeutet nicht, dass die Live-Webseite zu dem Zeitpunkt tatsächlich exakt so aussah.
That’s it
So viel zum Thema Publishing und Fallstricke, ich hoffe ihr könnt mit diesen Einblicken etwas anfangen. In meinem nächsten Artikel wird es dann um Sprachen und Versionierung gehen.
