Lang.php überschreibt cust_lang.php - Bug oder Feature?

Hallo Zusammen,

bei meinem ersten Projekt mit der neuen PE 4.0 bin ich auf ein seltsames Verhalten gestoßen:

Wenn ich in der cust_lang.php eine Kostante angebe, die schon in der lang.php existiert, wird der Wert nicht überschrieben, sondern weiterhin der Wert aus der lang.php genommen. Wenn ich aber in der cust_lang eine neue Konstante anlege, die es in der lang.php noch nicht gibt, klappt es. Grundsätzlich wird die cust_lang.php also gefunden.

In den Vorgänger-Versionen wurden die Werte der lang.php immer mit denen der cust_lang.php überschrieben, das ist ja auch der Sinn der cust_lang.php. Das scheint jetzt nicht mehr so zu sein. Es scheint so, als würde die cust_lang.php vor der lang.php geladen anstatt danach. Ist das so beabsichtigt, und wenn ja, was ist die Idee dahinter? Oder kann man das Verhalten irgendwo im Admin oder in der config beeinflussen?

Vielen Dank im Voraus für Eure Hilfe und viele Grüße.
Michaela

Hi,

das Problemchen hatte ich auch schon, da wurde wohl das sprach-file system umgebaut, ist noch schön auskommentiert in der oxlang.php drin.

Wie ich das sehe, greift sich der neue Code die Langfiles in alphabetischer Reihenfolge (glob()), es scheint übrigens egal zu sein wie die genau heißen halt nur irgendwas mit *lang.php

Ergo: benenn deine cust_lang.php in xcust_lang.php um, dann sollte es klappen… …hab gerade kein Server zur Hand zum testen :wink:

@OXID: wie wärs das default lang einfach _lang.php zu nennen, dann klapps auch mit den Customern äähhh cutomizen :wink: (erfordert Anpassung in oxlang.php Zeile 444) Gruß Magnus

Hallo,

mir scheint es anders herum logischer: Dafür zu sorgen, dass alles, was nicht lang.php heißt, mit einem Override-System zu versehen, oder?

Ach - von welchen Versionen reden wir eigentlich @Manuela und @Magnus?

Gruß


Marco Steinhäuser
Community Guide
OXID eSales AG

Hallo,

bei mir ist die Version PE 4.0.1.0 im Einsatz, habe es aber auch mit PE 4.0.0.2 getestet. Ein Kollege hat mit der aktuellen CE getestet - überall das gleiche Verhalten.

Der Trick mit dem Umbenennen der cust_lang funktioniert sehr gut.Achtung: Damit die neue Datei geladen wird, muss das tmp-Verzeichnis geleert werden.

Vielen Dank für den Workaround,
Michaela

Hallo zusammen,

der Beitrag ist zwar schon etwas älter, allerdings habe ich hier auch keinen aktuelleren gefunden.

Mein Problem ist ähnlich dem eingangs beschriebenen, nur kann ich nicht einmal neue Identifier in der cust_lang anlegen, da diese nicht gefunden werden.

Etwas detaillieter:
Wir entwickeln einen B2B Shop und ich habe in den Einstellungen bereits die Netto-Preise ausgewählt. Im Frontend wird allerdings nicht auf Netto hingewiesen. Neben einigen anderen Tests und Ideen, um dies zu verbessern, habe ich die kleine Fußnote rechts (zzgl. Versandkosten) um den Teil “zzgl. MwSt.” ergänzen wollen (so geschehen mittels eines neuen Identifier in der page.tpl). Die passende Variable in der cust_lang im entsprechenden Templateverzeichnis eingefügt, aber die Fußnote zeigt nur die neue Variable / den neuen Identifier an. Ergänze ich die lang.php für den gesamten Shop (nicht die Template Datei), dann geht es. Das ist allerdings nicht Update sicher und darum unpraktisch.

Momentan habe ich es so gelöst, dass ich in der page.tpl den gewünschten Text hardcoded eingegeben habe; allerdings finde ich das sehr unsauber und zudem bin ich doch neugierig, wieso die cust_lang nicht tut, was sie soll.

Ich bin über jede Idee und jeden Hinweis dankbar.

OXID mobile Theme im Einsatz?

[QUOTE=leofonic;130364]OXID mobile Theme im Einsatz?[/QUOTE]

Ja, ein mobiles Template sollte sein; und dafür habe ich die kostenlose Variante von OXID genommen.

Das ist ein Fehler im Themeswitcher Modul: https://github.com/OXID-eSales/mobile_theme/issues/6