Mail eindeutschen

[guest*]

Hallo,

hat es schon jemand umgesetzt, dass die Anschreiben nicht wie prestaüblich:

Hallo Vorname Nachname

übergeben werden.
Eigentlich ist es bei uns nach wie vor üblich die Höflichkeitsform zu nutzen wie: Sehr geehrte Frau Nachname oder Sehr geehrter Herr Nachname.

Ich hatte bei der Version 1.3.6. das mal probiert:

Sehr {if $customer->gender == 2}geehrte {else}geehrter {$customer->gender == 1}{/if}

Die Variablen werden jetzt garnicht mehr übergeben und auch die Auswahl mit entweder/oder hat nie funktioniert.

Kann mir jemand bitte hierbei helfen ?

LG


Conny

[Lockesoft]

Hallo Conny,

Du schreibst zum einen nicht, wo du das einfügen möchtest, das oben sieht nach einem Text in einer E-Mail aus ?
Und wie es aussieht stimmen die Bezeichner für die Datenquelle nicht. In Deinem Beispiel heisst es

$customer->gender ==

funktionieren tut es aber erst mit

$customer-> id_gender ==

Im ganzen, wie im es auch im germanInstaller 1.3.7 der drüben im HPC-Forum zu finden ist, sieht das dann so aus:

/classes/PaymentModule.php ca. Zeile 320

                    $data = array(
                   // Germanized Gender
                   '{gender}' => ($customer->id_gender == 1 ? 'Herr' : ($customer->id_gender == 2 ? 'Frau' : '')),
                   '{gender_long}' => ($customer->id_gender == 1 ? 'geehrter Herr' : ($customer->id_gender == 2 ? 'geehrte Frau' : 'geehrte(r)')),
                   '{firstname}' => $customer->firstname,

Das ergibt für die order_conf-Mails schonmal {gender} und {gender_long}
Ergänzend noch in die OrderHistory.php ca bei Zeile 132 und fast alle Mails werden mit {gender}und {gender_long} bedient.

            $data = array('{lastname}' => $result['lastname'], '{firstname}' => $result['firstname'], '{id_order}' => intval($this->id_order), 
       // Germanized 18.11.2010: http://www.homepage-community.de/index.php?topic=773.0;msg10078#msg10078
           '{gender}' => ($result['id_gender'] == 1 ? 'Herr' : ($result['id_gender'] == 2 ? 'Frau' : '')),
           '{gender_long}' => ($result['id_gender'] == 1 ? 'geehrter Herr' : ($result['id_gender'] == 2 ? 'geehrte Frau' : 'geehrte(r) ')));
           if ($templateVars) $data = array_merge($data, $templateVars);

Hoffe, das hilft Dir weiter.

LG Klaus / Lockesoft

[guest*]

Hallo Klaus,

im titel steht es doch ? Mail eindeutschen... Der Code wurde mir damals von rocky genannt. Hat auch teilweise damit funktioniert leider aber die if-Abfrage nicht.

Jetzt werden diese Variablen in der Version 1.4.0.17 an keiner einzigen Mail mehr weitergegeben. Wurden diese Variablen eingespart ?

Auch häge ich mit der Variable Gewicht, welche ich in der Bestellbestätigung und Warenkorb miteingebaut hatte.

Diese Variable wird genausowenig in der Mail und im cart.tpl mitübernommen.

Die Version 1.3. hilft mir eigentlich nicht viel, da ich bereits auf die Version 1.4.0.17 umgestiegen bin und zwar direkt von 1.3.6 auf 1.4.0.17.

LG

Conny

[Lockesoft]

Hallo Conny,

ich habe mir nochmal die alten Postings dazu rausgesucht und da steht nichts vom Einbau dieser Abfrage in das Mail-Template. Auch dort wird von Änderungen in die PaymentModule.php geschrieben.
Natürlich muss in der Mail-Vorlage die Variable eingebaut werden, aber die eigentliche Entscheidung, womit die Variable befüllt wird fällt in der PaymentModule.php bzw. der OrderHistory.php.
Ähnliches dürfte auch für die Gewichtsvariable gelten

In den "Werks"-Dateien sind diese Änderungen natürlich noch nicht drin, wobei hier aber auch gesagt werden muss, dass dieser Weg aus der Lösung für die 1.3.er nicht der Königsweg ist. Für sowas würde sich das Override-Konzept anbieten.
Allerdings bin auch ich da noch schwer am Knacken, das erstmal zu verstehen. Leider ist das mal wieder arg wenig dokumentiert.

Viele Grüße

Klaus / Lockesoft

[guest*]

Hallo Klaus,

ja Du hast Recht. Auch die PaymentModule,php war abzuändern.

http://www.prestashop.com/forums/viewthread/66992/configuring___using_prestashop/change_attention_to_in_mails

Ja die Lösung durch die PaymentModule.php bzw. OrderHistory.php ist eher ein Hack, als eine Lösung. Eigentlich sollte Presta das standardmäßig eingebaut haben, wo ja fast jeder nach Gewicht versendet….

Im Produkt habe ich jetzt das Gewicht einmal stehen, allerdings mit dem Problem, dass der code:

'{total_weight}' => $order->getTotalWeight() . ' ' . Configuration::get('PS_WEIGHT_UNIT'));

