Magento2: 2.1.9 | Problem with switching to production mode

[test432400]

When I switch to the production mode, I get the problem with incorrect functioning of website.
The default language is Russian, but when i switch to the production mode, the language became English and site begin to work incorrectly.
When i go to the main page, i get 404 error. Some links on page lead to admin panel and they look like this:
https://m.repka.ua/admin/catalog/category/view/s/hdd-ssd-odd/id/1358/key/d429b96370ff46da296b33c18fe3ea94ce4ee4ae149d864dbdd8886032f9259b/products/noutbuki/
Correct link should be https://m.repka.ua/products/noutbuki/
I think that most likely the back-end method getUrl() works, when forming the URL

Preconditions

1. I use Magento version 2.1.9

Steps to reproduce

1. Switch website to the production mode
2. Go to Main page

Expected result

Correct work of the site without errors

Actual result

1. Incorrect working of main page with 404 error.
2. Automatic switching to English, although the default language is Russian.
3. The errors appeared in the browser's console.
4. Some links lead to admin panel.
   

[maksymcherevko]

For now, I can't figure out why, but after get compiled objects:
$this->_objectManager->configure($this->_configLoader->load($areaCode));
app starting work in "backend" mode.

While
$areaCode == 'frontend'
but, for example:
$this->pathConfig->getDefaultPath() is instance of Magento\Backend\Model\AdminPathConfig

[orlangur]

Do you have any URL building customization? Generally, such behavior is unlikely to be observed on clean Magento installation, try to disable all non-core modules and themes and check how switching to production mode works, then try to locate problematic customization.

[maksymcherevko]

try to disable all non-core modules and themes

Interestingly, classes of disabled modules (by bin/magento module:disable) after re-compile still remain in the di-files.

[orlangur]

Even if you remove var/*? Are those modules shown as disabled in bin/magento module:status?

[maksymcherevko]

@orlangur, yes, yes. As always, I cleaned all the necessary folders before re-compile.

Also, having skimmed through the 'frontend.ser', I noticed a lot of the backend's context (Magento\Backend\App\Action\Context). I don't know yet whether it's important or not, I'm still thinking about this.

[maksymcherevko]

Do you have any URL building customization?

@orlangur, I don't think that any customization of URL could affect, since when processing routers they already contain backend classes...

Not compiled:

Compiled:

What else is interesting, so "backend" is already present in compiled files (on Magento\Framework\App\Router\Base):

View:
a:9:{s:10:"actionList";a:1:{s:3:"_i_";s:39:"Magento\Framework\App\Router\ActionList";}s:13:"actionFactory";a:1:{s:3:"_i_";s:35:"Magento\Framework\App\ActionFactory";}s:11:"defaultPath";a:1:{s:3:"_i_";s:31:"Magento\Backend\App\DefaultPath";}s:15:"responseFactory";a:1:{s:3:"_i_";s:37:"Magento\Framework\App\ResponseFactory";}s:11:"routeConfig";a:1:{s:3:"_i_";s:34:"Magento\Framework\App\Route\Config";}s:3:"url";a:1:{s:3:"_i_";s:25:"Magento\Backend\Model\Url";}s:8:"routerId";a:1:{s:3:"_v_";s:8:"standard";}s:11:"nameBuilder";a:1:{s:3:"_i_";s:34:"Magento\Framework\Code\NameBuilder";}s:10:"pathConfig";a:1:{s:3:"_i_";s:37:"Magento\Backend\Model\AdminPathConfig";}}

[orlangur]

Do you have any URL building customization?

since when processing routers they already contain backend classes...

Well, that's exactly what could happen due to customization: some preference for class or class argument in di.xml.

Try to dump the resulting merged DI configuration XML within compilation.

$this->pathConfig->getDefaultPath() is instance of Magento\Backend\Model\AdminPathConfig

skimmed through the 'frontend.ser', I noticed a lot of the backend's context (Magento\Backend\App\Action\Context)

All such declarations cannot come from nowhere, either default declaration from constructor signature is used or it is overridden in some di.xml.

[maksymcherevko]

@orlangur, thanks for helping, I'll try.

[maksymcherevko]

@orlangur, for example i took class Magento\Framework\UrlInterface and added the next line:

echo PHP_EOL . $areaCode . ' <=> ' . $areaConfig->getPreference('Magento\Framework\UrlInterface') . PHP_EOL;

in the method Magento\Setup\Module\Di\Compiler\Config->generateCachePerScope() to check, what preference is taken for UrlInterface class. Result:

I decided to look up this class name in all di-files and found the next record:

<preference for="Magento\Framework\UrlInterface" type="Magento\Backend\Model\UrlInterface" />

in vendor file: /public_html/vendor/magento/module-backend/etc/adminhtml/di.xml, in adminhtml section!

After comment this row:

i got the next:

I think, that in my case the compiler does not distinguish area codes, something like this. Maybe you have any idea about this?

[maksymcherevko]

Found a problem module... It works with the console commands and similar errors:

which were solved (for some reason...) by configure objectManager:

$objectManager->configure(
$configLoader->load(\Magento\Framework\App\Area::AREA_ADMINHTML)
);

This was the reason for the "problematic" compilation. After removal of this row, the compilation is successful:

global <=> Magento\Framework\UrlInterface <=> Magento\Framework\Url
frontend <=> Magento\Framework\UrlInterface <=> Magento\Framework\Url
setup <=> Magento\Framework\UrlInterface <=> Magento\Framework\Url
adminhtml <=> Magento\Framework\UrlInterface <=> Magento\Backend\Model\Url
crontab <=> Magento\Framework\UrlInterface <=> Magento\Framework\Url
webapi_rest <=> Magento\Framework\UrlInterface <=> Magento\Framework\Url

[magento-engcom-team]

@vladpankeev, thank you for your report.
We were not able to reproduce this issue by following the steps you provided. If you'd like to update it, please reopen the issue.

[orlangur]

@maksymcherevko glad to know root cause was found after all.

Just for the reference, here is the right way to achieve what was achieved wrongly by ObjectManager configuration: https://magento.stackexchange.com/a/96830/40869

[maksymcherevko]

@orlangur, thanks for your support in my issue :)

The only thing, that I did't fully understand, is that disabled modules is included in the compilation files. It right or wrong.

[orlangur]

disabled modules is included in the compilation files

I don't think it is correct but I didn't check implementation if it was done for purpose. Many other configuration types, like layouts or templates, are ignored for disabled modules.

If you'll manage to produce an isolated case demonstrating this issue, please report it.