Thanks to Nicolas Batty (who seems to have the good sense to live offline) for a correction to the old Magento 2: Fixing Area code Not Set Exceptions quickies post. In the original post I’d recomended a fix for area code not set errors in Magento 2 CLI command by doing something like the following
public function __construct(
\Magento\Framework\App\State $appState,
$name=null
)
{
// don't do this. No really, don't, it's here as a bad example. But why am I even
// saying this -- if you're reading this you're probably not to sort to just blindly
// copy/paste something.
$appState->setAreaCode('frontend');
parent::__construct($name);
}
While this area setting works OK for a Magento web request, it has some unintended consequences when Magento bootstraps its Symfony Console instance. Namely — when you run a bin/magento ...
command, Magento instantiates every an object from every command class it knows about.
This means by introducing the above code you’re changing the area when every command runs, which (in turn) might create unexpected behavior in the other commands. The updated post now recomends doing that area setting as late as possible (i.e. in the execute
method of the command), and restoring the original area code when you’re done.
Beyond the technical details — this one’s interesting to me for a few reasons.
First — that post’s been up there for two and a half years and no one had noticed (or could be bothered to let me know about) the issue.
Second — this is another example of how a 2008-ish era descision to invent the concept of areas in Magento 1, but then leave the implementaiton/definition incomplete, is still creating problems ten years later.
Third — for all it’s “modernity”, Magento’s automatic constructor dependency injection hides the fact that all those injected objects might (or might not) be single instance objects, and single instance objects are basically global variables and contain all the problems we associate with globals.