unter den Tabreiter Module folgende Fehlermeldung bringt:

Parse error: syntax error, unexpected T_DOUBLE_ARROW in …\classes\PaymentModule.php on line 405

In der OrderHistory.php konnte ich den Code nicht einbauen. Es gibt nicht einmal eine ähnliche Passage mit “wrapping”, somit bleibt das Gewicht im Warenkorb, leider wieder ausständig.

Hast Du auch eine Idee, wie ich die Hersteller wieder in die product.tpl hineinbekommen. Denn dieser ist bei mir detto futsch…

http://www.prestashop.com/forums/viewthread/77929/configuring___using_prestashop/manufacturer_with_link_in_product_dot_tpl/

Am Code selbst der override habe ich mich garnicht rangemacht, da ich a) kein Programmierer bin und meinen Presta nach 6 Monaten endlich auch mal online sehen möchte. Hatte ich auch schon immer Probleme mit der Sprache DE und Presta, was mich auch extrem aufgehalten hat (Updates und kein DE als Standard UND jede Menge Probleme beim Updaten der einzelnen Versionen).

LG

Conny

[Lockesoft]

Hallo Conny,

bei der Fehlermeldung oben, wäre mal interessannt, was denn konkret in der Zeile 405 der PaymentModule.php steht?
Evtl. auch ein paar Zeilen davor und dahinter. Oki, während des schreibens mal in eine unbearbeitete PaymentModule.php rein geguckt, das müsste das Ende des Datenfelds (Array) sein.
Ein parse-Error ist ganz salopp ausgedrückt ein Rechtschreibefehler, der PHP-Interpreter versteht Dein Script dann einfach nicht, weil ein oder mehrere Zeichen falsch sind.
Gerne genommen sind an der Stelle fehlende oder überzählige Klammern, die halten nun mal Funktionen und Variablen im richtigen Zusammenhang. :-) Wie bei Mathe *g*
Ebenfalls gerne regt sich der Interpreter auf, wenn man ein ; vergisst oder auch hier wieder zuviel macht. :-)
Anführungszeichen oben und das ' sind auch noch ganz oben in der Liste der Tippfehler. :-)

In Deinem Fall heisst das:

$data = array(

eröffnet mit der ( das Datenfeld/Array

                    '{firstname}' => $customer->firstname,
                   '{lastname}' => $customer->lastname,

einzelne Einträge im Feld werden mit , getrennt

                    '{total_wrapping}' => Tools::displayPrice($order->total_wrapping, $currency, false, false));

Beim letzten Eintrag schliesst die zweite der anwesenden ) das datenfeld und das ; sagt der Befehl ist zu Ende
Hast Du jetzt beim vorletzten Eintrag auch ein Semikolon, ich denke, Du hast das hinten angefügt, dann gibts Mecker vom Interpreter. *g*

