[Gelöst/Upd] Anzeigeproblem mit Umlauten nur bei Upgrade

[homtata]

Hallo,

ich versuche gerade die ersten Schritte, um bisherige 4.8.18er-Seiten auf 4.9.0 (final) umzubauen.
Ich habe sowohl eine neue reine Erstinstallation von 4.9 wie auch parallel eine kopierte Live-Seite, die ich von 4.8 auf 4.9 aktualisiert habe.

Ich habe nun das Phänomen, dass in der Neuinstallation Umlaute keine Probleme bereiten. Im Modul content_pictury_gallery kommt z.B. im HTML-Template des Moduls das Wort "Zurück" vor. In der Neuinstallation wird das komplette HTML-Template angezeigt, ABER in der Upgrade-Version nicht. Gleiches, wenn Umlaute im Layout vorkommen. Es wird im Upgrade zwar gespeichert, aber die Input-Box des Layouts wird sofort danach leer angezeigt. Auf der Dateiebene ist das Layout aber erstmal gespeichert & vorhanden und wird auch verwendet. Umschreibe ich die Umlaute à la "ü", dann klappts auch in den Upgrade-Versionen....

Hat jemand eine Idee?

-------------- Edit 28.08.2013: Problem (für mich) zunächst gelöst
Wie unten beschrieben, traten die Probleme definitiv nach Installation des Smarty Wrappers auf.
Der "Fehler" liegt in der Datei /contenido/plugins/smarty/smarty_source/Smarty.class.php
In Zeile 67 wird unter bestimmten Umständen UTF-8 geladen, das führt in Layouts, Kategorien, Modulen bei mir (vorwiegend HostEurope Webpacks) zu den angesprochenen Fehlern. Ich habe die bisherige Zeile

Code: Alles auswählen

define('SMARTY_RESOURCE_CHAR_SET', SMARTY_MBSTRING ? 'UTF-8' : 'ISO-8859-1');

ersetzt durch

Code: Alles auswählen

define('SMARTY_RESOURCE_CHAR_SET', SMARTY_MBSTRING ? 'ISO-8859-1' : 'ISO-8859-1');

Und dann sind *magic* alle Dinge wieder da.
Trotzdem die Frage an die Entwickler: ließe sich der Fehler auf andere Art vermeiden, ohne diese Klasse umschreiben zu müssen?

LG

-------------- Edit 29.08.2013: Es ist noch mehr zu beachten:
sorry, wenn dieser Thread inzwischen gruselig aussieht. Mit dem geänderten Eintrag beim Smarty stimmten zwar die Layouts sowie die Kategoriennamen, in den Modulen wurden nun aber wieder die Umlaute zerschossen, was beim Original-Eintrag im Smarty wiederum NICHT der Fall war. Dieses Phänomen tritt in einer Neuinstallation nicht auf, nur bei Upgrades.

Es muss nun - soweit ich es testen konnte - alles mögliche zusammenspielen, damit das reibungslos klappt mit dem Smarty in einer Upgradeumgebung:
- Die Smartyeinstellungen doch so belassen, wie sie im Original sind.
- Die Sprache des Mandanten MUSS auf UTF8 stehen. Mit iso-Werten führt dies zu falschen Darstellungen.
- Beim Upgrade wurde in der /data/config/production/config.php in KEINER meiner Installationen der Wert für charset (ziemlich am Ende der Datei) gesetzt. Der ist zwingend auf "utf8" zu setzen.

Nur wenn alle diese drei Dinge erfüllt sind, verarbeitet der Mandant in allen Bereichen die Umlaute und Sonderzeichen korrekt!

[marcus.gnass_4fb]

Welches encoding hat das layout denn im filesystem?

[homtata]

Blöde Frage: Wie soll ich das rausfinden?
Ich habe die Datei ja nicht selbst abgespeichert, sondern sie wurde generiert beim Upgrade.
Der Fehler tritt auch auf, wenn ich im Upgradesystem ein völlig neues Layout anlege mit Umlaut drin, also ohne "Altlasten" starte.

Ich glaube auch nicht wirklich, dass es rein mit dem Fileystem zu tun hat. Es scheint irgendwo ein grundsätzliches Problem zu sein in meiner Upgradeversion. Der Fehler tritt ebenso auf, wenn der Artikelname Umlaute enthält, dann wird er auch nicht mehr angezeigt - also liegt es nicht (nur) am Filesystem, sondern grundsätzlich irgendwo anders.

Vor dem Upgrade habe ich ja das Livesystem in eine nicht-produktive Umgebung kopiert. Die Datenbank habe ich (wie bisher immer) mit "latin1" importiert, da "utf8" immer zu Darstellungsproblemen führte bei solchen Aktionen. Nach dem DB-Import habe ich die Seite komplett als Version 4.8.18 installiert und gecheckt - da war mit der Darstellung in den Layouts, Templates, Modulen mit den Sonderzeichen definitiv alles in Ordnung. Kann trotzdem an dieser Stelle irgendwas nicht stimmen?
In der data/config/production/config.php ist im Vergleich zur Neuinstallation folgender Wert leer: 'charset' => '', in der Neuinstallation steht 'charset' => 'utf8'. Ich habe diesen Wert in der Upgradeversion auch mal eingesetzt, das scheint aber auch nichts zu helfen.

LG

[xmurrix]

Hallo homdata,

dann stell doch bitte in der data/config/production/config.php den Wert für charset auf 'latin1'.

Wenn du Glück hast, wird es funktionieren...

Gruß
xmurrix

[homtata]

Nope, da hilft nix. Ich habe wechselweise sowohl nichts eingetragen, als auch "latin1" und "utf8". Der Fehler bleibt bestehen, egal in welcher Variante...

[homtata]

So. In einer anderen Installation, die ich gerade upgrade, ist das Verhalten jetzt völlig anders:
- Webseite (weil noch nicht live) direkt mit dem Upgrade versorgt, also kein Hin- und Herkopieren der Datenbank, vorherige Version 4.8.18
- Jetzt kann ich im Layout zwar Umlaute speichern, ABER
- ABER: in den Modulen werden die Umlaute jetzt umgeschossen zu "Â" und "ü" usw... und bei jedem neuen Abspeichern werden DIESE Sonderzeichen wiederum neu umgeschossen, so dass sich die Umlautketten ständig verlängern.

Irgendwas scheint doch da nicht hinzuhauen im Upgrade, obwohl ich mich an die Vorgaben halte...

--------------- Edit:
Nun habe ich eine Weile am System gearbeitet, die ersten Module umgestellt, unter anderem die neue Navigation eingeklemmt, und NUN beginnt das System wieder im Layout zu spinnen, wie schon oben im ersten Post beschrieben:
Jetzt wird das Layout wieder nicht angezeigt nach dem Speichern, wenn ich Sonderzeichen einfüge!

Ideen?

[homtata]

ich bin nicht ganz sicher, aber es könnte sein, dass das Problem auftrat, nachdem ich zum ersten Mal "Module synchronisieren" geklickt habe, um neue Module einzulesen.

[homtata]

so, inzwischen kann ich das eingrenzen: das Plugin "SmartyWrapper" ist der böse... ist es installiert, lassen sich Umlaute nicht abspeichern. Wenn ich es deinstalliere, klappt alles wie gehabt!
Das habe ich an verschiedenen Stellen getestet (Layout, HTML-Eingabe im Modul selbst).