m_Schlenz
I'm new here

Konvertieren von Verweisvorlagen in der Praxis

Hallo,

mich würde interessieren wie die Konvertierung von Verweisvorlagen in der Praxis von statten gehen soll?

Alle bei uns verwendeten Verweisvorlagen sind in einem Vorlagenpaket enthalten, was es noch ein wenig komplexer für mich macht.

Meine nächsten Schritte an dieser Stelle währen folgende:

  1. Alle Templates über den Konvertierungsassistenten umzuwandeln.
  2. Alle Alten Templates mit der Eigenschaft „in Auswahl verstecken“ versehen.
  3. Templates bei bedarf umbenennen.
  4. Templates in Paket aufnehmen
  5. Paket Publlizieren

Nun Sollte zu jedem Namen z.B. m_lt_ext@LinkTemplates 2 gültige Vorlagen bereitstehen eine 4.1 Variante und eine 4.2 Variante (genericLink).

Somit sollten alle bislang erstellten Links funktionieren und gleichzeitig alle weiteren neuen Links mit der neuen Variante erstellt werden.

Ist dieser Weg so gehbar oder gibt es ein besser Lösung?

Was ist mit den Links die bis zum Update 5.x nicht angefasst wurden?

Was ist mit Links in Historischen Versionen?

Gruß

markus

0 Kudos
6 Replies
feddersen
Community Manager

Zur Linkkonvertierung ohne PackagePool kann ich etwas sagen:

Der Konvertierungsassistent ändert die Referenznamen der alten Linkvorlage in NAME.old, der neue generische Link bekommt den ursprünglichen Namen der alten Linkvorlage. Somit müssen sie keine Änderungen an den Linkkonfigurationen (z.B. bei der DOM-Eingabekomponente) vornehmen. Sie müssen auch nicht die alten Linkvorlagen "verstecken". Durch das "Umbiegen" der Referenznamen zeigen alle Eingabekomponenten automatisch auf den generischen Link. Es ist allerdings eine gute Idee nach der Umstellung den Referenzgraphen des Projektes neu berechnen zu lassen, da im Referenzgraph immer noch die alte Linkkonfiguration enthalten ist. Es gibt einen Auftrag, mit dem sie die Neuberechnung starten können.

Zum Verhalten in Zusammenspiel mit dem PackagePool kann ich aus dem Kopf nichts sagen, die wesentliche Frage ist, ob sie bei ihren Paketen eine Namensraumerweiterung definiert haben (z.B. @templates) oder nicht.

Die Daten in historischen Versionen werden nicht automatisch modifiziert. Die Daten werden erst im neuen Format abgespeichert, wenn sie durch einen Redakteur modifiziert werden. Weitere Informationen finden Sie auch in den Release Notes von Version 4.2, Abschnitt 8.1.2.

0 Kudos

Christoph Feddersen schrieb:


Zum Verhalten in Zusammenspiel mit dem PackagePool kann ich aus dem Kopf nichts sagen, die wesentliche Frage ist, ob sie bei ihren Paketen eine Namensraumerweiterung definiert haben (z.B. @templates) oder nicht.

Ja wir verwenden die Namenserweiterung. Dem zur Folge entsteht ein Kopie mit dem Namen VERWEISKONFIGRURATION.VERWEISVORLAGE@PAKETNAME.OLD (optional kann auch eine Kopie mit Folgendem Namen möglich sein VERWEISKONFIGRURATION@PAKETNAME.VERWEISVORLAGE@PAKETNAME.OLD) . Die im Projekt verwendeten Links dieser Vorlage sind nach einer Konvertierung nicht mehr gültig. Es wird ein Fehler "Die Erzeugung folgender Link Editoren schlug fehl. UID - Verweistext" ausgegeben. Im Falle von Links ohne Paketzugehörigkeit erscheit kein Fehler.

Wir das ".OLD" am Ende entfernt ist der Link wieder gültig und funktioniert. Leider geht nur die automatische konvertierung nicht mehr. Wird der alte Link bearbeitet wird kein genericLink erzeut.

Christoph Feddersen schrieb:

Es ist allerdings eine gute Idee nach der Umstellung den Referenzgraphen des Projektes neu berechnen zu lassen, da im Referenzgraph immer noch die alte Linkkonfiguration enthalten ist. Es gibt einen Auftrag, mit dem sie die Neuberechnung starten können.

Entspricht  Referenzgraph neu berechnen dem Auftrag "repair references"?

Der Link auf die Release Notes kann ich nicht öffnen. Auch in anderen Threads habe ich dies schon festgestellt Smiley Sad.

0 Kudos

Markus Schlenz wrote:

Christoph Feddersen schrieb:


