magento2: Admin panel not working if I install any custom modules in Magento 2.2.0

Has anyone found a permanent solution of this issue? I am facing this issue randomly in Magento 2.3.1 EE version.

I had a similar issue just and was down to a carrage return in a layout file

By chaning from

<?xml version="1.0" ?>
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">

to

<?xml version="1.0" ?>
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">

The error dissapeared very strange but i have seen this on a number of occasions not only this issue but generation issues

I was experiencing this issue, and was even able to solve it by deleting (read: re-naming) generated/metadata/global.php also worked for a little while, but the issue did eventually did appear again, on another admin page.

My store is on a linux server, so I wasn’t buying the xampp/windows theory. However, I do develop on windows using PHPstorm. And I know that PHP storm will sometimes break lines to “clean up” code, so that seemed like a more plausible theory.

I used a regex search in app/code/ to find any of my extensions that matched http://www.w3.org/2001/XMLSchema-instance"\n, and discovered there was a layout XML for a module that related to what page I was getting the error. I removed the newline, and everything was back to normal.

I then built a regex to see if there are other XML layout files that have this newline: find . -path "*/layout/*.xml" -exec grep -lir "http://www.w3.org/2001/XMLSchema-instance\"" {} + and it turned out there are a lot of core files that have this, which might explain why some people have this issue on clean installs. What I can’t explain is why it isn’t more widespread, or why it is even an issue.

More testing is necessary.

@C4rter The issue doesn’t need to be caused by Windows/Xampp. Maybe there’s just some kind of a bug in Magento which reveals itself only on Windows/Xampp (e.g. because of how Windows handles file permissions, or something like that).

I’ve had an extensive debugging session and I had some insights into the issue. But no solution. The issue seems to be that the backend theme is not properly created when this issue is happening. The trace differs early on and Magento tries to create the backend theme a different way with or without the global.php.

I think the key is this file: vendor\magento\module-theme\Model\View\Design.php

When the issue is happening Magento never “sets” the theme. It just gets it at some point and because it’s not there it’s created on the fly, which creates a faulty theme.

public function getDesignTheme()
    {
        if ($this->_theme === null) {
            $this->_theme = $this->_themeFactory->create();
        }
        return $this->_theme;
    }

When calling getDesignTheme without a theme set before it creates a theme that just consists of one field “type” with the value of 1.

When the issue is not happening the theme is created differently by setting it. In this function:

public function setDesignTheme($theme, $area = null)
    {
        if ($area) {
            $this->setArea($area);
        } else {
            $area = $this->getArea();
        }
        if ($theme instanceof \Magento\Framework\View\Design\ThemeInterface) {
            $this->_theme = $theme;
        } else {
            $this->_theme = $this->_flyweightFactory->create($theme, $area);
        }
        return $this;
    }

The code runs through the “else” part of the second if condition. That creates a proper theme.

It seems like none of the plugins that are in place before and during theme creation are called when the issue is happening. As I mentioned the trace differs in both cases:

Faulty trace:

Working trace:

Debugger will show. If you tried to clean everything up (caches, var/*, generated/*) it’s hard to guess what else may be broken.

What could cause that? It’s clean installation.