In our guide on how to add a plugin configuration, you can learn how to provide this possibility to use configuration options in your plugins. This guide will aid you on how to then use this configuration in your plugin.
In order to add a plugin configuration, you sure need to provide your plugin first. However, you won't learn to create a plugin in this guide. Head over to our plugin base guide to create your plugin first. It is also recommended to know how to setup a plugin configuration in the first instance. In this example, the configurations will be read inside of a subscriber, so knowing the Listening to events guide will also be helpful.
The plugin in this example already knows a subscriber, which listens to the product.loaded event and therefore will be called every time a product is loaded.
Just a simple input field with the technical name example. This will be necessary in the next step.
Reading the configuration
Let's get to the important part. Reading the plugin configuration is based on the Shopware\Core\System\SystemConfig\SystemConfigService. This service is responsible for reading all configs from Shopware 6, such as the plugin configurations.
Inject this service into your subscriber using the DI container.
So far, so good. The SystemConfigService is now available in your subscriber.
This service comes with a get method to read the configurations. The first idea would be to simply call $this->systemConfigService->get('example') now, wouldn't it? Simply using the technical name you've previously set for the configuration.
But what would happen, if there were more plugins providing the same technical name for their very own configuration field? How would you access the proper field, how would you prevent plugin conflicts?
That's why the plugin configurations are always prefixed. By default, the pattern is the following: <BundleName>.config.<configName> Thus, it would be SwagBasicExample.config.example here.