Service Container

The OXID eShop uses the Symfony DI Container to handle services. For more information about DI Container refer to the Symfony DI Container documentation

Services can be used in modules and OXID eShop components. You can use services in multiple ways:

Creating services 

There is a step by step instructions for modules but the instructions are the same for components. Modules need to be activated in order to make the services included working in contrast to components which just need to be installed by composer.

Getting services 

Getting services via injecting it through the constructor as a dependency. Use this way whenever possible (inside another service).

Getting services using service locator. You can use ContainerFactory class to get a service. The service you want to get has to be marked as public.

Example:

$containerFactory = ContainerFactory::getInstance();
$container = $containerFactory->getContainer();
$moduleActivationService = $container->get(ModuleActivationBridgeInterface::class);

Important

Please consider the hints in the section Stable OXID eShop Core Services.

Replacing OXID eShop services in a project 

In some cases you might need to change system services behaviour. Creating a replacement for OXID eShop system services should be done in a OXID eShop Component and not in a module.

You can overwrite system services in your project. For this purpose there is a file named configurable_services.yaml, which you will find (or will have to create) under var/configuration. This file exists exactly once per project. Do not use any other way of replacing OXID eShop services!

Example of var/configuration/configurable_services.yaml file:

services:
  Psr\Log\LoggerInterface:
    class: MyProject\CustomLogger

In the example, the OXID eShop Service PsrLogLoggerInterface is set as the key and will be replaced by our custom implementation MyProjectCustomLogger, which is specified by the class parameter.

Note

There are several possibilities to configure the Symfony DI container. OXID framework only uses and supports the yaml file format. In addition always use file extension .yaml, not .yml.

Important

Please consider the hints in the section Stable OXID eShop Core Services.

Important

If we want to overwrite already existent service and it is a public service, a new service should be also set as public. In fact the services should have the same visibility. The reason is, it could be used in the shop or modules as before, it means maybe we have already used it as public in the shop or modules and if we make it private in the new service, they will not work any more.

Stable OXID eShop Core Services 

We do not recommend to use or overwrite system services in internal directory, unless services have @stable annotation. Services which are not marked as stable might change more often in future releases. For more information refer to README.md file in internal directory.