Hallo, bei meinem shop werden bestimmte Umlaute nicht korrekt dargestellt. Das liegt natürlich irgwndwie am Encoding… ich bin aber nicht sicher, wo ich jetzt etwas umstellen muss, damit es funktioniert. Konkret betroffen sind Textbausteine, die über den SQL-Import errzeugt wurden, wie „Über uns“. Nicht betroffen sind Kategorien, die ich später erstellt habe - hier werden die Umlaute korrekt dargestellt. Meine Datenbank ist eine UTF-8-Datenbank - ist das vielleicht schon das Problem? Kann es sein, dass beim Import die Umlaute falsch abgespeichert wurden? Sollte man besser ein anderes DB-Encoing wählen? Danke und viele Grüße Constantin
Hallo Ich kann das Problem bestätigen. Ich vermute auch, dass die Datei „import.sql“ fehlerhaft codiert ist und dadurch zu Problemen mit einigen Umlauten auftreten. Das Problem besteht bei allen von mir getesteten Daten mit/ohne Demodaten für ioncube oder zend Optimizer … Bspw. bei diesen SQL Statement INSERT IGNORE INTO s_cms_support …. (10, ‘R?ckgabe’, Das ? steht natürlich für einen fehlerhaft codiertes Zeichen. Es währe gut wenn Shopware die Codierung von „import.sql“ noch einmal überprüft und ggf. ändert. Vielen Dank
1 „Gefällt mir“
Gibt es ein “offizielles” Statement dazu? 
Danke
UTF-8 ist falsch, es sollte ISO Latin sein, sonst gibt es die beschriebenen Probleme. mfg Frank
1 „Gefällt mir“
… die Lösung rückt näher… Durch den Import als Latin1 werden die Umlaute schon mal richtig in phpmyadmin dargestellt … Der MySQL Server (zumindest bei mir) benutzt als Standarteinstellung UTF-8 für die character_set% und collation% Variablen … deswegen diese Probleme mit den Umlauten … Wenn man jetzt in der Application.php die Zeile: ‚db‘ => array( … ‚charset‘ => ‚latin1‘ … einfügt. Werden auch die Umlaute im Frontend richtig dargestellt. Nur hat das bislang keine Auswirkung im Backend dort werden die Umlaute immer noch falsch dargestellt. Scheinbar werden im Backend andere Parameter für den Verbindungsaufbau zum MySQL Server verwendet … weiss jemand wo man für’s Backend etwas einstellen kann? Vielen Dank. Sash
[quote=„sashluc“]… die Lösung rückt näher… Durch den Import als Latin1 werden die Umlaute schon mal richtig in phpmyadmin dargestellt … Der MySQL Server (zumindest bei mir) benutzt als Standarteinstellung UTF-8 für die character_set% und collation% Variablen … deswegen diese Probleme mit den Umlauten … Wenn man jetzt in der Application.php die Zeile: ‚db‘ => array( … ‚charset‘ => ‚latin1‘ … einfügt. Werden auch die Umlaute im Frontend richtig dargestellt. Nur hat das bislang keine Auswirkung im Backend dort werden die Umlaute immer noch falsch dargestellt. Scheinbar werden im Backend andere Parameter für den Verbindungsaufbau zum MySQL Server verwendet … weiss jemand wo man für’s Backend etwas einstellen kann? Vielen Dank. Sash[/quote] Das Backend verwendet denselben Verbindungsaufbau wie das Frontend…
1 „Gefällt mir“
… OK - Codierungschaos konnte nach einigen Tests lokalisiert werden. Shopware benötigt vom MySQL Server immer die Verbindungskodierung und andere Variablen in „latin1“. Da bei der OpenSuse Standart LAMP Installation der MySQL Server für UTF-8 Kodierung … konfiguriert ist müssten die betreffenden Variablen vor jeder Datenbankabfrage von Shopware in jeden Script neu gesetzt werden. Vielleicht können diese Verbindungsparameter auch GLOBAL gesetzt werden?? evtl. in der codierten Datei backend/php/check.php die immer zu Beginn aufgerufen wird … das müsste jedoch ein Programmierer von Shopware überprüfen Das ist m.E. ein Bug, der gefixt werden sollte, damit der Shop auch in anderer Umgebung läuft. Meiner Ansicht noch besser, wenn man konsequent auf UTF-8 umsteigt, da von einigen Scripten (z.B. json.php) wieder UTF-8 benötigt wird und somit das hin und her konvertiert wegfällt. (sicher auch sinnvoll wenn jemand einen Shop in kyrillisch benötigt) Um das Problem „temporär“ zu lösen habe ich folgenden Zeilen in die betreffenden Dateien eingefügt: Bspw. in Zeile 20 Datei ./engine/backend/modules/cmsstatic/cms.php mysql\_query('SET character\_set\_client = latin1'); mysql\_query('SET character\_set\_results = latin1'); mysql\_query('SET character\_set\_connection = latin1'); mysql\_query('SET character\_set\_server = latin1'); mysql\_query('SET character\_set\_system = latin1'); mysql\_query('SET collation\_connection = latin1\_german1\_ci'); mysql\_query('SET collation\_server = latin1\_german1\_ci'); das gleiche nochmal in Zeile 18 Datei ./engine/backend/ajax/getCms.php Somit würde im Backend zumindest schon einmal die Funktion Inhalt/Shopseiten/ funktionieren … ist logischerweise keine zweckmäßige Lösung da alle betreffenden Dateien manuell geändert werden müssten … ich habe das nur bei den beiden probiert und bin sicher es werden im Backend noch viele ander Codierungsprobleme ohne die richtige Verbindungskodierung auftauchen. Wie schon geschrieben, diese Variablen müssen in irgend einer Form GLOBAL übergeben werden. Falls jemand eine bessere Lösung einfällt, würde ich mich über ein entsprechendes Post freuen . Viele Grüße sash
Also ich vermute, die Ursache ist, dass das Installationsskript „import.sql“ fehlerhaft ist! Die Umlaute in dem Immport-Skript scheinen nicht konsistent kodiert zu sein. Siehe auch hier: post11524.html#p11524 Demzufolge ist es egal, ob ich die DB mit latin1 oder utf-8 aufsetze. Ich erhalte immer fehlerhafte Umlaute. Die einzige Lösung scheint also zu sein, die import.sql manuell zu reparieren, also per find&replace die fehlerhaften Umlaute zu fixen. Oder was meint ihr?
Hallo, … die fehlerhafte “import.sql” ist (zumindest bei mir) nicht das Hauptproblem, man könnte ja die Umlaute einfach “manuell reparieren” falls beim Import etwas schief läuft. (bei mir ging es zumindest, wenn man mit latin1 importiert) Sobald ich im Backend Kategorien oder anderes mit Umlauten eingebe, werden diese Umlaute nur als “?” in die Datenbank übernommen, Problem ist wie schon geschrieben die Verbindungskodierung zum MySQL Server sash
1 „Gefällt mir“
[quote=„sashluc“]Hallo, … die fehlerhafte „import.sql“ ist (zumindest bei mir) nicht das Hauptproblem, man könnte ja die Umlaute einfach „manuell reparieren“ falls beim Import etwas schief läuft. (bei mir ging es zumindest, wenn man mit latin1 importiert) Sobald ich im Backend Kategorien oder anderes mit Umlauten eingebe, werden diese Umlaute nur als „?“ in die Datenbank übernommen, Problem ist wie schon geschrieben die Verbindungskodierung zum MySQL Server sash[/quote] Kann ich bestätigen! Es gibt hier http://trac.shopware.de/trac/ticket/100266 ein ticket dazu.
Moin Leute, dieser Artikel könnte Euch evtl. helfen… Trac Umlautproblemlösung Stefan :thumbup:
Hallo, mal für´nen Anfänger: Wo muss ich das ändern? Gruß Holzi
1 „Gefällt mir“
90 Leute bedanken sich, und niemand kann hinschreiben, in welcher Datei der Code eingefügt werden muss. Ist die pod.php gemeint? Wohl kaum
Hallo, Es gibt nochmal ein Fehler in den Import Scripten. Das betrifft, wohl aber nur die Importierung von Artikel und Kategoriedaten sowohl auch die Importierung von Kundendaten aus XML Dateien. Man kann in der XML Datei zwar das charset auf ISO-8859-1 oder UTF-8 ändern, das bewirkt jedoch nichts, ein XML Feed im ISO-8859-1 Format wird im Importierungsscript direkt ins UTF8 encodiert, was Zeichenfehler in der Datenbank verursacht, wenn diese Automatisch mit latin1 Zeichensatz eingerichtet wurde. Abhilfe schafft jedoch eine Änderung der Datei: /engine/backend/modules/import/import/customers.php $customer = (array) $customer; foreach($customer as $key =\> $value) { $customer[$key] = utf8\_decode($value); } Danach wurden alle Kundendaten ohne Zeichenfehler Importiert, das sollte man in den Restlichen Importierungsmöglichkeiten ebenfalls berücksichtigen! Grüße, Daniel
[quote=„theexplainer“]90 Leute bedanken sich, und niemand kann hinschreiben, in welcher Datei der Code eingefügt werden muss. Ist die pod.php gemeint? Wohl kaum[/quote] Nein hier ist die Application.php im Root-Verzeichnis deines Shops gemeint. Die Änderung würde so aussehen: return array( 'db' =\> array( 'username' =\> $DB\_USER, 'password' =\> $DB\_PASSWORD, 'dbname' =\> $DB\_DATABASE, 'host' =\> $DB\_HOST 'charset' =\> 'latin1' Ergo, nur ein Zusatz im DB Config Array hinzufügen! Grüße, Daniel
Danke, soweit war ich schon. Aber was das mit dem Ticket zu tun hat ??? Naja, auf alle Fälle geht das jetzt mit den Umlauten in Artikeln und selbst angelegten Seiten. Leider ist aber sowohl Backend als auch Frontend in den Standardtexten betroffen. zb Übersicht, weiterführende Links, Anzeige wählen,… alle Umlaute auch falsch. Steht solche Texte auch in der db?
Umlautproblem im Frontend und Backend Lösung Durch den import der sql Datei (die von Haus aus anscheinend bereits die falschen Umlaute enthielt) sind viele Umlaute falsch dargestellt. Lösung: phpMyAdmin Tabelle s_core_snippets exportieren, text kopieren und in eine Textdatei einfügen, mit suche und ersetzen folgende Zeichen ersetzen: ä ä ß ß Ã¼ ü Ä Ä Ã¶ ö Ãœ Ü (großes Ö hab ich leider nicht gefunden) dann in phpMyAdmin tabelle leeren, auf SQL Anweisungen gehen und ab dem Import befehl hineinkopieren. Shopcache leeren fertig danke
[quote=“theexplainer”]Umlautproblem im Frontend und Backend Lösung Durch den import der sql Datei (die von Haus aus anscheinend bereits die falschen Umlaute enthielt) sind viele Umlaute falsch dargestellt. Lösung: phpMyAdmin Tabelle s_core_snippets exportieren, text kopieren und in eine Textdatei einfügen, mit suche und ersetzen folgende Zeichen ersetzen: ä ä ß ß Ã¼ ü Ä Ä Ã¶ ö Ãœ Ü (großes Ö hab ich leider nicht gefunden) dann in phpMyAdmin tabelle leeren, auf SQL Anweisungen gehen und ab dem Import befehl hineinkopieren. Shopcache leeren fertig danke[/quote] Habe die Tabelle exportiert und nach ü für ein fehlerhaftes ü gesucht, konnte aber nix finden, obwohl eine Shopseite mit “R?ckgabe” übertitelt wird. " ‘charset’ => ‘latin1’ " in der application.php hatte auch keine Auswirkung. Mit der Zeile " ‘host’ => $DB_HOST " war mein Shop nicht mehr zu erreichen. Bei beiden Versuchen hab ich auch den Shopcache geleert. Gehen eure Lösungsansätze bei der Shopware V 3.5.6 überhaupt???