Magento2 - Befehlszeile - Senden von E-Mails mithilfe von Blockvorlagen - Fehler: Fehlendes erforderliches Argument $ debugHintsPath


11

Beim Versuch, E-Mails in Magento 2 über die Befehlszeile zu senden, ist die folgende Ausnahme aufgetreten. Während der Verwendung derselben Klasse zum Senden von E-Mails von einem Frontend- oder Backend-Controller funktionierte dies einwandfrei. Das Problem trat nur über die Befehlszeilenschnittstelle auf.

Ausnahme:

main.CRITICAL: Ausnahme 'BadMethodCallException' mit der Meldung 'Fehlendes erforderliches Argument $ debugHintsPath von Magento \ Developer \ Model \ TemplateEngine \ Plugin \ DebugHints'. in /.../.../magento/vendor/magento/framework/ObjectManager/Factory/Dynamic/Developer.php:45

Das Problem trat auch nur auf, wenn versucht wurde, einen Block über das Layout innerhalb der Vorlage aufzurufen. Sobald der Blockaufruf entfernt wurde, wird die Ausnahme nicht mehr angezeigt.

Vorlagendatei:

app / code / NameSpace / Module / view / frontend / email / email_notification.html

{{template config_path="design/email/header_template"}}

...

<!-- THIS LINE CAUSED THE EXCEPTION TO SHOW UP -->
{{layout handle="sales_email_order_items" order=$order area="frontend"}}

...

{{template config_path="design/email/footer_template"}}

Die E-Mail wurde weiterhin mit intakter Betreffzeile gesendet, aber der gesamte Inhalt wurde nicht gerendert und nur der folgende Fehler wurde im Inhaltsbereich angezeigt, sobald die E-Mail empfangen wurde.

Fehler in E-Mails gedruckt:

Fehlerfiltervorlage: Fehlendes erforderliches Argument $ debugHintsPath von Magento \ Developer \ Model \ TemplateEngine \ Plugin \ DebugHints.

Antworten:


16

Die Lösung für dieses Problem habe ich schließlich in den Magento Community-Foren gefunden, die von @ dunagan5887 bereitgestellt wurden . Ich habe beschlossen, es hier auf magento.stackexchange.com zu teilen, da viele von einer gut verwiesenen Lösung für diese Ausnahme profitieren können.

Es gibt einen Link zum ursprünglichen Beitrag im Community-Forum: E-Mail-Vorlage mit Block

Es scheint, dass diese Lösung, wie von @ dunagan5887 zitiert ;dictates that the di.xml directive set in vendor/magento/module-developer/etc/adminhtml/di.xml is loaded.

Die Lösung besteht aus dieser einfachen Codezeile:

$ this -> _ objectManager-> configure ($ this -> _ configLoader-> load ('adminhtml'));


Unten finden Sie eine Befehlszeilenklasse für Arbeitsversionen:

app / code / NameSpace / Module / Console / Command.php

<?php
namespace NameSpace\Module\Console\Command;

use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputArgument;
use Magento\Framework\Exception\LocalizedException;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;

class CustomCommandClass extends Command
{
    public function __construct(
        \Magento\Framework\App\State $state,
        \Magento\Framework\ObjectManagerInterface $objectManager,
        \Magento\Framework\ObjectManager\ConfigLoaderInterface $configLoader
    ) {
        $state->setAreaCode('frontend'); //SET CURRENT AREA
        $objectManager->configure($configLoader->load('frontend')); //SOLUTION
        parent::__construct();
    }

    ...

}

Ändern Sie einfach den Bereich von frontend zu adminoder globalwie von der Anwendung erforderlich.


[AKTUALISIEREN]

Bereich adminhtml, der Fehler bei der Bereitstellung statischer Inhalte verursacht

Es scheint, dass das Festlegen des Bereichs aus bestimmten Gründen adminhtmlbeim Bereitstellen statischer Inhalte Fehler verursacht.

Wir haben folgende Fehler festgestellt:

Fatal error: Uncaught Exception: Warning: Error while sending QUERY packet. PID=22912 in ../magento/vendor/magento/zendframework1/library/Zend/Db/Statement/Pdo.php on line 228 in ../magento/vendor/magento/framework/App/ErrorHandler.php:61

Ich dachte zunächst, dass dieser Fehler durch ein Tief verursacht werden würde max_allowed_packet Einstellung für MYSQL aber da das Limit bereits hoch genug war und das Problem dadurch nicht behoben werden konnte, entschied ich mich, weiter zu graben. Nachdem ich einen Eliminierungsprozess durchlaufen hatte, stellte ich schließlich fest, dass dies der Hauptunterschied zwischen zwei Modulen mit ähnlichen Befehlsfunktionen war, von denen eines der Module dieses Problem verursachte, sobald es aktiviert war.