Zum Gewicht im Warenkorb, glaube ich, dass weder die PaymentModule.php noch die OrderHistory.php die richtigen Orte sind. Das klingt mehr nach einer Sache in den Templates des Themes. Konkret denke ich da an shopping-cart.tpl und shopping-cart-productline, eigentlich eher die erste von den beiden, in der ...product-line ist mehr der Tabellenkopf des Warenkorbs, eben halt die Zeilen für die Produkte behandelt.

Die Sache mit dem Herstellerlink muss ich mir selber erst angucken.

LG Klaus

[guest*]

Hallo Klaus,

Die Fehlermeldung kommt wenn ich die nachstehende Zeile einbaue:

'{total_weight}' => $order->getTotalWeight() . ' ' . Configuration::get('PS_WEIGHT_UNIT')); 

Parse error: syntax error, unexpected T_DOUBLE_ARROW in ...\classes\PaymentModule.php on line 405

Die Zeile davor:

'{total_shipping}' => Tools::displayPrice($order->total_shipping, $currency, false, false), 
'{total_wrapping}' => Tools::displayPrice($order->total_wrapping, $currency, false, false));

und die Zeilen danach:

    if (is_array($extraVars))
                       $data = array_merge($data, $extraVars);

[guest*]

Ah ja und im Template habe ich folgende Zeile. Die ist es aber nicht. Denn ich habe die Zeile aus der PaymentModule.php wieder rausgelöscht und den smarty/compile noch nicht gelöscht und die Fehlermeldung ist bei den Modulen weg, und ich kann auch wieder diese aufrufen und das Gewicht wird auch im Produkt weiterhin angezeigt. Ich weiss dass das aber nur aus dem compile cache kommt. Sobald ich den leere, funzt die Variable in der product.tpl nicht mehr:

                <!--weight-->

{l s='Gewicht/Einheit:'} {$product->weight} {$weightUnit}  

Nicht meckern. Ich weiss, dass die Variable so nicht für andere Sprachen weitergebe, aber mein Shop ist nur DE!

[guest*]

Interessannt wäre auch noch für mich, wie man im Produkt jetzt den Hersteller wieder einbaut:

<!--manufacturer   -->

{l s='Weitere Produkte von'}: {$product->manufacturer_name|escape:'htmlall':'UTF-8'}

wird nämlich auch in der 1.4.01.7 nicht mehr weitergegeben...

[Lockesoft]

Hallo Conny,

also hast Du ungefähr das:

'{total_shipping}' => Tools::displayPrice($order->total_shipping, $currency, false, false), 
'{total_wrapping}' => Tools::displayPrice($order->total_wrapping, $currency, false, false)); 
'{total_weight}' => $order->getTotalWeight() . ' ' . Configuration::get('PS_WEIGHT_UNIT')); 

in der Datei stehen und da sind genau die zwei Fehler drin, die ich Dir beschrieben habe. Im Codeschnippsel Zeile 2 wird das Datenfeld mit der zweiten ) bereits geschlossen um dann in Zeile Drei zu versuchen, da noch einen Wert anzuhängen.
Ebenso wird der komplette Befehl zum anlegen des Feldes bereits in Zeile 2 mit dem Semikolon für beendet erklärt, um dann doch weiter zu machen. Versuchs mal so:

'{total_shipping}' => Tools::displayPrice($order->total_shipping, $currency, false, false), 
'{total_wrapping}' => Tools::displayPrice($order->total_wrapping, $currency, false, false), 
'{total_weight}' => $order->getTotalWeight() . ' ' . Configuration::get('PS_WEIGHT_UNIT'),
); 

Damit sollten die Mails jetzt richtig bestückt werden.
Beim Rest muss ich mich, wie ich nach einem ersten schnellen Drüber gucken fest gestellt habe, etwas eingehender mit befassen und da ich selber gerne upgraden würde, wird das zeitmässig hier auch etwas enger. Aber, wenn ich mal wieder mit meinen Baustellen nicht vorankomme gucke ich mir zur Abwechslung dann Deine Baustellen an. Also bitte nicht böse sein, wenn die Lösung nicht in den nächsten Minuten geliefert wird. :-)

