Email Betreff und Umlaute

[dbs]

Hallo,

es geht nur um die Email Betreffzeile:  Bestätigung und Rechnung für Ihre ....

Vielleicht habe ich den passenden Thread übersehen.
Egal ob in bakery/payment_methods/invoice/languages/DE.php ü oder ü steht, in der Datenbank steht ü.
WB und DB stehen auf UTF-8. Der Inhalt der Email wird mit korrekten Umlauten angezeigt.

Ändere ich in der Datenbank ü in ü, stimmts im Backend nicht mehr, dafür aber im Emailbetreff.

Sachdienliche Hinweise werden gern gesehen.

Gruß
dbs

[jacobi22]

bakery/payment_methods/invoice/languages/DE.php  beinhaltet die Grundeinstellung für die Seite Zahlungsmethode für einen jungfräulichen Shop, also direkt nach der Installation. Dort (Backend -> Bakery-Einstellungen->Zahlungsmethoden)  sind auch die Änderungen für den E-Mailbetreff zu machen, die dann in UTF-8 gespeichert werden.
Die Zusammenstellung der Mail und somit auch das Auslesen des Betreffs aus der DB  erfolgt in der view_confirmation.p hp
Ab hier
// Make email headers.......
wird der Mail-Header festgelegt, u.a. auch der Zeichensatz UFT-8, den du ja eingestellt hast, deswegen wird auch ü statt ü erwartet.

Solltest du in der Seite Zahlungsmethoden eine andere Anzeige haben, schau in der modify_payment_meth ods.php, dort wird auch wieder der Betreff ausgelesen, aber eben auch als UTF-8

[dbs]

Danke für die Infos.

Demnach brauche ich in der DE.php nichts ändern, weil nur bei neuangelegter Seite von dort der Inhalt geladen wird. Änderungen im Backend wandern in die DB.
Textänderungen konnte ich in der DB finden, aber die Umlaute zeigten sich in der gleichen Form und wurden beim Versenden weiter falsch wiedergegeben.
Wie gesagt betrifft das den Betreff der Email. Im Body werden Umlaute korrekt dargestellt.
Betreff und Body bekommen aber das gleiche Futter aus der DB.

Ich verstehe es noch nicht.

[jacobi22]

Textänderungen konnte ich in der DB finden, aber die Umlaute zeigten sich in der gleichen Form und wurden beim Versenden weiter falsch wiedergegeben.

in welcher Form??

die Eingabe der Betreffzeile unter "Zahlungsoptionen" erfolgt in "normaler" Form = ISO 8859, also etwa so:
Bestätigung und Rechnung für Ihre [SHOP_NAME] Bestellung

ohne UFT-8-Formatierung und auch kein ü statt nem ü

Ergebnis in der DB dann Bestätigung und Rechnung für Ihre [SHOP_NAME] Bestellung

P.S.: am Mailprogramm könnt es auch noch liegen 

[dbs]

Ergebnis in der DB dann Bestätigung und Rechnung für Ihre [SHOP_NAME] Bestellung

So steht es geschrieben.
Und im Backend ganz normal mit ä und ü.

Im Mail-Betreff genauso wie in der DB, im Mail-Body genauso wie im Backend.
Mails werden mit GMX empfangen.
Werde mal Web.de testen.

[jacobi22]

Wenn du möchtest, schick mal einen Link zum Testen

[dbs]

Scheinbar liegts an GMX, da Uwe kein Problem bei Testbestellung hatte.

[dbs]

Andererseits:
Eine Mail über das Standard-WB-Kontaktformular, wo unter Optionen > E-mail Optionen > E-mail Betreff: Umlaute eingefügt werden, kommt korrekt bei GMX an.

Brat mir einer nen Storch, please.

[jacobi22]

Laß mir ja den Storch in Ruhe 

Bakery sendet mittels eingestelltem Charset, also in UTF-8, Form wandelt vorher um.
Wenn GMX für dich überlebenswichtig ist, mußt du Bakery halt anpassen, z.b. mit htmlspecialchars_de code()  für den Betreff

[badknight]

Andererseits:
Eine Mail über das Standard-WB-Kontaktformular, wo unter Optionen > E-mail Optionen > E-mail Betreff: Umlaute eingefügt werden, kommt korrekt bei GMX an.

Brat mir einer nen Storch, please.

ohne mir den code anzusehen vermute ich einfach,

Form Modul wandelt es in HTML Zeichen um (z.B. ü statt Ü)

und das andre Modul sendet es normal mit Ü.. wenn nun aber - aus welchen gründen auch immer - keine UTF8 codierung da ist.. kommt es zu deinen Fehlern

[jacobi22]

Schick dir doch mal eine Testmail an deine GMX-Mail mit einem solchen Betreff und solchem Mailtext
Bestätigung und Rechnung für Ihre [SHOP_NAME] Bestellung

oder probier mal in der view_confirmation.p hp

statt

Code:

$cust_email_subject = stripslashes($payment_methods['cust_email_subject']);         

dies hier

Code:

$cust_email_subject = stripslashes(htmlspecialchars_decode($payment_methods['cust_email_subject']));

Zeilennummer kann ich dir nicht genau sagen, etwa um die 110. Bei mir ist alles ziemlich umgebaut
suche nach diesem Kommentar
// Get the email templates from the db

