PHP Mailer 6 language file

[jspit]

Beim PHP Mailer 6 werden die language files wohl nur ohne eine zusätzliche Pfadangabe gefunden

$mail = new PHPMailer;
$languageOk = $mail->setLanguage('de'); 

wenn folgende Verzeichnisstruktur vorliegt:

   + PHPMailer
       + src
           + language

Diese Struktur erscheint mir ungewöhnlich. Liege ich da falsch oder ist da noch ein kleiner Bug im PHP-Mailer ?

[Arne Drews]

Hallo,

Das liegt daran, dass der PHPMailer 6 die Sprachdatei relativ vom Pfad der PHPMailer.php auflöst.
Nicht ganz schick, aber ich würde die PHPMailer.php dahingehend anpassen. Entweder einfach den Pfad direkt anpassen, oder variabel gestalten, um parametrisieren zu können.
Dann könnte man evtl. den Konstruktor erweitern, um einen optionalen String-Parameter, über den die setLanguage() direkt aufgerufen wird.

Der Pfad wird ca. in Zeile 1997 gesetzt:

$lang_path = __DIR__ . DIRECTORY_SEPARATOR . 'language' . DIRECTORY_SEPARATOR; 

[Messier 1001]

Nicht ganz schick, aber ich würde die PHPMailer.php dahingehend anpassen.[/PHP]

"Nicht ganz schick"? Damit verbaut man sich die Möglichkeit PHP Mailer irgenwann mal zu aktualisieren. Gaanz schlechte Idee!

[Arne Drews]

Bei einer neuen Version musst Du vermutlich eh umdenken, siehe PHPMailer 5 zu PHPMailer 6.
Und sonst erweitert man die PHPMailer-Klasse halt und der Drops ist gelutscht, so what?!

[tomBuilder]

Kann man ein solches Problem nicht einfach durch einen Link lösen?

[Arne Drews]

Wie meinst Du das?

[BlackScorp]

Wie meinst Du das?

symlink des ornders language

[jspit]

Also in den PHPMailer-Quellen rumzupfuschen ist auch nicht nach meinen Geschmack. Besser ist da den 2.Parameter zu bemühen a.la.

$languageOk = $mail->setLanguage('de','../class/PHPMailer/language/'); 

Das sind so die Vorschläge bei stackoverflow. Der Pfad muss immer entsprechend gesetzt werden, auch blöd.

Für mich selbst hab ich ein Workaround:

$mail = new PHPMailer;
$pathMailer = dirname(autoload::getFilePath('PHPMailer\\PHPMailer\\PHPMailer'));
$languageOk = $mail->setLanguage('de',$pathMailer.'/../language/'); 

Arne Drews : Bin grad dabei mit PHPMailer 6 meine Skripte zu testen die unter der letzten 5er geschrieben wurden. Soviel mit umdenken ist da gar nicht, die ersten Test's laufen 1:1.

[Arne Drews]

jspit: Die Scripte selber laufen sicherlich. Der Aufruf von bspw. send() bleibt ja meist unverändert. Die Anpassungen/Aktualisierungen stecken ja dahinter... oder wie aktuell thematisiert: Die Einbindung.

BlackScorp: Im Dateisystem Veränderungen vorzunehmen finde ich doch deutlich schlechter, wie Code anzupassen.

Code-Anpassungen sind natürlich nicht die ganz schicke Art, das sagte ich ja auch. Aber alternativ habe ich ja auch erwähnt, dass man die PHPMailer-Klasse erweitern kann, schematisch etwa so:

class ExtPHPMailer extends PHPMailer {


    public function __construct( $exceptions = null ) {

        parent::__construct( $exceptions );

    }


    public function setLanguage( $langcode = 'en', $lang_path = '' ) : bool {

        // hier halt der eigene Code, entweder komplett überschreiben oder anpassen und parent::setLanguage(...) aufrufen

    }

} 

Dann muss bei einer Inkompatiblität mit einem Udate/Upgrade maximal der eigene Code angepasst werden.
Ich würde diese Variante in diesem Fall vorziehen, was nicht heißt, dass es die beste sei.
Zumindest aber halte ich mir mit diesem Weg weitere Anpassungen offen.

[tomBuilder]

Das mit dem Link war meine Idee, nicht BlackScorp blamen. Ich habe die Erfahrung gemacht, dass sich mit Links recht schnell Probleme lösen lassen und dafür keine Anpassungen an fremdem Code gemacht werden muss.

[Arne Drews]

War auch nicht gegen BlackScorp gedacht. Hatte ihn nur angesprochen, weil er mir erklärt hatte, was mit Link gemeint war

[JaMa]

SymLinks halte ich ebenfalls für nicht schön. Wenn die Anwendung auf anderen Umgebungen ausgeführt werden soll muss jedes mal bedacht werden dass der SymLink gesetzt wird.
Würde auch die PHPMailer Klasse ableiten.

[tomBuilder]

Das hab ich nicht bedacht, geb ich zu.
Immer Klassen zu erweitern ist aber, wie oben ja niemand bestreiet für so wenig änderung auch nicht super elegant.

[Arne Drews]

Ich würde diese Variante in diesem Fall vorziehen, was nicht heißt, dass es die beste sei.
Zumindest aber halte ich mir mit diesem Weg weitere Anpassungen offen.

[jspit]

Ich habe den Ansatz von Arne Drews mal umgesetzt um das Thema hier abzurunden:

<?php
/**
 * PHPMailer Exctension class
 * this script must be saved in the same directory as PHPMailer
 * PHP Version 5.5.
 */

namespace PHPMailer\PHPMailer;

/**
 * PHPMailer Exctension
 */
class ExtPHPMailer extends PHPMailer
{
   /**
    * Set the language for error messages.
    * Returns false if it cannot load the language file.
    * The default language is English.
    *
    * @param string $langcode  ISO 639-1 2-character language code (e.g. French is "fr")
    *
    * @return bool
    */
    public function setLanguageIntern( $langcode = 'en' )
    {
        return parent::setLanguage($langcode, __DIR__.'/../language/');
    }
}

Es wird eine neue Methode zugefügt, die Orginalmethode setLanguage nicht zu überschrieben halte ich für besser.

Hab das kurz gestestet:

use PHPMailer\PHPMailer\ExtPHPMailer;

//:

$mail = new ExtPHPMailer;
$languageOk = $mail->setLanguageIntern('de');

$mail->addAddress('schnulli');
var_dump($mail->isError(),$mail->ErrorInfo);
//bool(true) string(42) "Die Adresse ist ungültig: (to): schnulli" 

Wenn keine Autoloader benutzt werden, muss neben der Klasse ExtPHPMailer auch die Orginalklasse PHPMailer geladen werden.

Die Dateistruktur muss so sein wie sie auch via Composer generiert wird:

    + PHPMailer
       + src        
       + language

und die zusätzliche Klasse ExtPHPMailer kommt mit in das Verzeichnis src.

LG jspit