In this guide we will take a closer look at the configuration file
This file is in the root folder of a shopware installation. Normally it is generated during the
installation process and filled with your database credentials.
It should look like this:
<?php return [ 'db' => [ 'username' => 'yourUsername', 'password' => 'yourPassword', 'dbname' => 'yourDbname', 'host' => 'yourHost', 'port' => 'yourPort' ], ];
During this guide you will get to know some important options of the configuration.
For a complete list of options you can look at the
which holds all possible configuration options and their default values. You only
need to specify options in your
config.php if you want to override the defaults.
But keep in mind that most of these options should only be used for debugging and testing and should be removed for your live system.
To be able to set different configs for different environments, you can place a file called
config_ENVIRONMENT.php in the Shopware root directory.
ENVIRONMENT should be replaced with the environment the kernel gets initialized and defaults to
config_production.php. The environment-specific config file is preferred over the normal one.
Blog post with a more advanced use case: Configuring multiple Shopware environments
As of Shopware 5.2.13 session locking is enabled by default. This prevents unsuspected failures when concurrent ajax requests work with the same session variables. With enabled locking ajax requests are processed one after another.
'session' => [ ... 'locking' => true, ],
'csrfProtection' => [ 'frontend' => true, 'backend' => true ],
With these options you can activate/deactivate the CSRF attack protection. By default, both options are set
true. Deactivating them is for example necessary if you want to run mink tests
with behat. For more information take a look at the complete guide: CSRF Protection
'phpsettings' => [ 'error_reporting' => E_ALL & ~E_USER_DEPRECATED, 'display_errors' => 0, 'date.timezone' => 'Europe/Berlin', ],
These PHP settings override the defaults of your
display_errors is the only important option to change for debugging. Set this to
1 to enable the output
of low-level php errors.
The default value of
error_reporting should be sufficient for developing.
'front' => [ ... 'throwExceptions' => false, 'showException' => false, ],
The difference between
showException is how an exception will be handled.
showException keeps the Shopware error handler enabled, catches the PHP exception and prints the message instead of showing the generic "Oops! An error has occurred!" message.
In contrast, the option
throwExceptions skips the Shopware error handler and outputs the pure PHP exception. This is important to understand, because some errors need to be caught by the Shopware error handler for self-healing processes e.g. CSRF Token invalidation.
'template' => [ ... 'forceCompile' => false, ... ],
This option controls the smarty template caching. Normally you have to clear your cache after every change on the template, but if you set
true your template will be compiled on every reload. This should be an essential option for every developer. Keep in mind that it does have a great impact on loading times and should never be used in production.
'template_security' => [ 'php_modifiers' => ['shell_exec', 'strpos'], 'php_functions' => ['shell_exec', 'strpos'], ],
This option is available since version 5.2.26 and controls the smarty security configuration. Normally shopware has a whitelist of allowed php modifiers and functions for smarty template, but if you need additional php function in your template, you can extend the whitelist by this configuration.
'cache' => [ 'backend' => 'auto', 'backendOptions' => [ ... ], 'frontendOptions' => [ ... ] ],
These settings configure the caching implementation to be used inside of Shopware as well as everything necessary to set up that implementation. The
backend option defines which cache implementation the cache should use, the available implementations can be found in
backendOptions configure the settings for the selected cache implementation. A list of available settings can be found at the
$_options member of the main class
Zend_Cache_Backend and the respective backend class.
frontendOptions work similar to the
backendOptions, you can find the available settings in the classes in
'httpcache' => [ 'enabled' => true, 'debug' => false, ... ],
With these options you can set the HTTP Cache base configuration. For debugging we only take a look at the
debug option and set it to
true. If you want to learn more about the other options you can take a closer look on the complete guide: HTTP cache
<?php return [ 'db' => [ 'username' => 'yourUsername', 'password' => 'yourPassword', 'dbname' => 'yourDbname', 'host' => 'yourHost', 'port' => 'yourPort' ], 'front' => [ 'throwExceptions' => true, 'showException' => true ], 'phpsettings' => [ 'display_errors' => 1 ], 'template' => [ 'forceCompile' => true ], 'csrfProtection' => [ 'frontend' => true, 'backend' => true ], 'httpcache' => [ 'debug' => true ] ];
With Shopware 5.3 it is possible to use redis as cache adapter:
'model' => [ 'redisHost' => '127.0.0.1', 'redisPort' => 6379, 'redisDbIndex' => 0, 'cacheProvider' => 'redis' ], 'cache' => [ 'backend' => 'redis', // e.G auto, apcu, xcache 'backendOptions' => [ 'servers' => [ [ 'host' => '127.0.0.1', 'port' => 6379, 'dbindex' => 0, 'redisAuth' => '' ], ], ], ]
Be aware, that for Zend_Cache::CLEANING_MODE_ALL the cache implementation will issue "FLUSHDB" and therefore clear the current redis db index. For that reason, the db index for the cache should not be used for persistent data.