OXID CE: PDF-Attachment mit den AGB an Bestell-Bestätigungs-Email anhängen

Hallo zusammen,

es handelt sich hier um einen OXID CE 4.6.4.

An die Bestellungsbestätigungs-Email an den Kunden soll ein PDF mit den AGB als Attachment angehängt werden. (Gilt an sich als obligatorisch bei einem deutschen Shop, wird vom OXID CE aber scheinbar noch nicht standardmäßig unterstützt.)

Gemäß Tip aus dem Thread
http://forum.oxid-esales.com/showthread.php?t=1248

hab ich folgenden Code in die Methode

public function sendOrderEmailToUser( $oOrder )

in der

core/oxemail.php

eingebaut:


		$attachment_path = 'out/basic/img/';
		$attachment_file = 'banner_300x100.png';
		
		if (is_readable($attachment_path.$attachment_file))
		{		
			$this->addAttachment( $attachment_path, $attachment_file );
		}
		else
		{
			die ( "Fehler beim Zugriff auf die Datei!" );
		}
		
        $blSuccess = $this->send();

        return $blSuccess;

Das hab ich bereits mit mehreren Dateien in versch. Verzeichnissen probiert.

Problem:

Obwohl die Dateien jedes Mal prinzipiell auffindbar waren (Überprüfung durch PHP-Funktionen is_file( ), file_exists( ) und is_readable( ), wurden sie im Endeffekt halt doch nicht an die Mail an den Kunden rangehängt. Die Email enthält also kein Attachment.

Woran kann das liegen bzw. hat jemand einen grundsätzlichen Tip, wie man so was im OXID am Besten debuggen kann?

(Ich hab auch diverse Tips bzgl. Modulen gefunden wie z.B. https://github.com/pgaida/ppg_ordermailattach, allerdings mutet das zunächst wie mit Kanonen auf Spatzen an, zumal es so eine addAttachment( )-Methode ja gibt.)

Gruß Michl

schau mal in Zeile 1964:

http://docu.oxid-esales.com/CE/sourcecodedocumentation/4.7.6.48acf618c43d333b81bb6636f7d13a3a75ec4638/oxemail_8php_source.html#l01950

[QUOTE=Hebsacker;127998]schau mal in Zeile 1964:

http://docu.oxid-esales.com/CE/sourcecodedocumentation/4.7.6.48acf618c43d333b81bb6636f7d13a3a75ec4638/oxemail_8php_source.html#l01950[/QUOTE]

Wenn ich die Zeile rauskommentiere (anschließend die Klasse hochlade und erneut bestelle), ändert das mal noch nichts. Der Anhang ist auch dann nicht dran in der Email und es wär ja auch komisch, wenn die Klasse ihre eigenen Parameter pauschal wegrasieren würde… :slight_smile:

nicht pauschal. Nur an dieser Stelle :smiley:

Wir haben schon ein Modul für PDF Anhänge, ich darf es veröffentlichen wenn mein Chef die Lizenzbestimmungen etc geprüft hat. Heute Nachmittag ist es soweit, denke ich.

hi marat,

ich will KEINESWEGS drängeln, (gier, lechz, schlabber,…) aber hast du schon das ok vom chef? :wink:

volker

Probiers mal so (Dateien in den Sprachenordner). Ist nicht von mir, aber so gehts.

$attachment_path=$myConfig->getLanguageDir(false);
        $a_result= $this->addAttachment( $this->createMyPdf($oOrder, "" ));

oder

$b_result= $this->addAttachment( $attachment_path."agb.pdf" , 'agb.pdf', 'base64', 'application/pdf');

für das Anhängen von AGB und/oder Rechnung als PDF bzw. einem beliebigen Dateianhang gibts diverse unterschiedliche Ansätze quer durchs Forum, teilweise sogar in fertiger Modulform

Jo, aber die Ausgangsfrage ist nun mal folgende

 "Woran kann das liegen bzw. hat jemand einen grundsätzlichen Tip, wie man so was im OXID am Besten debuggen kann?"

Mir wurde erklärt, dass ich absolute Pfade ohne Angabe der ShopSource vermeiden soll. Und so geht es nun mal. :wink:

tvtotal hat die bzw. eine funktionierende Lösung präsentiert. :slight_smile:

Nach diesem Methoden-Aufruf:

$b_result= $this->addAttachment( $attachment_path.$attachment_file , 'agb.pdf', 'base64', 'application/pdf');

hängt das Attachment an der Email dran.

Die Quell-Datei muss in

/out/basic/de/

liegen (je nach Sprache natürlich, für die englische Version natürlich in

/out/basic/en/
), um den Pfad über

$attachment_path=$myConfig->getLanguageDir(false); 

auf die Ressource setzen zu können.

Danke!

Wär aber insgesamt nicht verkehrt, wenn OXID so was noch ein bisschen direkter einstellbar macht, sodass es ohne Code-Änderungen und Modul-Installation hinzubekommen ist, ein Attachment an die Emails ranzubekommen, was bei einem rechtssicheren Webshop gehen muss.