[dbs]

Schick dir doch mal eine Testmail an deine GMX-Mail mit einem solchen Betreff und solchem Mailtext
Bestätigung und Rechnung für Ihre [SHOP_NAME] Bestellung

Dann erhalte ich im Betreff und im Body die gleiche Darstellung (Mailprogramm) und auf dem GMX-Server selbst ist nur der Betreff betroffen, Body ok.

DB, WB, FF, Mailprogramm: UTF-8
Ein Test mit anderem Mailprogramm (TheBat) zeigte den Betreff korrekt, aber das soll ja kein Glücksspiel sein.

Die Änderung mit htmlspecialchars_de code brachte keine Änderung.

Mir schwirrt der Kopf, Storch ist noch in Gefahr.

[dbs]

Was sagt der Fachmann dazu? Die gleiche Zeile wie oben nur anders:

Code:

$cust_email_subject = stripslashes(utf8_decode($payment_methods['cust_email_subject']));

Damit ist es überall lesbar, jedenfalls bei mir. Aber wahrschienlich nicht die Lösung? 

[jacobi22]

Code:

$cust_email_subject = stripslashes(htmlspecialchars_decode($payment_methods['cust_email_subject']));

das war auch Quatsch von mir, sorry, is ja utf-8

so gehts bei mir

Code:

$cust_email_subject = stripslashes(utf8_decode($payment_methods['cust_email_subject']));

[/quote]

funktioniert aber nur so lang, wie du UTF-8 verwendest (siehe Einstellungen Zeichensatz unter Optionen) und auch keine Umlaute nach ISO 8859 im Betreff sind, was ja eigentlich nicht passieren kann

Alternativ: den Zeichensatz vorher abfragen (ungetestet)

Code:

if (defined('DEFAULT_CHARSET' == 'utf-8')) {$cust_email_subject = stripslashes(utf8_decode($payment_methods['cust_email_subject']));}
else
{$cust_email_subject = stripslashes($payment_methods['cust_email_subject']);
}

[jacobi22]

das war wohl fast zeitgleich

aber siehe Zusatz unten betreff der Charset-Einstellungen

[dbs]

Prima, dass ich dann doch auf dem richtigen Weg war.
Die Abfrage ist eher unötig, da UTF-8 auf jeden Fall das Charset ist für WB und sich nicht ändern wird.
Nun aber genug en- und decoded, alle Störche können aufatmen.
Danke dir, hat viel Nerven gekostet bis hierhin. 

[jacobi22]

Die Abfrage ist eher unötig, da UTF-8 auf jeden Fall das Charset ist für WB und sich nicht ändern wird.

Falls du dich mal wunderst, warum irgendwann mal lauter Fragezeichen statt Umlaute im Betreff stehen, weißt du ja, warum

alle Störche können aufatmen.

bersser ist das, man weiß ja nie, wann man den mal braucht 

[dbs]

Falls du dich mal wunderst, warum irgendwann mal lauter Fragezeichen statt Umlaute im Betreff stehen, weißt du ja, warum wink

Das Wundern hat genau einen Tag gebraucht. *grrr*
Ok, also doch Abfrage rein.
Allerdings bekomme ich beim Test dadurch wieder:

Code:

Bestätigung und Rechnung für Ihre [SHOP_NAME] Bestellung

[jacobi22]

Wenn meine Kids ankommen und jammern, der PC geht nicht, frag ich immer: was haben wir diesmal wieder kaputt gemacht? Die Antwort ist immer die Gleiche:  NIX 

Die ganze En- bzw. Decodierung ist wohl ein Denkfehler gewesen
Bisher war es so, das GMX die Betreffzeile nicht umgewandelt hat. Da der Mail-Header aber das Charset mitliefert, wird auch im Betreff UTF-8 erwartet. Die nun dargestelten Fragezeichen sind also das Ergebnis unserer Decodierung und der (jetzt mal) ordentlichen Umsetzung bei GMX.
Man müßte nun wieder zurück auf Start und darauf hoffen, das das Problem der fehlenden Umwandlung von GMX nur temporär war. Andere Variante wäre ein kompletter Umbau der Mail und ein Absenden mit anderem Header.

[badknight]

und wenn du einfach mal htmlentities verwendest zum testen?

[jacobi22]

und wenn du einfach mal htmlentities verwendest zum testen?

htmlentities() wandelt Umlaute und HTML-Tags in Unicode um, aber keine UTF-8-codierten Zeichen

[badknight]

das ist mir klar.. doch mit unicode in mails hab ich weniger Probleme als mit UTF8 ..

[jacobi22]

versteh ich ja, nur müßte man dann in Bakery alles umbauen und das nur, weil GMX ab und an mal zickt oder gezickt hat

[dbs]

Das ist leider nichts Temporäres.
htmlentities statt utf8_decode ergibt im Betreff:

Code:

Bestätigungen und Rechnung für Ihre

[jacobi22]

siehe oben....  zurück auf Start und ohne Decodierung, wenn du die Fragezeichen im Betreff hast.

hast du UTF-Zeichen im Betreff, schau dir den Header in der Mail an, was da an Zeichensatz mitgeliefert wird, ist es
UTF-8???