E-Mails zeigen HTML-Code statt Umlauten an

[Lockesoft]

Bei den Fehlermeldungen ganz unten verstecken sich zwei Kleinigkeiten, die an sich richtig wären, aber an der Stelle, an denen Sie zum Einsatz kommen nicht gut aussehen.

Konkret geht es um die Zwei kleinen Sätze zu den Virtuellen Produkten in der Variable {virtual_products}.

Zum einen heisst es "verfällt am" und "%d mal möglich"

Bei beiden Texten werden die Sonderzeichen (ä,ö) mit Ihrem HTML-Code in die E-Mail übernommen. Das sieht in den HTML-Mails nur Schlecht aus und könnte bei Textmails dazu führen dass die Mails im Spamordner landen. Der ein oder andere Spamfilter mag als Text deklarierte Mails mit gemischtem Inhalt gar nicht. Also sollte man in jedem Fall die ae bzw. oe verwenden.

 

Zum zweiten finde ich könnte man auch direkt ganze Sätze daraus machen:

Der Download verfaellt am:

der Download ist %d mal moeglich.

 

Ach und wie ich da gerade an der Stelle in den Fehlermeldungen stöbere. :-)

 

Kurz  da drunter findet sich noch ein: Klasse Steuerwaltung inicht gefunden (%s)

 

Übersetzungsstand hier : 16.09.2013

 

LG Klaus / Lockesoft

 

Edit: ich hatte doch noch einen Screenshot vorbereitet ...

Edited September 16, 2013 by Lockesoft (see edit history)

[eleazar]

Nein Klaus, Umlautumschreibungen wären ein echter Rückschritt. Bis auf das Ampersand (&) müssen Umlaute und Sonderzeichen bei UTF-8-kodierten Seiten nicht mehr durch Umschreibungen ersetzt werden. Hier ist offenbar der Server deines Kunden nicht richtig konfiguriert. Bei mir kommen die Mails nämlich korrekt an und bei den meisten anderen wahrscheinlich auch.

 

Dann gib doch deinem Kunden lieber den Tipp, dass er folgende Eintragung in seiner .htaccess (aber oberhalb der Eintragungen von PrestaShop!) macht:

AddCharset utf-8 .css .html .xhtml

Den Tippfehler 'inicht' habe ich gerade beseitigt. Danke für den Hinweis.

 

Gruß

Rainer

[Lockesoft]

Hallo Rainer,

 

Sorry, wenn ich da jetzt ein wenig skeptisch gucke, dass es bei Dir problemlos funktioniert. Es wird aber sehr sicher nicht an den Servereinstellungen liegen.

Evtl. an Deinem Mailprogramm, aber mit großer Wahrscheinlichkeit nicht am Server.

 

Hintergrund:

Die Variable {virtual_products}, die den Downloadlink und die Übersetzungen enthält wird in der /classes/order/OrderHistory.php gebildet.

Das dort zusammengesetzte Array wird mit Tools::htmlentitiesUTF8 an die Funktion htmlentitiesUTF8 in der /classes/tools/Tools.php zum umwandeln übergeben.

Dort wird auf das Array der PHP-Befehl htmlentities angewandt.

Und der macht nichts anderes als HTML-Code für alle die Orginalzeichen, die eine HTML-Code-Entsprechung haben in eben diesen HTML-Code umzuwandeln.

 

Folglich stehen in Deinen Mails garantiert auch die HTML-Codes drin. Evtl. zeigt Dein Mailprogramm die dann auch korrekt an. Mein Standardmailprogramm (kmail) tut das nicht. Aber das ist letztlich auch der Grund, warum hier kein Outlookexpress oder ähnliches läuft. Wenn Mail-Code fehlerhaft ist, möchte ich das sehen, bevor der Virus eingeschleust worden ist. :-)

 

Es ändert dennoch nichts daran, dass ebenso wie beim Modul Bankwire / Vorkasse / Überweisung (wahrscheinlich auf ähnlichem  Weg) dann HTML-Codes auch in Textmails eingefügt werden. Mit unter Umständen den oben erwähnten Folgen.

 

