Theme compilation fails for custom themes during system:update:finish

[kleinmann]

In a shop using a custom duplicated theme via a plugin, system:update:finish throws an error "Unable to find theme XXXX" (with XXXX being the name of the custom theme).

After further checking, this occurs because system:update:finish tries a theme compilation, but uses a Kernel without any plugins. Without the plugins, no configuration of the custom theme can be loaded and the compilation fails.

Since the configured duplicated theme has a parent theme, the fallback to the standard Storefront theme is not used (and would be wrong here anyway 🙂).

Steps to reproduce:

1. Create a new theme with bin/console theme:create XXXX
2. Create a duplicate of this theme via administration
3. Use this duplicated theme in a sales channel
4. Run bin/console system:update:finish

Expected result: Command finishes successfully.

Actual result: Error message Unable to find the theme "XXXX".

[aragon999]

Probably related: https://github.com/shopware/production/issues/49

[acydburn]

This happens propably because in system:update:xxx the Kernel is rebooted without any plugins (and a theme is a plugin), This also has other side effects (plugins not able to utilize common symfony methods, for example own configs). But IMO fixing this correctly needs a re-evaluation of the complete update code (or "re-booting without plugins" step).

Just saying... maybe it is something different. ;)

[AndreasA]

Isn't the issue just that the kernel is not cloned prior to being rebooted because otherwise the default kernel is rebooted but what the code actually is intending, is to run pre-update events without plugins but the post should again be run with the full kernel which is not the case as prior to rebooting the kernel it was not cloned.

Not sure, if migrations have to run without plugins, I don't think it should be necessary but if so, this might be a bit more complicated e.g. restore prior kernel or fully reboot kernel instead of clone. However, in that case before calling the post events this should be enough, if the original plugin loader is stored:

    private function rebootKernelWithoutPlugins(): ContainerInterface
    {
        /** @var Kernel $kernel */
        $kernel = $this->container->get('kernel');

        $this->originalPluginLoader = $kernel->getPluginLoader();
        $classLoad = $kernel->getPluginLoader()->getClassLoader();
        $kernel->reboot(null, new StaticKernelPluginLoader($classLoad));

        return $kernel->getContainer();
    }

    private function rebootKernelWithPlugins(): ContainerInterface
    {
        /** @var Kernel $kernel */
        $kernel = $this->container->get('kernel');

        $kernel->reboot(null, $this->originalPluginLoader);

        return $kernel->getContainer();
    }

Can't be 100% sure this works in all cases but it fixes an issue I had regarding this and it is probably not the best solution (maybe create a separate command that runs everything that's necessary without plugins).

[JoshuaBehrens]

Just stumbled upon this again. Isn't it weird to run bin/console in composer.json anyway? I mean I want to run composer install/update to get my system in a different runnable state. This means quite often that I am not in that state before and therefore can't rely on that. Can we maybe just keep that stuff completely out of composer.json and serve a Makefile or psh actions or so? It just feels wrong.

[iNaD]

We call this command on every deployment, to ensure the Shopware migrations are applied. Now the theme was duplicated for another sales channel with different logo. The only workaround seems to create the duplicated theme as a real plugin?

[MarcelSchmaeing]

Hello,

Within our company roadmap and work capacity, we try to address each bug or improvement request but admit that not each one will be resolved. To continue our culture of honesty and openness, we are closing this issue to focus on our roadmap on behalf of all Shopware users.

If you feel like this issue is still impacting you, please create a new issue and let us know. Thank you again for your valuable feedback.