martinmueller
I'm new here

Publizierung aus FS setzt #global.preview nicht auf true, wenn man in den Preview-CaaS publiziert

Guten Morgen,

wir haben aktuell das Problem, dass wir Preview-relevante Informationen immer rauspublizieren müssen, weil #global.preview, #global.isPreview und #global.is('WEBEDIT') alle zu false evaluieren, wenn wir es direkt aus FirstSpirit raus publizieren.

Wenn ich jedoch etwas über den ContentCreator (mit TPP) ändere, wird danach die Delta-Publizierung angeworfen und dann wird auch #global.preview auf true gesetzt.

Viele Grüße

Martin

0 Kudos
8 Replies
Peter_Jodeleit
Crownpeak employee

Hallo Martin,

was ist denn mit "direkt aus FirstSpirit raus publizieren" gemeint? Der Auftrag mit der CaaS-Delta-Generierung?

Dieser ist nur für die freigegebenen Inhalte, daher ist es da korrekt, dass "preview" etc. da "false" sind.

Eventuell beschreibst du noch mal deinen Anwendungsfall, ich habe das Gefühl, das ich das Problem noch nicht verstanden habe.

Grüße aus Dortmund,

Peter

Peter
0 Kudos

Hallo Peter,

danke für die Rückmeldung.

Wir haben ein Projekt was, technisch gesehen, in zwei CaaS-Repos publiziert wird. Einmal das normale Repo wo freigegebener Content rein kommt.

Zusätzlich gibt es aber noch das Preview-Repo wo auch nicht freigegebener Content rein publiziert wird. Hieraus erstellen wir die Vorschau, die dem Redakteur im Content Creator angezeigt wird.

Wenn ich eine full publication in das Preview-Repo anstoße, dann steht in #global.preview "false" drin. Da ich aber nur in das Preview-Repo die PreviewIds usw. generieren möchte, sollte bei der Preview-Publizierung #global.preview auf "true" stehen.

Viele Grüße

Martin

0 Kudos

Ok, du hast also den Vollgenerierungs-Auftrag dafür genommen und dort angehakt, das die aktuellen Inhalte genommen werden... Dann wäre eine Option, die Bedingung auf $CMS_IF(!#global.isRelease)$ zu ändern. Ist das ein gangbarer Weg für euch?

LG, Peter

Peter
0 Kudos

Hi Peter, das reicht leider nicht, ich will ja den ganzen Content publizieren und eben für die Vorschau ein paar zusätzliche Dinge. Darum kann ich nicht !#global.isRelease nehmen, weil ich ja auch freigegebene Inhalte publizieren möchte.

Meiner Meinung nach müsste #global.preview nach true evaluieren, weil ich ja in den Preview-CaaS publiziere.

LG, Martin

0 Kudos

Hi Martin,

genau das macht die vorgeschlagene Bedingung. Sie prüft, ob die Inhalte aus dem aktuellem Stand kommt. Da ist der Name tatsächlich nicht eindeutig: Ein Inhalt kann aus dem aktuellem Stand stammen, aber trotzdem fachlich freigegeben sein.

Probiere es am besten einmal aus: Ist der Haken im Auftrag für "aktuelle Inhalte" gesetzt, ist während des Autrages der Wert von "#global.isRelease" immer "false".


LG, Peter

Peter
0 Kudos
MichaelaReydt
Community Manager

Hallo Martin,

ist dieses Posting noch offen? Benötigst du noch weitere Hilfe oder konnten Peters Antworten dir weiterhelfen? In diesem Fall wäre es super, wenn du die "richtige Antwort" entsprechend markierst.

Viele Grüße

Michaela

0 Kudos

Hi Peter,

danke für die Rückmeldung.

Ich bin mir nicht sicher, ob das wirklich die Richtung ist, die wir gehen wollen. Für mich sieht das nach einer Quick-And-Dirty-Lösung aus. Wir würden damit schon Schwierigkeiten bekommen, wenn wir Projekte haben, die den Freigabe-Mechanismus nicht verwenden (aus welchen Gründen auch immer).

Für die Umsetzung der Preview in UCP müsste ich > 200 Stellen anpassen, darum würde ich das ungern nochmal machen, sobald es mit #global.preview (oder wie auch immer) funktioniert.

Ist das denn, technisch gesehen, ein Bug? Habt ihr da was auf der Roadmap? Oder wird das so bleiben?

Viele Grüße

Martin

0 Kudos

Hallo Martin,

der Auftrag generiert den aktuellen Stand. Das dieser für Vorschauzwecke genutzt wird, ist dem Auftrag an der Stelle nicht bekannt. Wenn wir das ändern würden, würden sich Projekte ohne Freigabe-Nutzung in der Generierung plötzlich anders verhalten. Daher planen wir in dem Bereich auch keine Änderung.

Anstatt "#global.isRelease" kann man auch einen eigenen Schalter benutzen, der im Auftrag gesetzt wird. Dieser kann dann sowohl im Generierungs-Auftrag als auch in der CaaS-Konfiguration gesetzt werden. Dieser Ansatz wäre wahrscheinlich tatsächlich "technisch sauberer".

Grüße,
Peter

Peter
0 Kudos