Magento2 - Riga di comando - Invio di e-mail utilizzando i modelli di blocco - Errore: Argomento richiesto mancante $ debugHintsPath


11

Quando ho tentato di inviare e-mail in Magento 2 dalla riga di comando, ho riscontrato l'eccezione di seguito. Mentre utilizzava la stessa classe per inviare e-mail da un controller frontend o backend funzionava perfettamente. Il problema si stava verificando rigorosamente utilizzando l'interfaccia della riga di comando.

Eccezione:

main.CRITICAL: eccezione "BadMethodCallException" con messaggio "Argomento richiesto mancante $ debugHintsPath di Magento \ Developer \ Model \ TemplateEngine \ Plugin \ DebugHints." in /.../.../magento/vendor/magento/framework/ObjectManager/Factory/Dynamic/Developer.php:45

Il problema si stava verificando anche solo quando si tenta di chiamare un blocco tramite layout dall'interno del modello. Non appena la chiamata di blocco è stata rimossa, l'eccezione ha smesso di essere visualizzata.

File modello:

app / code / namespace / modulo / 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"}}

L'e-mail è stata ancora inviata con l'oggetto intatto ma l'intero contenuto non è stato visualizzato e solo l'errore riportato di seguito è stato visualizzato nella sezione del contenuto una volta ricevuta l'email.

Errore stampato nelle e-mail:

Modello di filtro errori: Argomento richiesto mancante $ debugHintsPath di Magento \ Developer \ Model \ TemplateEngine \ Plugin \ DebugHints.

Risposte:


16

Ho finalmente trovato la soluzione a questo problema nei forum della community di Magento, forniti da @ dunagan5887 . Ho deciso di condividerlo qui su magento.stackexchange.com poiché molti potrebbero beneficiare di una soluzione ben riferita a questa eccezione.

C'è un link al post originale del forum della community: modello di email con blocco

Sembra che questa soluzione, come citato da @ dunagan5887 ;dictates that the di.xml directive set in vendor/magento/module-developer/etc/adminhtml/di.xml is loaded.

La soluzione consiste in questa semplice riga di codice:

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


Di seguito trovi una classe della riga di comando della versione funzionante:

app / code / namespace / modulo / 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();
    }

    ...

}

È sufficiente modificare l'area da frontenda admino globalcome richiesto dall'applicazione.


[AGGIORNARE]

Area che adminhtmlcausa errori di distribuzione del contenuto statico

Sembra che per alcuni motivi l'impostazione dell'area adminhtmlsia causa alcuni errori durante la distribuzione di contenuti statici.

Abbiamo riscontrato errori come i seguenti:

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

Inizialmente pensavo che questo errore sarebbe stato causato da un'impostazione bassa max_allowed_packetper MYSQL ma dato che il limite era già abbastanza alto e aumentandolo non si stava risolvendo il problema, ho deciso di approfondire. Dopo aver attraversato un processo di eliminazione ho finalmente scoperto che questa era la differenza principale tra due moduli che utilizzavano funzioni di comando simili, da cui uno dei moduli stava causando questo problema non appena abilitato.

Anche se non ho scavato per trovare la fonte di questo problema o conflitto, ho pensato che sarebbe stata una buona idea condividere qui i miei risultati poiché altri potrebbero trovarlo utile.


[AGGIORNAMENTO - 2]

Il metodo giusto:

Dopo aver aggiornato Magento a 2.2.X ci siamo resi conto che questo è il metodo giusto per impostare l'area:

app / code / namespace / modulo / 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

        ...

    }

    ...

}

Si noti che non utilizziamo l'Object Manager e che l'area deve essere impostata all'interno della funzione che lo richiede e NON nel costruttore. Questo è il modo ufficiale di impostare l'area e dovrebbe funzionare perfettamente con tutte le versioni di Magento 2.


Un elenco delle aree disponibili è disponibile nella seguente classe:

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';

    ...

Grazie mille @ElGatito. Mi salvi la giornata. :) Grazie ancora un diario
Ankit Shah,

Ho impostato l'ambito come globale e funziona bene per me.
Rakesh Jesadiya,

1
ATTENZIONE: NON usare quel codice ( $objectManager->configure($configLoader->load('frontend'));) nel costruttore di una classe! Se lo fai e carichi la configurazione da un'area diversa rispetto alla tua area corrente, questo può danneggiare gravemente Magento 2!
Wesley Vestjens,

@Wesley Vestjens +1 Grazie per il tuo commento. Il metodo giusto è in realtà molto diverso e ho aggiornato la mia risposta per riflettere. Fare riferimento a [AGGIORNAMENTO - 2] .
ElGatito,

In realtà, la semplice impostazione dell'area non funziona se si utilizza qualsiasi parte del livello di visualizzazione di Magento 2 (necessario per generare file PDF in Magento 2). Verrà visualizzato un errore relativo al seguente oggetto: Magento\Developer\Model\TemplateEngine\Plugin\DebugHintsperché la debugHintsPathvariabile non è impostata. L'uso del codice originale per caricare l'area ADMINHTML DI funziona o la configurazione manuale della debugHintsPathvariabile funziona, ma potrebbero esserci altre parti rotte. Questo è in realtà un "bug" in Magento, perché non è possibile utilizzare gli elementi del livello di visualizzazione nella CLI.
Wesley Vestjens,

6

Poiché l'interfaccia della riga di comando in Magento non dispone di un'area appropriata, ho capito la seguente soluzione alternativa:

app / code / namespace / modulo / 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>
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.