Artikelname mit Umlauten

[Inge]

Guten Abend,
nach einem Serverumzug hab ich ein Problem mit den Artikelnamen mit Umlauten.
Sie werden nicht dargestellt oder ohne Formatierung dargestellt.

Meine Konfiguration:
Server OS: Linux #1 SMP Debian 3.2.57-3
Datenbank: MySQL 5.5.37-0+wheezy1
PHP Version: 5.4.4-14+deb7u9 (Zend: 2.4.0)
modified eCommerce Shopssoftware v1.06 rev 4642
Datenbank Version: "MOD_1.0.6.0"

Beispiel ohne Formatierung - hier der Reißverschluß in gelb
http://www.serviettenhaus.de/Kurzwaren/Reissverschluesse:::151_152.html
Hier fehlt der Artikelname ganz:
http://www.serviettenhaus.de/Servietten/In-den-Kueche/Kraeuter:::129_43_127.html

Beispiel keine Darstellung in den Artikeldetails:
http://www.serviettenhaus.de/Kurzwaren/Reissverschluesse/Spitzen-Reissverschluss-in-Gelb::854.html

Das hier wurde erledigt, brachte aber auch keine Abhilfe
http://www.modified-shop.org/forum/index.php?topic=25014.msg229982#msg229982

und das hier auch:
http://www.modified-shop.org/forum/index.php?topic=25014.msg229982#msg229982

und nun weiß ich auch nicht weiter, welche Dateien müssen noch angepaßt werden?
Müssen irgendwelche Seiten neu generiert werden?

Gruß
Inge



Linkback: https://www.modified-shop.org/forum/index.php?topic=30082.0

[Grumpfli]

Hallo Inge

Das Problem hatte ich auch. Nach der Umstellung auf PHP 5.3 waren die Umlautprobleme weg.

Ich hoffe bei deinem Shop hilft das auch.

Gruss
Stefan

[noRiddle (revilonetz)]

Hallo Inge.
Im Quelltext deiner Seite sehe ich charset=iso-8859-15.
Ich vermute, daß die Datenbank entweder vollständig auf utf-8 läuft oder zumindest die Collation der Tabellen.
Da stimmt etwas im Zusammenspiel von DB und Shop nicht.
Überprüfe das mal.

Die Collation der Tabellen sollte auf latin1_german1_ci stehen und die Datenbankverbindung ebenso.
Du kannst das in phpMyAdmin nachschauen.

Gruß,
noRiddle

[Inge]

Hallo noRiddle,

danke für den Tipp. Werde danach gleich morgen einmal sehen.

Gruß
Inge

[Inge]

Hallo Inge.
Im Quelltext deiner Seite sehe ich charset=iso-8859-15.
Ich vermute, daß die Datenbank entweder vollständig auf utf-8 läuft oder zumindest die Collation der Tabellen.
Da stimmt etwas im Zusammenspiel von DB und Shop nicht.
Überprüfe das mal.

Die Collation der Tabellen sollte auf latin1_german1_ci stehen und die Datenbankverbindung ebenso.
Du kannst das in phpMyAdmin nachschauen.

Gruß,
noRiddle

Hallo noRiddle,

vielen Dank für deine Antwort. In der Tat stand die Datenbank Kollation sowie die Tabellen auf "utf8_general_ci". Dieses habe ich nun für die DB sowie allen Tabellen auf "latin_german1_ci" geändert.

Im Quellcode steht das Meta Charset Encoding auf "iso-8859-15"
Und in der configure.php "define('DB_SERVER_CHARSET', 'latin1')" auf latin1.

Das Umlauteproblem ist weiterhin vorhanden.

Hat jemand vielleicht noch eine Idee, was es sein könnte?

Vielen Dank im Voraus

Gruße Inge

[Inge]

Wenn ich Dateien als UTF-8 speichere und hochlade werden die Umlaute angezeigt.
Da dies aber nicht für alle Dateien händisch machbar ist, wo liegt denn hier mein entscheidener Einstellungsfehler?

Gruß,

Inge

[Inge]

Ich habe in der Datenbank alles wieder auf UTF-8 geändert und in der configure.php die DB-Connection auf UTF-8 gestellt.

Jetzt klappts.

Hat doch keine Nachteile, oder ?

[Inge]

Als Hintergrundinfo:

Das Kernproblem war auf dem neuen Server die neue PHP-Version, bei der standardmäßig in der php.ini
default_charset = "UTF-8" stand.

Das hätte man auch anpassen können .

Gruß

Inge

[Inge]

Ich habe den Bug im Quellcode gefunden, warum es trotzdem dazu führte, dass bestimmte ArtikelNamen nicht sichtbar sind unter PHP 5.4, trotz richtiger Kollation.

/includes/classes/product.php

Zeile:
'PRODUCTS_NAME' => htmlentities($array['products_name']),

Ändern in:
'PRODUCTS_NAME' => encode_htmlentities($array['products_name']),

htmlentities hat ab PHP 5.4 einen neuen default Wert (UTF8 statt ISO) und deswegen habt ihr ja auch ein encode_htmlentities() entwickelt als Wrapper in \inc\html_encoding.php.