LG Klaus / Lockesoft

Edited September 17, 2013 by Lockesoft (see edit history)

[eleazar]

Das ändert aber nichts daran, dass die meisten Kunden aller Wahrscheinlichkeit nach entweder Outlook (Express) oder Thunderbird benutzen dürften, und da gibt es nun mal keine Probleme mit der korrekten Darstellung der Umlaute.

[Lockesoft]

Nur eben, dass Sie unter Umständen die Mails gar nicht erst zu Gesicht bekommen, weil der Spamfilter des Providers diese wegen Verstößen gegen den Standard ausfiltert.

 

Eine Textmail hat eben einfach nur Text zu enthalten.

 

Ich weiss jetzt nicht was ich als schlimmer angucken soll in einer einzigen Mail zweimal einen umgeschriebenen Umlaut, oder gar keine Mail. :-)

 

LG Klaus / Lockesoft

[Pronux]

Also die Problematik mit den Sonderzeichen in Text E-Mails ist sicher nicht neu.

 

z.B.  http://stackoverflow.com/questions/1719149/send-emails-with-international-accent-and-special-characters

 

Umlaute als HTML-Code oder Umlautumschreibungen sind von mir aus gesehen in TEXT-Mails beides keine optimalen Lösungen. Diese Zeichen sollten gem. obigem Link "einfach" entsprechend codiert werden.

 

Allerdings hatte ich selber/meine Kunden bis jetzt noch nie Probleme damit. Wäre mal interessant zu wissen, ob gmail, hotmail etc. diese Mails korrekt anzeigen.

 

[Lockesoft]

Die Frage ist zum einen eigentlich: Warum werden die bereits UTF/8 codierten Zeichen überhaupt in HTML-Code umgewandelt?

 

Zum anderen scheint das obendrauf auch noch fehlerhaft zu geschehen. Hier mal eine Zeile aus dem empfangenen E-Mail-Quelltext:

</a> Der Download verf&auml;llt am:=
 2013-10-18 der Download ist 3 mal m&ouml;glich.</li></ul><=

Die ist nebenbei auch genauso in der Textmail zu finden.

so wie der Quelltext da aussieht ist es an sich unmöglich, dass DAS richtig angezeigt wird.

 

LG Klaus / Lockesoft

[guest*]

Also die Problematik mit den Sonderzeichen in Text E-Mails ist sicher nicht neu.

 

z.B.  http://stackoverflow.com/questions/1719149/send-emails-with-international-accent-and-special-characters

 

Umlaute als HTML-Code oder Umlautumschreibungen sind von mir aus gesehen in TEXT-Mails beides keine optimalen Lösungen. Diese Zeichen sollten gem. obigem Link "einfach" entsprechend codiert werden.

 

Allerdings hatte ich selber/meine Kunden bis jetzt noch nie Probleme damit. Wäre mal interessant zu wissen, ob gmail, hotmail etc. diese Mails korrekt anzeigen.

Ja diese werden korrekt angezeigt. Habe Testaccounts bei beiden Anbietern für Testaccounts im Prestashop zugeordnet. Mails werden korrekt angezeigt. Was aber nicht korrekt angezeigt wird ist im Back-Office die Nachrichten die aus Prestashop heraus generiert werden. Für mich also ein internes Problem mit dem Back-office. Die gleichen Mails kommen beim Kunden korrekt an.

[eleazar]

@CD2500

Da hast du wohl etwas verwechselt. Der Fehler im Back Office betraf nur Version 1.5.3.1 und wurde längst bereinigt:

https://github.com/PrestaShop/PrestaShop/commit/3e9e765a5abd85914c7084d7ab8c601edbb3601f

 

Das hatten wir ja hier schon mal diskutiert: http://www.prestashop.com/forums/topic/226153-keine-umlaute-bei-mail-aus-order-detail/

[guest*]

