During the migration of a Shopware 5 system to a containerized environment, an error pattern emerged that initially seemed unusual: The backend loaded, but instead of the usual interface, a Shopware error dialog appeared that completely blocked the user. This error dialog contained:
-
- the actual exception
- a response preview
- browser and system information
Normal operation was not possible.
The following article documents the analysis in detail – from the initial symptom and identification of a problematic third-party plugin to the specific code corrections in two subscriber classes of the NetiFoundation plugin (Vendor: Net Inventors GmbH).
The Error Pattern in the Backend
After logging into the backend, the usual Shopware interface did not appear. Instead, a modal window was displayed immediately:
-
- Title: “An error has occurred”
- Content: a complete stack trace
- Right side: JSON response, system information, user agent
It was not possible to close the dialog – the backend remained blocked.
The error was:
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException:The "auth" service is synthetic, it needs to be set at boot time before it can be used.
This message occurs when a subscriber or service accesses a service too early in the backend boot process or extends templates before Shopware itself has been fully initialized.
Initial Investigation and Elimination Process
The frontend worked without any problems, so it was clear that:
-
- routing works
- PHP-FPM works
- Nginx is running properly
- Shopware core files are not corrupted
However, since an entire block of error messages was being loaded in the backend, it was suspected that a plugin was interfering with the backend rendering process.
Radical Test: Disable All Non-Shopware Plugins
A classic approach for narrowing down the cause:
UPDATE s_core_pluginsSET active = 0, capability_enable = 0WHERE namespace <> 'Shopware';
After clearing the cache:
→ The backend worked again immediately – without the error dialog.
This made it clear: A third-party plugin was causing the blockage.
The plugins were then reactivated step by step.
The result was clear:
Culprit: NetiFoundation (Vendor: Net Inventors GmbH)
As soon as this plugin was activated:
- the error dialog appeared again
- some icons in the backend were missing (e.g. menu icons)
- ExtJS elements did not load completely
- an exception was triggered while initializing the backend
Detailed Analysis: Which Plugin Components Cause the Exception?
The plugin contains numerous Symfony service definitions as well as several event subscribers.
By successively removing/disabling the subscribers, it became clear: Two specific subscribers were causing problems:
1. Subscriber/Backend.php
2. Subscriber/Controller.php
All other subscribers could remain active without triggering any errors.
Cause 1: Incorrect / Outdated Method in the Controller Subscriber
Code excerpt from Subscriber/Controller.php:
$view->getTemplateDir();
Problem:
- This method does not exist in Shopware 5 backend views (it never existed or is no longer available).
- Under classic Linux/Apache, this error is sometimes swallowed.
- Under Docker + PHP-FPM, the error results in an immediate Fatal Error, which triggers the error dialog in the backend.
Solution:
The line must be removed or replaced.
The correct approach is:
addTemplateDir(__DIR__ . '/../Views/', 'NetiFoundation_Controller'); ?>The entire invalid method was removed.
Cause 2: Backend Subscriber Extends a Template Whose Path Is Not Registered
In Subscriber/Backend.php, the following was present:
getSubject()->View()->extendsTemplate('backend/foundation_menu_item.tpl'); ?>
Problem:
- The template exists – but Shopware does not know the path because there was no
addTemplateDir()for the view directory beforehand. - As a result, Smarty attempts to find the template in the existing theme directories → fails → exception.
- As a result, the Shopware error dialog blocks the backend.
Solution:
The template path must be registered before extending the template:
templateManager->addTemplateDir( __DIR__ . '/../Views/', 'NetiFoundation_Backend' ); ?>
and only then perform the extension:
getSubject()->View()->extendsTemplate('backend/foundation_menu_item.tpl'); ?>
Result After Both Corrections
After applying the fixes:
- Backend loads without an error dialog
- Menu icons appear correctly again
- ExtJS loads completely
- PluginManager works
- No more ServiceNotFound exceptions
- No more “synthetic service” error
The NetiFoundation plugin is now fully compatible with the Docker/PHP-FPM environment.
Why Did the Error Only Occur in Docker?
Everything worked without problems on the original server – so why did the error occur in the container?
Technical causes:
-
PHP-FPM handles Fatal Errors more strictly than Apache mod_php.
-
Some PHP warnings or calls to non-existent methods are suppressed in the live system through configuration or error handling.
-
Docker often uses more modern, stricter defaults (e.g. display_errors=0, but strict logging).
-
Shopware always displays backend errors as a modal error window – which is why it was impossible to continue working.
Conclusion
Migrating a system often reveals “sleeping” errors that were never visible on the previous server. In this case:
- an outdated method call (getTemplateDir())
- a missing addTemplateDir() in a backend subscriber
caused the NetiFoundation plugin to interfere with the backend rendering process as early as the initialization phase.
Through targeted analysis and precise corrections, the problem was completely resolved.
If you need support with troubleshooting, plugin optimization, or the technical modernization of your Shopware instance, we are happy to assist you. We develop, analyze, and stabilize complex e-commerce systems and ensure that your shop runs efficiently, securely, and reliably.