LG Klaus

[guest*]

Hallo Klaus,

also ich war nah dran. Ich hatte die letzte Klammer bei PS_Weight_Unit auch schon weggenommen, was eben nichts brachte. Auf die Idee die Klammer auch aus der Vorzeile zu nehmen und die letzte zu versetzen, kam ich leider nicht. Ich bin ja kein Programmierer, habe aber mal in der Schule Basic gelernt und nie angewandt...
Die Fehlermeldung war mir schon bekannt worum es geht, aber meine Änderungen haben eben nichts gebracht.

Ich habe jetzt diesen Code:

'{total_wrapping}' => Tools::displayPrice($order->total_wrapping, $currency, false, false),
'{total_weight}' => $order->getTotalWeight() . ' ' . Configuration::get('PS_WEIGHT_UNIT'));

liefert keine Fehlermeldung mehr und das Gewicht wird in den product.tpl auch angezeigt. Ich baue das jetzt mal analog auch in die Mail ein, bzw. in den Warenkorb. Mal sehen, ob ich weiterkomme....

Danke für die Unterstützung.

LG

Conny

[bonbontamura]

Hallo cd2500 und Klaus,

funktioniert etwa die Anrede bei Euch?
Ich habe jetzt die Version 1.4.0.17 in meinem Server installiert und die Anleitung vom Klaus gefolgt, wie ich die Datei PaymentModule.php und OrderHistory.php ändern sollte. Und in Mail-Template habe ich {gender_long} hinzugefügt wie z.B. in BankWire-Template:

Sehr {gender_long}  {firstname} {lastname},

Aber geht's leider nicht.
wie gesagt, die Datei orderhistory.php und paymentmodule.php habe ich nur wie die Beschreibung vom Klaus geändert.

[guest*]

Nö funzt nicht. Ich habe die komplett überall ausgebaut. Ist ja mehr als peinlich wenn man den Kunden mit Hallo... anspricht. Alternativ wäre es statisch zu machen indem man überall Sehr geehrte® Kundin(Kunde) einbaut. Was ja dann auch genau so blöde ist, wenn keine Ansprache da ist. Ich habe die Texte dafür so abgeändert, dass man auf das Sehr geehrte... verzichten kann.

[Lockesoft]

Hallo zusammen,

Versucht mal die zwei Dateien unten, die bauen {gender} und {gender_long} bei mir erfolgreich ein. Das {total_weight} ist auch dabei.
Was ich der PaymentModule.php für die Shopversion 1.4.x noch nicht beibringen konnte sind die Variablen {total_tax} und {total_paid_without_tax}. Die hab ich bei mir in den Mails derzeit auskommentiert.

LG Klaus / Lockesoft

PaymentModule.php

OrderHistory.php

[bonbontamura]

Ich verstehe auch nicht wieso Prestashop di Anrede nicht gleich als Standard programmiert hat.
Danke Klaus für die Dateien. Ich werde es gleich probieren und melde mich wieder

[guest*]

Tja. Ich habe mittlerweile, weil ich update seit 1.3.1.1, also fast ein Jahr jede Version, es davon abgesehen Anpassungen in .php Dateien zu machen. Bei jedem Update wird das überschrieben. Ist mir zu mühsam. Ich habe dafür ein eigenes Theme und versuch nur dort Zentral meine Anpassungen zu steuern. Das erspart mir enorm viel Zeit und lässt ein update reibungsloser verlaufen.

[eitschpi]

Hallo zusammen,

 

Versucht mal die zwei Dateien unten, die bauen {gender} und {gender_long} bei mir erfolgreich ein. Das {total_weight} ist auch dabei.

Was ich der PaymentModule.php für die Shopversion 1.4.x noch nicht beibringen konnte sind die Variablen {total_tax} und {total_paid_without_tax}. Die hab ich bei mir in den Mails derzeit auskommentiert.

 

LG Klaus / Lockesoft

 

Hallo Forum, Hallo Klaus,

 

ich versuche im Moment ebenfalls die Mails einzudeutschen.

