Magento2 - Baris Perintah - Mengirim Email Menggunakan Blokir Template - Kesalahan: Argumen yang diperlukan tidak ada $ debugHintsPath


11

Ketika mencoba mengirim email di Magento 2 dari command-line, saya menemukan pengecualian di bawah ini. Saat menggunakan kelas yang sama untuk mengirim email dari frontend atau backend controller berfungsi dengan baik. Masalah ini terjadi dengan menggunakan antarmuka baris perintah.

Pengecualian:

main.CRITICAL: exception 'BadMethodCallException' dengan pesan 'Argumen yang diperlukan tidak ada $ debugHintsPath of Magento \ Developer \ Model \ TemplateEngine \ Plugin \ DebugHints.' di /.../.../magento/vendor/magento/framework/ObjectManager/Factory/Dynamic/Developer.php:45

Masalah ini juga hanya terjadi ketika mencoba memanggil blok melalui tata letak dari dalam templat. Segera setelah panggilan blok dihapus, pengecualian berhenti muncul.

File Templat:

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"}}

Email masih dikirim dengan baris subjek utuh tetapi seluruh konten tidak diterjemahkan dan hanya kesalahan di bawah ini yang ditampilkan di bagian konten setelah email diterima.

Kesalahan dicetak di dalam email:

Templat pemfilteran kesalahan: Tidak ada argumen yang diperlukan $ debugHintsPath dari Magento \ Developer \ Model \ TemplateEngine \ Plugin \ DebugHints.

Jawaban:


16

Saya akhirnya menemukan solusi untuk masalah ini di Forum Komunitas Magento, yang disediakan oleh @ dunagan5887 . Saya memutuskan untuk membagikannya di sini di magento.stackexchange.com karena banyak orang dapat mengambil manfaat dari solusi yang dirujuk dengan baik untuk pengecualian ini.

Ada tautan ke pos Forum Komunitas asli: Template email dengan blok

Tampaknya solusi ini, seperti dikutip oleh @ dunagan5887 ;dictates that the di.xml directive set in vendor/magento/module-developer/etc/adminhtml/di.xml is loaded.

Solusi Terdiri dari Baris Kode Sederhana ini:

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


Temukan kelas baris perintah versi yang berfungsi di bawah:

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();
    }

    ...

}

Cukup ganti area dari frontendke adminatau globalsesuai kebutuhan oleh aplikasi Anda.


[MEMPERBARUI]

Area yang adminhtmlmenyebabkan kesalahan penggunaan konten statis

Tampaknya karena beberapa alasan mengatur area ke adminhtmlmenyebabkan beberapa kesalahan saat menyebarkan konten statis.

Kami melihat kesalahan seperti berikut:

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

Saya awalnya berpikir bahwa kesalahan ini akan disebabkan oleh max_allowed_packetpengaturan yang rendah untuk MYSQL tetapi karena batasnya sudah cukup tinggi dan meningkatkannya tidak menyelesaikan masalah, saya memutuskan untuk menggali lebih jauh. Setelah melalui proses eliminasi saya akhirnya menemukan bahwa ini adalah perbedaan utama antara dua modul menggunakan fungsi perintah yang sama, dari mana salah satu modul menyebabkan masalah ini segera setelah diaktifkan.

Meskipun saya belum menggali untuk menemukan sumber masalah atau konflik ini, saya pikir akan lebih baik untuk berbagi temuan saya di sini karena orang lain mungkin merasa berguna.


[PEMBARUAN - 2]

Metode yang tepat:

Setelah memutakhirkan Magento ke 2.2.X kami menyadari bahwa ini adalah metode yang tepat untuk mengatur area:

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

        ...

    }

    ...

}

Perhatikan bahwa kami tidak menggunakan Object Manager dan bahwa area tersebut harus diatur dalam fungsi yang membutuhkannya dan BUKAN dalam konstruktor. Ini adalah cara resmi pengaturan area dan harus bekerja dengan sempurna dengan semua versi Magento 2.


Daftar area yang tersedia tersedia di kelas berikut:

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

    ...

Terima kasih banyak @ ElGatito. Kamu menghemat hariku. :) Terima kasih log lagi
Ankit Shah

Saya telah menetapkan ruang lingkup sebagai global dan berfungsi dengan baik untuk saya.
Rakesh Jesadiya

1
PERINGATAN: JANGAN gunakan kode itu ( $objectManager->configure($configLoader->load('frontend'));) di konstruktor kelas! Jika Anda melakukannya dan memuat konfigurasi dari area yang berbeda dari area Anda saat ini, ini dapat merusak Magento 2!
Wesley Vestjens

@Wesley Vestjens +1 Terima kasih atas komentar Anda. Metode yang tepat sebenarnya sangat berbeda dan saya telah memperbarui jawaban saya untuk mencerminkannya. Silakan lihat [UPDATE - 2] .
ElGatito

Sebenarnya, hanya mengatur area tidak berfungsi jika Anda menggunakan bagian mana pun dari lapisan tampilan Magento 2 (yang diperlukan untuk membuat file PDF di Magento 2). Anda akan mendapatkan kesalahan mengenai objek berikut: Magento\Developer\Model\TemplateEngine\Plugin\DebugHintskarena debugHintsPathvariabel tidak disetel. Menggunakan kode asli Anda untuk memuat area ADMINHTML konfigurasi DI berfungsi, atau secara manual mengatur debugHintsPathvariabel berfungsi, tetapi mungkin ada bagian yang rusak lainnya. Ini sebenarnya adalah "bug" di Magento, karena tidak mungkin menggunakan elemen tampilan layer di CLI.
Wesley Vestjens

6

Karena CLI di Magento tidak memiliki area yang sesuai, saya menemukan solusi berikut:

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>
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.