Zum Verhalten in Zusammenspiel mit dem PackagePool kann ich aus dem Kopf nichts sagen, die wesentliche Frage ist, ob sie bei ihren Paketen eine Namensraumerweiterung definiert haben (z.B. @templates) oder nicht.

Ja wir verwenden die Namenserweiterung. Dem zur Folge entsteht ein Kopie mit dem Namen VERWEISKONFIGRURATION.VERWEISVORLAGE@PAKETNAME.OLD (optional kann auch eine Kopie mit Folgendem Namen möglich sein VERWEISKONFIGRURATION@PAKETNAME.VERWEISVORLAGE@PAKETNAME.OLD) . Die im Projekt verwendeten Links dieser Vorlage sind nach einer Konvertierung nicht mehr gültig. Es wird ein Fehler "Die Erzeugung folgender Link Editoren schlug fehl. UID - Verweistext" ausgegeben. Im Falle von Links ohne Paketzugehörigkeit erscheit kein Fehler.

Wir das ".OLD" am Ende entfernt ist der Link wieder gültig und funktioniert. Leider geht nur die automatische konvertierung nicht mehr. Wird der alte Link bearbeitet wird kein genericLink erzeut.

Dann würde ich es so probieren:

  1. Backup des Systems machen
  2. Verweiskonfiguration und Verweisvorlagen aus Paket entfernen
  3. Migration durchführen
  4. Geänderte (.OLD) Verweiskonfigurationen, Verweisvorlagen und die generischen Links dem Paket hinzufügen
  5. In den Zielprojekten die alten Verweiskonfigurationen entfernen
  6. Neue Paketversion packen und ausrollen

Markus Schlenz wrote:

Entspricht  Referenzgraph neu berechnen dem Auftrag "repair references"?


Ja.

Markus Schlenz wrote:

Der Link auf die Release Notes kann ich nicht öffnen. Auch in anderen Threads habe ich dies schon festgestellt Smiley Sad.

Logindaten finden Sie unter javascript:;

0 Kudos

Christoph Feddersen schrieb:


Dann würde ich es so probieren:

  1. Backup des Systems machen
  2. Verweiskonfiguration und Verweisvorlagen aus Paket entfernen
  3. Migration durchführen
  4. Geänderte (.OLD) Verweiskonfigurationen, Verweisvorlagen und die generischen Links dem Paket hinzufügen
  5. In den Zielprojekten die alten Verweiskonfigurationen entfernen
  6. Neue Paketversion packen und ausrollen

Als Ausgangssituation habe ich eine Verweiskonfiguration und eine darauf basierendeVorlage.

foo@LinkTemplates (Verweistemplate)

      foo.bar@LinkTemplates (Verweisvorlage)

2. Die Namen der Elemente entsprechen immer noch der Ausganssituation.

3. Nach der Migration gibt es folgende Elemente:

foo@LinkTemplates (Verweistemplate)

      foo.bar@LinkTemplates.OLD (Verweisvorlage)

foo@LinkTemplates (Verweisvorlage genericLink)

4. Nach diesem Schritt sind die Namen der Elemente wie folgt:

foo@LinkTemplates (Verweistemplate)

      foo.bar@LinkTemplates (Verweisvorlage)

foo@LinkTemplates (Verweisvorlage genericLink)

Die Erweiterung ".OLD" Verschwindet bzw. wird durch die Paketnamenserweiterung ersetzt.

5. Dieser Schritt ist aus meiner Sicht dann nicht mehr nötig da sich im Grunde nichts geändert hat.

6. Nach diesem Schritt hae ich eine gültige neuen Linkeditor und einen gültigen alten. Alle alten links bleibem dem zur Folge alt, auch nach einer Bearbeitung.

Zusatz zu Schritt 3 bzw. 4

Eine Link der auf der Vorlage "foo.bar@LinkTemplates" basiert kann eine geänderte Vorlage mit dem Namen "foo.bar@LinkTemplates.OLD" nicht auflösen. Dies habe ich zumindest bei meinen Tests wiederholt fastgestellt.

0 Kudos

Markus Schlenz schrieb:

Zusatz zu Schritt 3 bzw. 4

Eine Link der auf der Vorlage "foo.bar@LinkTemplates" basiert kann eine geänderte Vorlage mit dem Namen "foo.bar@LinkTemplates.OLD" nicht auflösen. Dies habe ich zumindest bei meinen Tests wiederholt fastgestellt.

Können Sie dazu bitte ein Helpdesk-Ticket einstellen. Ein Link, der auf der Vorlage "foo.bar@LinkTemplates" basiert, muss die Vorlage "foo@LinkTemplates" auflösen können.

Peter
0 Kudos

Die interne ID des Tickets ist #86702

Peter
0 Kudos