Die Erweiterung oben funktioniert leider nicht bei meiner Version (PrestaShop Version 1.5.4.1)

Hat das schone jemand eingepflegt und kann mir helfen?

 

Mein Versuch:

PaymentModul.php

In Zeile 561

 

 

'{gender}' => ($this->context->customer->id_gender == 1 ? 'Herr' : ($this->context->customer->id_gender == 2 ? 'Frau' : '')),

'{gender_long}' => ($this->context->customer->id_gender == 1 ? 'geehrter Herr' : ($this->context->customer->id_gender == 2 ? 'geehrte Frau' : 'geehrte®')),

 

 

LG

Peter

Edited May 7, 2013 by eitschpi (see edit history)

[Lockesoft]

Hallo Peter,

 

habe hier jetzt mal die Deine Zeilen angetestet. ( Evtl. beim nächsten Mal in codetags setzen? das ist besser lesbar) Bei mir klappt das so wie Du es da versuchst.

Allerdings solltest Du die orginal PaymentModule nicht verändern und das ganze in einen Override einfügen.

Das eine leere Datei Paymentmodule in /override/classes erstellen und zuerst das folgende einfügen:

<?php
abstract class PaymentModule extends PaymentModuleCore
{

}

dann zwischen die beiden geschweiften Klammern die komplette Funktion "publik function validateOrder()" bis hin zur schliessenden geschweiften Klammer direkt vor der nächsten Funktion kopieren und einfügen.

In diesem Konstrukt kannst Du dann die Anpassungen vornehmen. Am Ende das Ganze speichern und im Verzeichnis /cache Deines Shop die Datei "class_index.php" löschen. Die muss gelöscht werden, damit PS merkt, dass der Override dazu gekommen ist. Keine Bange, die wird umgehend neu aufgebaut.

 

Oder, da ich das ganze neben dem Schreiben des Postings parallell dazu auch probiert habe nimmst Du die angehängte Datei und kopierst diese in /override/classes und löscht die /cache/class_index.php

 

Der angehängte Override sollte an sich ab PS-Version 1.5.2 funktionieren, ab da sind im Orginal keine privaten funktionen mehr drin, habe aber jetzt auch nicht alle Presta-Zips durch gesehen. evtl. geht es auch eine oder zwei kleine Versionen früher.

 

LG Klaus / Lockesoft

[guest*]

@ eitschpi, bitte nicht so alte Postings ausgraben. Wie man im Post erkennen kann handelt die Lösung für eine PS Version 1.3. bzw. 1.4.

 

Der code für PS 1.5. ist komplett anders. Andere User können das verwirrend finden und fehlerhafte Anpassungen vornehmen.

In so einem Fall bitte einen neuen Topic eröffnen. Danke.

[eitschpi]

@Klaus

Merci für die ausführliche Erklärung & Deine Mühe, ich finde zwar die angehängte Datei nicht, werde es aber wohl dennoch irgendwie hinwurschteln ;-)

 

@cd2500 sry, das nächste mal mach ich einen neuen Thread auf.

[guest*]

Danke.

[eleazar]

Hallo Klaus, hallo Peter,

 

ja, es funktioniert, nur nicht ganz so wie erhofft. Ich habe selbst eine Weile gebastelt und getestet, aber der erhoffte Erfolg will sich leider nur teilweise einstellen. Die hier vorgestellte Lösung mit Lang- und Kurzfassung ist etwas unlogisch, denn man müsste ja im Mail Text ein einleitendes "Sehr" belassen, was dann in der ersten Form unschön zu

 

"Sehr Herr Tünnes Schäl"

 

aufgelöst würde. Ich habe die genaue Vorgehensweise mal hier gepostet:

http://www.prestashop.com/forums/topic/245472-tipp-bestellbestatigung-mit-personalisierter-anrede/n

 

und gleich ein Override mit dran gehängt. Funktionieren tut das Ganze übrigens nur bei der order_conf.html, die anderen Mails mögen anscheinend die neue Variable nicht. Und dann muss man sich auch noch hüten, dass die Frauen nicht plötzlich mit "Sehr geehrter Herr" angesprochen werden (s. mein Post).

 