Bitte benutzt diese Funktion auch zukünftig, da ansonsten weitere PHP 5.4 Fehler eintreten, das Script ist damit eigentlich auch offiziell nicht PHP 5.4 ready...

Bitte den Fehler in den zukünftigen Versionen fixen!
Vielen Dank.

P.S.: Thread im BugTracker Forum konnte ich nicht erzeugen, eventuell kann jemand anderes den Bug ja offiziell an das Team herantragen. Dankeschön.

[Sick]

Kann sich hierzu mal bitte jemand vom Team äußern?
Bei mir steht auch bald ein Umzug auf PHP 5.4 an und das sind ja doch nicht ganz unwichtige Sachen.

Gruß

[noRiddle (revilonetz)]

@Inge
Was das encode_htmlentities betrifft hast du zwar Recht, das war/ist aber nicht dein Hauptproblem.
Wenn die DB auf UTF-8 steht sollte auch dein Shop die charset-Angabe UTF-8 haben.

Daß da einfache ändern der Collation in der DB nicht geholfen hat ist logisch, da die Texte ja dort in UTF-8 zu stehen scheinen
- wobei ich mich frage wie das geschehen konnte wenn dein Shop doch vor dem Umzug auf ISO-8859-15 lief -
Außerdem müssten deine Sprachfiles ja dann auch in UTF-8 (ohne BOM) abgespeichert sein.

Mir erscheint das ganze ein wenig undurchsichtig, aber ich weiß ja auch nicht alles über deine Umgebung und Einstellungen.

Es gibt mit UTF-8 noch kleine Ungereimtheiten im System, z.B. Probleme mit den aus einem urlencoded GET-Parameter geholten Fehlermeldungen wenn man keine Zahlungsart ausgewählt hat im Checkout (Javascript deaktivieren zum Testen).
Das habe ich bereits im Experten-Forum angesprochen und es soll in der kommenden Version gefixt sein.

Gruß,
noRiddle

[Inge]

Hallo noRiddle,

die Tabelleninhalte kann man ja auch nachträglich zur entsprechenden Collation ALTERN.
Das Problem konnte bei uns ja behoben werden.

Allerdings mussten wir noch über 15 weitere PHP-Scripte von Modified-Shop anpassen, die nicht PHP 5.4 kompatibel waren.

Es ist für mich nicht verständlich, warum bereits als Mindestanforderung (PHP ab 5.x bis PHP 5.4.x) aufgeführt ist, im kompletten Shop-Script allerdings noch ein Mischbetrieb zwischen alten und neuen PHP-Funktionen besteht sowie inkonsistente Anpassungen durchgeführt wurden (ggf. Qualitätsniveau unter den Programmier dramatisch unterschiedlich).

Ich bitte einfach, hier ggf. noch ein bisschen Qualität und Wert in weitere Anpassungen zu legen (Q&A).

Da mit manuellen Anpassungen erhält man einen erhöhten Arbeitsaufwand beim nächsten Update...

Danke!

[noRiddle (revilonetz)]

Tja, ich bin kein Team-Mitglied, bin also die verkehrte Adresse.

Habe eine Beta 2.0 wo es bislang nur einen Fehler mit PHP 5.4 gab den ich auch dem Team gemeldet habe.

Habe auch einen aktuellen 1.06 rev4642 Demo-Shop auf PHP 5.4, keine Probleme damit,
der läuft allerdings nicht auf UTF-8 sondern auf ISO-8859-15,
aber gerade da müsste es ja Probleme geben wegen htmlentities(), wenn irgendwo der $_SESSION['language_charset'] -Parameter nicht angegeben wurde, bzw. nicht die shop-eigene Funktion encode_htmlentities() benutzt wurde,
wo der Parameter, insofern nicht angegeben, ja automatisch auf $_SESSION['language_charset'] gesetzt wird.

Wo habt Ihr denn Inkompatibilitäten entdeckt ?
Wärst du so nett das mal zu dokumentieren ?

Gruß,
noRiddle

[Inge]

Es handelt sich um Aufrufe zu htmlentities() und htmlspecialchars(). Beide müssen angepasst werden mit ihren Prefix "encode_".

Allerdings ist ein blindes suchen und ersetzen nicht zu empfehlen. Aber eine Suche nach " htmlentites(" und " htmlspecialchars(" (Leertaste vorne um alle einzelnen Funktionen zu finden, die betroffen sind) zeigt zumindest die Dateien, die kontrolliert werden sollten.

[noRiddle (revilonetz)]

Mmmh, schon klar, aber ich vermute, daß du Unstimmigkeiten im Shopsystem hast.
Wie gesagt habe ich eine 1.06 rev4642 auf PHP 5.4 laufen, ohne Probleme.

Vermute, daß es an Mixturen liegt wie

Code: XML  [Auswählen]

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15" />

im Quelltext
aber teilweise UTF-8 Collations in der DB.
Vor allem ist auch die Codierung der Datenbankübertragung an sich wichtig.
Weiß gerade nicht wo du die in phpMyAdmin nachschauen kannst.

Gruß,
noRiddle