Obwohl ich nicht nach der Quelle dieses Problems oder Konflikts gesucht habe, hielt ich es für eine gute Idee, meine Erkenntnisse hier zu teilen, da andere es möglicherweise nützlich finden.


[UPDATE - 2]

Die richtige Methode:

Nach dem Upgrade von Magento auf 2.2.X haben wir festgestellt, dass dies die richtige Methode zum Festlegen des Bereichs ist:

app / code / NameSpace / Module / Console / Command.php

<?php
namespace NameSpace\Module\Console\Command;

use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Input\InputArgument;
use Magento\Framework\Exception\LocalizedException;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;

class CustomCommandClass extends Command
{
    public function __construct(
        \Magento\Framework\App\State $state,
    ) {
        $this->_appState = $appState;
        parent::__construct();
    }

    ...

    protected function execute(InputInterface $input, OutputInterface $output)
    {
        $this->_appState->setAreaCode(\Magento\Framework\App\Area::AREA_GLOBAL); //SET CURRENT AREA

        ...

    }

    ...

}

Beachten Sie, dass wir den Objektmanager nicht verwenden und dass der Bereich innerhalb der Funktion festgelegt werden muss, die dies erfordert, und NICHT im Konstruktor. Dies ist die offizielle Methode zum Festlegen des Bereichs und sollte mit allen Magento 2-Versionen einwandfrei funktionieren.


Eine Liste der verfügbaren Bereiche ist in der folgenden Klasse verfügbar:

Magento \ Framework \ App \ Area

class Area implements \Magento\Framework\App\AreaInterface
{
    const AREA_GLOBAL = 'global';
    const AREA_FRONTEND = 'frontend';
    const AREA_ADMIN    = 'admin';
    const AREA_ADMINHTML = 'adminhtml';
    const AREA_DOC = 'doc';
    const AREA_CRONTAB = 'crontab';
    const AREA_WEBAPI_REST = 'webapi_rest';
    const AREA_WEBAPI_SOAP = 'webapi_soap';

    ...

Vielen Dank @ElGatito. Du rettest meinen Tag. :)
Nochmals

Ich habe den Geltungsbereich als global festgelegt und es funktioniert gut für mich.
Rakesh Jesadiya

1
WARNUNG: Verwenden Sie diesen Code ( $objectManager->configure($configLoader->load('frontend'));) NICHT im Konstruktor einer Klasse! Wenn Sie die Konfiguration aus einem anderen Bereich als Ihrem aktuellen Bereich laden, kann dies Magento 2 ernsthaft beschädigen!
Wesley Vestjens

@Wesley Vestjens +1 Vielen Dank für Ihren Kommentar. Die richtige Methode ist eigentlich sehr unterschiedlich und ich habe meine Antwort aktualisiert, um sie widerzuspiegeln. Bitte beziehen Sie sich auf [UPDATE - 2] .
ElGatito

Das bloße Festlegen des Bereichs funktioniert nicht, wenn Sie einen Teil der Ansichtsebene von Magento 2 verwenden (die zum Generieren von PDF-Dateien in Magento 2 erforderlich ist). Sie erhalten eine Fehlermeldung bezüglich des folgenden Objekts: Magento\Developer\Model\TemplateEngine\Plugin\DebugHintsweil die debugHintsPathVariable nicht gesetzt ist. Die Verwendung Ihres Originalcodes zum Laden des ADMINHTML-Bereichs DI funktioniert, oder die manuelle Einstellung der debugHintsPathVariablen funktioniert, es können jedoch auch andere defekte Teile vorhanden sein. Dies ist tatsächlich ein "Fehler" in Magento, da es nicht möglich ist, Elemente der Ansichtsebene in der CLI zu verwenden.
Wesley Vestjens

6

Da CLI in Magento keinen geeigneten Bereich hat, habe ich die folgende Problemumgehung herausgefunden:

app / code / NameSpace / Module / etc / di.xml

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:ObjectManager/etc/config.xsd">
    <!-- Add this for sending email via cli -->
    <type name="Magento\Developer\Model\TemplateEngine\Plugin\DebugHints">
        <arguments>
            <argument name="debugHintsPath" xsi:type="string">dev/debug/template_hints_storefront</argument>
        </arguments>
    </type>
</config>
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.