Viele Grüße,

Rainer

[eitschpi]

Hallo Rainer,

 

ich glaube da vertust Du dich.

Beim Script von Klaus ist die zweite Abfrage : (also wenn gender_id undefined ist) die Auflösung => geehrte®

 

Danke für den Link, werde ich mir gleich ansehen.

 

Viele Grüße

Peter

Edited May 7, 2013 by eitschpi (see edit history)

[eleazar]

Du, ich glaube, dass ist wohl eher als Nummer 3 gedacht: Herr, Frau, Firma ...

 

Außerdm hätte ich mal richtig lesen sollen! Klaus hatte ja schon darauf hingewiesen, dass es nicht reicht, nur die PaymentModule.php zu ändern, weil die sich nur auf die Bestellbestätigung bezieht. Hab daher mein kleines Tutorial noch mal erweitert.

[eitschpi]

Ach ja Firmen gibt es ja auch noch...

aber dann macht das geehrte® wenig Sinn oder?

 

Keine Idee - muss ich testen.

 

Dir noch einen schönen Abend

Peter

Edited May 7, 2013 by eitschpi (see edit history)

[Lockesoft]

Hallo Klaus, hallo Peter,

 

ja, es funktioniert, nur nicht ganz so wie erhofft. Ich habe selbst eine Weile gebastelt und getestet, aber der erhoffte Erfolg will sich leider nur teilweise einstellen. Die hier vorgestellte Lösung mit Lang- und Kurzfassung ist etwas unlogisch, denn man müsste ja im Mail Text ein einleitendes "Sehr" belassen, was dann in der ersten Form unschön zu

 

"Sehr Herr Tünnes Schäl"

 

aufgelöst würde. Ich habe die genaue Vorgehensweise mal hier gepostet:

http://www.prestasho...ierter-anrede/n

 

und gleich ein Override mit dran gehängt. Funktionieren tut das Ganze übrigens nur bei der order_conf.html, die anderen Mails mögen anscheinend die neue Variable nicht. Und dann muss man sich auch noch hüten, dass die Frauen nicht plötzlich mit "Sehr geehrter Herr" angesprochen werden (s. mein Post).

 

Viele Grüße,

Rainer

Hallo zusammen,

 

der Hintergrund bei den Zwei Variablen ist an sich, das Chris ( HomepageCommunityForum) das damals über die Variable {gender} nur mit Herr / Frau / und halt eben nichts eingesetzt hatte. da hätte man im Mailtext auch noch ein geehrte® ( das sollen Zwei Klammerrn und ein r sein) Das fand ich damals allerdings unpassend, weil ja auch das geehrte® sich mit ändert, also habe ich das für meine Mailpakete damals mit einer Zweiten Variable {gender_long} eingebaut. Und das seltsame Konstrukt mit den ( r ) taucht nur noch bei der dritten und vierten Option auf, also, wenn entweder nichts angegeben wurde oder direkt die dritte Checkbox ausgewählt wurde.

 

Ja, die PaymentModule.php ist nur die halbe Miete, die OrderHistory.php gehört ebenso, wie die Mail.php (im wesentlich für ein Impressum in der Mail) auch noch dazu. Im Post war jetzt zuletzt von der PaymentModule.php die Rede, daher habe ich mir die zuerst vorgenommen.

 

Ansonsten, mal ehrlich, wenn ich doch eh die Mailvorlage anfassen muss um die neue Variable einzubauen und das "Hallo" zu entfernen.........:-)

Man muss sich ja eh entscheiden, was man letztlich genau machen will, beide Variablen gleichzeitig ist wohl ein klein wenig unsinnig. :-)

Für meine eigenen Entwicklungen bin ich da eh mittlerweile noch auf einem etwas anderen Pfad, da werden die Variablen mehr {gender_de] oder {gender_fr} usw. heissen und die jetzige {gender_long} ersetzen.

 

