J'ai finalement trouvé la solution à ce problème dans les forums de la communauté Magento, fournis par @ dunagan5887 . J'ai décidé de le partager ici sur magento.stackexchange.com car beaucoup peuvent bénéficier d'une solution bien référencée à cette exception.
Il existe un lien vers le message original du forum communautaire: modèle d'e - mail avec bloc
Il semble que cette solution, citée par @ dunagan5887 ;dictates that the di.xml directive set in vendor/magento/module-developer/etc/adminhtml/di.xml is loaded.
La solution consiste en cette simple ligne de code:
$ this -> _ objectManager-> configure ($ this -> _ configLoader-> load ('adminhtml'));
Veuillez trouver une classe de ligne de commande de version fonctionnelle ci-dessous:
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();
}
...
}
Il suffit de changer la zone de frontendla adminou globaltel que requis par votre application.
[MISE À JOUR]
Zone adminhtmlprovoquant des erreurs de déploiement de contenu statique
Il semble que pour certaines raisons, la définition de la zone adminhtmlprovoque des erreurs lors du déploiement du contenu statique.
Nous avons vu des erreurs comme les suivantes:
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
J'ai d'abord pensé que cette erreur serait causée par un max_allowed_packetparamètre bas pour MYSQL, mais comme la limite était déjà suffisamment élevée et que l'augmentation ne résolvait pas le problème, j'ai décidé de creuser davantage. Après avoir traversé un processus d'élimination, j'ai finalement découvert que c'était la principale différence entre deux modules utilisant des fonctions de commande similaires, dont l'un des modules provoquait ce problème dès qu'il était activé.
Bien que je n'aie pas creusé pour trouver la source de ce problème ou conflit, j'ai pensé que ce serait une bonne idée de partager mes conclusions ici car d'autres pourraient le trouver utile.
[MISE À JOUR - 2]
La bonne méthode:
Après la mise à niveau de Magento vers 2.2.X, nous avons réalisé que c'était la bonne méthode pour définir la zone:
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
...
}
...
}
Notez que nous n'utilisons pas le gestionnaire d'objets et que la zone doit être définie dans la fonction qui le requiert et NON dans le constructeur. C'est la façon officielle de définir la zone et cela devrait fonctionner parfaitement avec toutes les versions de Magento 2.
Une liste des zones disponibles est disponible dans la classe suivante:
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';
...
$objectManager->configure($configLoader->load('frontend'));) dans le constructeur d'une classe! Si vous faites et chargez la configuration à partir d'une zone différente de votre zone actuelle, cela peut sérieusement casser Magento 2!Magento\Developer\Model\TemplateEngine\Plugin\DebugHintscar ladebugHintsPathvariable n'est pas définie. L'utilisation de votre code d'origine pour charger la configuration DI de la zone ADMINHTML fonctionne, ou la définition manuelledebugHintsPathdes travaux de variable, mais il peut y avoir d'autres pièces cassées. Il s'agit en fait d'un "bug" dans Magento, car il n'est pas possible d'utiliser des éléments de couche de vue dans CLI.Comme CLI dans Magento n'a pas de zone appropriée, j'ai trouvé la solution de contournement suivante:
la source