CONTENIDO Forum

Hallo,
ich hätte eine Frage zur Speicherung der Modulkonfigurationen. Ich habe Artikel in denen über die Konfiguration Moduleinstellungen gemacht werden können. Wenn man nun diese Artikel in andere Sprachen synchronsiert, dann wird bei einer Änderung der Konfiguration in der neuen Sprache die Konfiguration in der Ursprungssprache auch geändert.

Ist das so gewollt oder ein Fehler?

Danke

Con Version: 4.9.7

Lieber smac,

vielen Dank für Deinen Beitrag. Dieses Verhalten ist von unserer Seite gewollt, es handelt sich also um keinen Fehler .

Okay, danke für die Info, dann muss ich mir was überlegen

Servus,

frederic.schneider_4fb hat geschrieben:Dieses Verhalten ist von unserer Seite gewollt, es handelt sich also um keinen Fehler .

Gibt es dafür auch einen Grund?
Für mich ist es so, als würde man Artikel synchronisieren können, wenn man aber in der neuen Sprache den Text ändert, dann ändert sich auch der in der alten Sprache.

Wäre es nicht besser wenn die Modulkonfiguration beim Sync zwar mit kopiert, und dann natürlich auch verwendet wird, sobald man aber in der neuen Sprache Änderungen macht, dann diese, und auch nur dort, Verwendung finden?
Wenn dann könnte man über eine Systemeinstellung nachdenken, die, falls eingeschaltet, beim Ändern der Konfiguration diese in allen Sprachen entsprechend ändert. Ich würde es aber nicht als Standard setzen.

Gruß aus Franken

Ortwin

Hallo,

also mich hat das auch überrascht, und das ist in meinem Projekt auch sehr nachteilhaft, weil ich den Kunden ständig eintrichtere, er soll die Sprachen syncronisieren und jetzt darf er das bei bestimmten Artikel nicht, damit man unterschiedliche Einstellungen treffen kann. Natürlich hat es auch zum Nachteil, dass ich den "Sprachenumschalter" den ich direkt auf der idart liegen habe, jetzt abhändern muss und auf die idcat beschränke, was nicht ideal ist

Also falls ihr in die Richtung nachdenken möchtet - unabhängige Konfigurationen wäre schon ein Vorteil.

smac hat geschrieben: unabhängige Konfigurationen wäre schon ein Vorteil.

Ich glaube nicht, dass es bei Synchronisation ein Vorteil wäre.

Also im konkreten Fall, steuere ich über die Konfiguration den Empfänger eines Onlinefomulares. Die deutsche Version davon soll Person A bekommen, die französische aber Person B, weil nur diese französisch spricht. Hier ist es schon ein Vorteil bzw notwendig, dass ich unterschiedliche Konfigurationen machen kann.

smac hat geschrieben:Die deutsche Version davon soll Person A bekommen, die französische aber Person B, weil nur diese französisch spricht.

Wäre das dann nicht besser in der Modulprogrammierung aufgehoben?
if($lang=1) ...

Zumal auch das Template in französisch sein sollte. Also die übertragenen Formular-Felder dann z.B. "Rue" statt "Straße" benannt werden sollen (nicht Frontend, sondern das was im Email dann ankommt).

Hallo,
das war jetzt auch nur ein Beispiel, es gibt auch noch andere Anwendungsfällt. Aber auch in diesem Beispiel wäre die Steuerung über die Module nachteilhaft, denn ich gebe dem Kunden keinen Zugriff auf die Module - und wenn die E-mail-Adresse sich ändern soll, kann er es über die Konfiguration ganz einfach selber machen.
Ich finde das so eigentlich die einfachste Möglichkeit, dafür ein CMS_TEXT zu missbrauchen oder über free_use zu arbeiten, geht natürlich auch. Die Variante die Einstellung in der Konfiguration und nicht im Editor zu haben, finde ich aber grundsätzlich besser. Der Kunde hat somit den Zugriff, muss aber schon etwas versierter sein, als nur im Editor zu arbeiten.
Oder wie löst ihr solche Fälle?

Ich kann gerade nicht genau reproduzieren was Ihr meint.
Ich habe eine Seite am Start, die auch in chinesisch, russisch und englisch bereitgestellt wird.
Dort habe ich alle diese Sprachen von der Ursprungssprache synchronisiert. Dazu gehören z.B. auch Artikel, die ALR (Article List Reloaded) nutzen.
Ich habe für jede der Sprachen eine andere Konfiguration hinterlegt.

Der Umstand, das sich nach dem Synchronisieren auch in anderen Sprachen noch etwas ändert ist mir bisher noch nicht untergekommen.
Ganz im Gegenteil, manchmal hat man in DE etwas im ALR geändert (sortierreihenfolge), und es für die anderen Sprachen vergessen.
Oder nehmen wir das Datum: in DE= 21.12.1988 in EN= 1988-12-21 (funktioniert tadellos).

Soweit ich mich erinnere hat ALR dabei kein Sprachflag, welches es in der Programmierung setzt.

Selbst wenn man an der Vorlage, die diese Artikel nutzen etwas ändert (so dass man die Vorlage eigentlich erneut zuweisen muss, damit die Änderung aktiv wird), ist die Funktion so, wie sie auch innerhalb der Sprache ist [d.h. solange ich in der synchronisierten Sprache nicht die Vorlage neu zuweise, verwendet er weiter die alte].

oldperl hat geschrieben:Wäre es nicht besser wenn die Modulkonfiguration beim Sync zwar mit kopiert, und dann natürlich auch verwendet wird, sobald man aber in der neuen Sprache Änderungen macht, dann diese, und auch nur dort, Verwendung finden?

Ich "meine", das das Verhalten derzeit exakt so ist ?!

smac hat geschrieben:Oder wie löst ihr solche Fälle?

Das kommt immer drauf an, es gibt mehrere Möglichkeiten

• In der Modulkonfig mit CMS_VAR und CMS_VALUE, vor allem wenn es Artikel-bezogene Einstellungen sind
  • als Rohwerte (strings)
  • oder als JSON-Array für multiple Werte (beispielsweise Selects)
• Per Mandanteneinstellung (auch sprachabhängig), vor allem bei Mehrfachverwendung von Einstellungen und/oder falls es die selben Einstellungen Mandanten übergreifend sein sollen
• Systemeinstellungen, wenn es zentrale Einstellungen, die System-weit gelten sollen, sind

Das sind ein paar Möglichkeiten.

Gruß aus Franken

Ortwin