Ups, dann ist mir wohl in dem Beitrag hier entgangen, dass es sich spezifisch um die PS Version 1.5.3 aufwärts handelt. Habe übrigens das gleiche Problem unter PS 1.5.4.1. mit dem Back-office. Aber ja du hast Recht unter PS 1.5.5.0 nicht mehr vorhanden und auch nicht die Probleme im Topic 1 angesprochen, die ja bei mir niemals Thema waren, weil korrekt funktionieren.

[roblaus]

Ich kann den Umlaut Fehler bei den Downloadprodukten bestätigen - und zwar sowohl bei Outlook als auch bei Thunderbird. Die Übersetzung is allerdings korrekt. Ich habe einfach den Text umformuliert...

[eleazar]

Hallo roblaus,

 

dann melde das doch bitte mal im Bugtracker, denn an den E-Mail-Vorlagen selbst liegt es nicht. Die haben sich in dieser Hinsicht nicht geändert.

 

Als Soforthilfe schlage ich Folgendes vor: Versuch doch mal, ob die Ersetzung der Umlautzeichen in den Mails direkt zur korrekten Anzeige führt. Also z.B. statt

<p>vielen Dank für Ihre Bestellung bei <strong>{shop_name}</strong>.</p>
<p>Es liegen für Sie {nbProducts} Produkt (e) zum Download bereit.</p>

schreibst du

<p>vielen Dank für Ihre Bestellung bei <strong>{shop_name}</strong>.</p>
<p>Es liegen für Sie {nbProducts} Produkt (e) zum Download bereit.</p>

[Lockesoft]

 

Hallo roblaus,

 

dann melde das doch bitte mal im Bugtracker, denn an den E-Mail-Vorlagen selbst liegt es nicht. Die haben sich in dieser Hinsicht nicht geändert.

 

Als Soforthilfe schlage ich Folgendes vor: Versuch doch mal, ob die Ersetzung der Umlautzeichen in den Mails direkt zur korrekten Anzeige führt. Also z.B. statt

<p>vielen Dank für Ihre Bestellung bei <strong>{shop_name}</strong>.</p>
<p>Es liegen für Sie {nbProducts} Produkt (e) zum Download bereit.</p>

schreibst du

<p>vielen Dank für Ihre Bestellung bei <strong>{shop_name}</strong>.</p>
<p>Es liegen für Sie {nbProducts} Produkt (e) zum Download bereit.</p>

Hallo Rainer,

 

das ist leider nicht die in Frage kommende Stelle in der Mail. Im restlichen Text werden ja auch hier die Sonderzeichen korrekt dargestellt. Das sollte man im Screenshot oben noch erkennen können.

Der falsche Code und das ist wörtlich zu nehmen kommt ausschliesslich in der Variable {virtualProducts} der download_product mail vor. Das auch nur dann, wenn in der Übersetzung Umlaute oder anderes, was eine HTML-Codeentsprechung hat, vorhanden sind.

 

Da erstens diese HTML-Codes offenbar defekt sind und zweitens auch in der (reinen) Textemail vorkommen würden, habe ich für mich hier kurzerhand den Aufruf der Funktion Tools:htmlentitiesUTF8 in der /classes/order/OrderHistory.php enfernt.

Damit dachte ich wäre das Problem erledigt.:

Ist es auch, aber nur zum Teil. :-)

Der Umlaut aus der Übersetzung wird immer noch in HTML-Code umgewandelt. Diesmal allerdings richtig.

Offensichtlich rührt der defekte Code vom Versuch Zweimal aus Sonderzeichen HTML zu machen her.

 

Langer Rede kurzer Sinn

Habe meine Basteleien schnell noch in einen Override und den in ein Modul verpackt, so dass zumindest diesen Stand der Fehlerbehebung jeder nutzen kann.

(Es ändert natürlich nichts dran, dass derzeit immer noch HTML-Code in den Textemails landet, aber der kommt auch noch von anderen Stellen.)

 

In diesem Sinne

 

LG Klaus / Lockesoft

overridefixvp-0.1.zip