Magento2: Import failed: Area code not set: Area code must be set before starting a session.

[springerin]

Preconditions

1. Magento 2.2.3 or 2.2.4
2. PHP 7.1.18
3. Ubuntu 16.04.4 LTS
4. mysql Ver 14.14 Distrib 5.7.22-22, for debian-linux-gnu (x86_64) using 6.3

Steps to reproduce

1. clean install of Magento 2.2.3 or 2.2.4
2. bin/magento app:config:dump
3. bin/magento app:config:import
4. change only the base_url in the env.php files
   'web' => array ( 'unsecure' => array ( 'base_url' => 'http://m223ee.ffm/', 'base_link_url' => '{{unsecure_base_url}}',
5. bin/magento app:config:import

Expected result

1. Expected output :
   Processing configurations data from configuration file...
   System config was processed

Actual result

1. Output: Processing configurations data from configuration file...
   Import failed: Area code not set: Area code must be set before starting a session.
2. var/log/exception.log:

report.ERROR: Area code not set: Area code must be set before starting a session. {"exception":"[object] (Magento\Framework\Exception\State\InvalidTransitionException(code: 0): Area code not set: Area code must be set before starting a session. at /home/springerin/Workspace/Progetti/m224ee/vendor/magento/module-config/Model/Config/Importer.php:137, Magento\Framework\Exception\SessionException(code: 0): Area code not set: Area code must be set before starting a session. at /home/springerin/Workspace/Progetti/m224ee/vendor/magento/framework/Session/SessionManager.php:175, Magento\Framework\Exception\LocalizedException(code: 0): Area code is not set at /home/springerin/Workspace/Progetti/m224ee/vendor/magento/framework/App/State.php:152)"} []

[ananth-iyer]

From the env.php file you had manually setting store url and Area code means store/website id.

You have to set MAGE_RUN_TYPE & MAGE_RUN_CODE in the index.php
MAGE_RUN_TYPE means store or website

Reference to setup multiple stores or websites: https://devdocs.magento.com/guides/v2.2/config-guide/multi-site/ms_over.html

[springerin]

@ananth-iyer I think you misunderstood the issue and your answer doesn't really relate to the bug since is something wrong with the cli command and not with the frontend. Plus modifying the index.php as in the guide you're referencing to says, isn't the only way to go.

[engcom-backlog-nickolas]

Hello @springerin, thank you for your report.
We've acknowledged the issue and added to our backlog.

[joeshelton-wagento]

I was able to work around the issue by deleting the system_config_snapshot flag.

DELETE FROM flag WHERE flag_code = 'system_config_snapshot';

[nathancasebolt]

@joeshelton-wagento Are you sure re-running setup:upgrade won't regenerate this field? It's been a long time since I dealt with this, and I can't recall for certain.

My problem with this was that I have two development servers, each of which needs their own system => default => web => secure => base_url value. I got around the problem by removing this setting from env.php and sticking it in an $_ENV environment variable. It's kludgy by my lights, but my colleague and I can finally develop concurrently without crashing each other's server.

[joeshelton-wagento]

In my case, I received the same error using either setup:upgrade or app:config:import.

[sezio]

In one year of development under m2, I ran into this issue at least 3 or 4 times on different projects that were using different magento 2 versions (2.0,2.1,2.2.2,2.2.5).
And so far, I never found a clear explanation of what means "Area code not set" or "Area code already set" as sometimes it works and sometimes it does not...
Depending of the environment, I sometimes had to include the framework state in my classes and change the area code, which was working on my dev but not in staging or working in prod but never in staging or dev....

Seriously, how can these area issues can still exists with so much reports on the github for so many time ?
I'm sorry to complaint, usually I would not do this, but I really don't get this... This is a very very annoying issue as it can not be reproduced on every environment and the magento team does not seems to take care of it.

Anyway... still getting this with a setup:upgrade in staging but was working fine on my dev....

[nathancasebolt]

I've triggered this error when building custom console commands. To get past it, I had to try to set the area code explicitly and catch a LocalizedException:

class FoobarCommand extends \Symfony\Component\Console\Command\Command
{
    private $state;

    public function __construct(\Magento\Framework\App\State $state)
    {
        $this->state = $state;
        parent::__construct();
    }

    // do configuring stuff

    protected function execute(\Symfony\Component\Console\Input\InputInterface $input,
                               \Symfony\Component\Console\Output\OutputInterface $output)
    {
        try {
            $this->state->setAreaCode(\Magento\Framework\App\Area::AREA_FRONTEND);
        } catch (\Magento\Framework\Exception\LocalizedException $exception) {
            // do error-catching stuff
        }
        // do processing stuff
    }
}

I'm not getting this error with vanilla Magento, so I can't test or guarantee a solution. That said, the setup:upgrade class instantiates and runs an app:config:import object like so:

$importConfigCommand = $this->getApplication()->find(ConfigImportCommand::COMMAND_NAME);
...
$importConfigCommand->run($arrayInput, $output);

(From _/ vendor / magento / magento2-base / setup / src / Magento / Setup / Console / Command / UpgradeCommand.php_)

So, someone having an area code problem with either app:config:import or setup:upgrade could attempt to set the area code in /vendor/magento/module-deploy/Console/Command/App/ConfigImportCommand.php to see if that gets them past the error, even if duct-taping the core is the furthest thing from a long-term solution.

[mikewhitby]

In one year of development under m2, I ran into this issue at least 3 or 4 times on different projects that were using different magento 2 versions (2.0,2.1,2.2.2,2.2.5).
And so far, I never found a clear explanation of what means "Area code not set" or "Area code already set" as sometimes it works and sometimes it does not...
Depending of the environment, I sometimes had to include the framework state in my classes and change the area code, which was working on my dev but not in staging or working in prod but never in staging or dev....

Seriously, how can these area issues can still exists with so much reports on the github for so many time ?
I'm sorry to complaint, usually I would not do this, but I really don't get this... This is a very very annoying issue as it can not be reproduced on every environment and the magento team does not seems to take care of it.

Anyway... still getting this with a setup:upgrade in staging but was working fine on my dev....

Whilst you may have gotten "Area code not set" as far back as 2.0 and 2.1, this particular issue relates to the pipeline deploy system introduced in 2.2, the issue (as the OP mentions) occurs when you have a base_url in env.php, import it with app:config:import, change it and import again.

I mention this because there are valid reasons for "area code not set" in CLI commands, but that message is a bit of a red herring in this case.

[mikewhitby]

I was able to work around the issue by deleting the system_config_snapshot flag.

DELETE FROM flag WHERE flag_code = 'system_config_snapshot';

This fixed it for me, cheers.

[hostep]

We had to run an extra query (but maybe that is Magento Cloud specific, in our case when moving a database from one environment to the other). And we are just clearing the flag data instead of deleting them entirely, this probably doesn't make a difference, but I'm not entirely sure.
Anyway, maybe it helps:

UPDATE flag SET flag_data = NULL WHERE flag_code = 'system_config_snapshot';
UPDATE flag SET flag_data = NULL WHERE flag_code = 'config_hash';

Credits to @joeshelton-wagento who pointed me in this direction on Slack a couple of months ago :)

[sezio]

In one year of development under m2, I ran into this issue at least 3 or 4 times on different projects that were using different magento 2 versions (2.0,2.1,2.2.2,2.2.5).
And so far, I never found a clear explanation of what means "Area code not set" or "Area code already set" as sometimes it works and sometimes it does not...
Depending of the environment, I sometimes had to include the framework state in my classes and change the area code, which was working on my dev but not in staging or working in prod but never in staging or dev....
Seriously, how can these area issues can still exists with so much reports on the github for so many time ?
I'm sorry to complaint, usually I would not do this, but I really don't get this... This is a very very annoying issue as it can not be reproduced on every environment and the magento team does not seems to take care of it.
Anyway... still getting this with a setup:upgrade in staging but was working fine on my dev....

Whilst you may have gotten "Area code not set" as far back as 2.0 and 2.1, this particular issue relates to the pipeline deploy system introduced in 2.2, the issue (as the OP mentions) occurs when you have a base_url in env.php, import it with app:config:import, change it and import again.

I mention this because there are valid reasons for "area code not set" in CLI commands, but that message is a bit of a red herring in this case.

My bad if what I said was not exact, I ran into this issue on several projects with different versions and I remember having recurring problems on m2.0, m2.1, m2.2 so I probably mixed all it up.
I was really upset after having the problem one more time and not having again something that could explain why it worked in some cases and why it did not in other.

Thanks for correcting me, and sorry for the "red herring", that's not what I wanted to do

Have a nice day

[andrew-knifecenter]

Just wanted to leave this here in case it helps someone. I had this same error and it was actually due to some formatting issues (line breaks) created by the config:dump command. This caused the import parsing to fail and the exception thrown was misleading. Hope this helps someone else!

[Adel-Magebinary]

Try this. I delete generated code and recompile fixed issues.

rm -rf generated
./bin/magento setup:di:compile

[leoquijano]

Don't remove the generated directory directly, as that will wipe out its .htaccess file. That would be a security hazard in Apache-hosted websites.

To remove generated files, use the approach recommended by the dev docs:

cd <your Magento install dir>
rm -rf generated/metadata/* generated/code/*

Note that it removes the _contents_ of the metadata and code directories, not the directories themselves.

[Adel-Magebinary]

Thanks for the tips.

have been nginx fan at all time :)

[leoquijano]

You're welcome. I think it's still a good idea to keep the .htaccess files intact, because you never know if and when a website could be switched over to an Apache server down the line.

[ryantfowler]

In my case, I followed @hostep 's advice here: and had to make sure that there were no values set in my env.php which conflicted with what was saved in the system_config_snapshot value. Again for me, it was having system/default/catalog/search/engine/mysql in my env.php whereas a db dump I was importing had a value in the flag table saved in the system_config_snapshot json. So the gist of my situation was to make sure there's no conflicting values between the two. Hope that helps someone.

[tuyennn]

Just maintain some old extensions,
I'm so confusing while it happened in some custom extension CLI commands(while load product model factory). Even I tried to set or emulate the area code, but no luck at all. Just give up with that dumb.

[Adel-Magebinary]

@tuyennn Magento 2 is pretty hard to develop now days. There are just too many little triggers that might affect the stability of the platform.

I hope Magento team can make this better in the near future.

[DaimPiek]

I recently encountered this issue as well. This time working on a Magento 2.1.X store.

We recently removed all command output in favour of logging. This caused the aforementioned "Area code not set: Area code must be set before starting a session." exception to be thrown.

We fixed this by ensuring the command has output by writing a line to the console. ($output->writeln()).

The issue is the following: when your command has a dependency which somehow injects the SessionManager class, the Magento\Framework\Session\SessionManager::start() function which is called in the constructor. Causes the class to attempt to initialize a session.

The reason why adding output to your console commands solves the problem is that headers are send and the session is never initialized. (Magento\Framework\Session\SessionManager::isSessionExists)

I realize that this does not seem to be a proper future-proof solution, but at least it works!

[kirtinariya1]

@magento-engcom-team Please provide Magento 2.3.1 CE test instance.

[djacques4gorilla]

To give some additional info, I'm getting this error if there is a value for the system_config_snapshot flag. When we attempt to save the flag at vendor/magento/module-config/Model/Config/Importer.php:135 (for 2.2.7), it dispatches the model_save_before event, which is observed by MagentoAdminGws\Observer\ValidateModelSaveBefore. But when the observer factory tries to instantiate it, there is a dependency chain (ValidateModelSaveBefore -> RolePermissionAssigner -> Backend Session) that leads to the creation of MagentoBackendModelAuth\Session\Interceptor, which will call $this->start() in its constructor. This will in turn cause the exception as the application state doesn't have an area code at this point.

However, in Magento 2.2.7 at least, the injected RolePermissionAssigner isn't even in use in that observer, making this a completely unnecessary access to the area code. If we turn it into a proxy, avoiding the instantiation of the session, we can successfully import the configuration data. My recommendation would be the complete removal of that dependency on the observer to improve performance and avoid the bug.

[J-SM]

to overcome this just use State->emulateAreaCode in
InstallShema
InstallData
UpgradeSchema
UpgradeData
& any Console Classes

E.G:

<?php

namespace  ##yournamespace here##

use Magento\Framework\App\State;
use Magento\Framework\App\Area;

class UpgradeSchema implements UpgradeSchemaInterface
{
    /**
     * @var State
     */
    private $appState;

/**
     * UpgradeSchema constructor.
     * @param State $appState
     */
    public function __construct(State $appState)
    {
        $this->appState = $appState;
    }

    /**
     * {@inheritdoc}
     */
    public function upgrade(SchemaSetupInterface $setup, ModuleContextInterface $context)
    {
        $this->appState->emulateAreaCode(
            Area::AREA_FRONTEND,
            [$this, 'upgradeCallback'],
            [$setup, $context]
        );
    }

/**
     * @param SchemaSetupInterface $setup
     * @param ModuleContextInterface $context
     * @throws \Zend_Db_Exception
     */
    public function upgradeCallback(SchemaSetupInterface $setup, ModuleContextInterface $context){
      ##the code that used to be in public function upgrade (i just rename the origional to upgradeCallback##
    }
....
}

[LiamTrioTech]

Also happens in Magento 2.3.0 with multiple sites/webstore/view when trying to install Mageplaza_StoreLocator.

As a temporary work around I modified vendor/magento/framework/Session/SessionManager.php

But agree that emulating the area code in the Setup/Upgrade php classes appears to be the better solution.

Needed to delete the module row from the setup_module table as it had schema-version set but data_version was null.