Was den Anhang angeht stehe ich anscheinend ein klein wenig mit der Programmlogik des Forum auf Kriegsfuss. Ich bin sicher, ich hatte alles bereits zum Upload vorbereitet, hab aber glaube ich noch einmal Tippfehler verbessert. jedenfalls ist das File nicht da, also versuch ich das jetzt nochmal.

 

LG Klaus

PaymentModule.php

Edited May 7, 2013 by Lockesoft (see edit history)

[eleazar]

Hallo Klaus,

 

gut dass du in deiner Version die Variable {total_tax} mit drin hast. Die hatte ich in diesem Override glatt vergessen. Dafür sind bei mir noch Formatierungen für die numerischen Werte in den Mails mit drin, da die angegebenen Mengen und Preise bis auf die Gesamtsumme linksbündig formatiert sind (Zeilen 257 - 275; in deiner Version 247-265):

 

$products_list .=
   '<tr style="background-color: '.($key % 2 ? '#DDE2E6' : '#EBECEE').';">
    <td style="padding: 0.6em 0.4em;width: 15%;">'.$product['reference'].'</td>
    <td style="padding: 0.6em 0.4em;width: 30%;"><strong>'.$product['name'].(isset($product['attributes']) ? ' - '.$product['attributes'] : '').' - '.Tools::displayError('Customized').(!empty($customization_text) ? ' - '.$customization_text : '').'</strong></td>
    <td style="padding: 0.6em 0.4em; width: 20%;text-align: right;">'.Tools::displayPrice(Product::getTaxCalculationMethod() == PS_TAX_EXC ?  Tools::ps_round($price, 2) : $price_wt, $this->context->currency, false).'</td>
    <td style="padding: 0.6em 0.4em; width: 15%;text-align: right;">'.$customization_quantity.'</td>
    <td style="padding: 0.6em 0.4em; width: 20%;text-align: right;">'.Tools::displayPrice($customization_quantity * (Product::getTaxCalculationMethod() == PS_TAX_EXC ? Tools::ps_round($price, 2) : $price_wt), $this->context->currency, false).'</td>
   </tr>';
  }
  if (!$customization_quantity || (int)$product['cart_quantity'] > $customization_quantity)
   $products_list .=
   '<tr style="background-color: '.($key % 2 ? '#DDE2E6' : '#EBECEE').';">
    <td style="padding: 0.6em 0.4em;width: 15%;">'.$product['reference'].'</td>
    <td style="padding: 0.6em 0.4em;width: 30%;"><strong>'.$product['name'].(isset($product['attributes']) ? ' - '.$product['attributes'] : '').'</strong></td>
    <td style="padding: 0.6em 0.4em; width: 20%;text-align: right;">'.Tools::displayPrice(Product::getTaxCalculationMethod() == PS_TAX_EXC ? Tools::ps_round($price, 2) : $price_wt, $this->context->currency, false).'</td>
    <td style="padding: 0.6em 0.4em; width: 15%;text-align: right;">'.((int)$product['cart_quantity'] - $customization_quantity).'</td>
    <td style="padding: 0.6em 0.4em; width: 20%;text-align: right;">'.Tools::displayPrice(((int)$product['cart_quantity'] - $customization_quantity) * (Product::getTaxCalculationMethod() == PS_TAX_EXC ? Tools::ps_round($price, 2) : $price_wt), $this->context->currency, false).'</td>
   </tr>';

 

Viele Grüße,

Rainer

[Lockesoft]

Hallo Rainer,

 

nich dafür :-)

wo ich einmal dabei war, weil ich es ja letztlich für die Mailpakete auch brauche, hatte ich das auch noch kurz angetestet und dann schlicht drin gelassen. Ist doch etwas, was die meisten hier in Ihren Mails verwenden können...

 

wenn man es genau nimmt müsste man an der Stelle auch noch ein klein wenig mehr tun, da diese Produktliste nun mal html-formatiert ist und dementsprechend in der TXT-Mail grottig schlecht aussieht. :-)

Im Prinzip haben wir damals die Variable nochmal mit dem Zusatz txt und ohne html-formatierung eingebaut.

 

LG Klaus