Service Container

The OXID eShop uses the Symfony DI Container to handle services.

For more information about the DI Container, see the Symfony DI Container documentation.

You can use the services described in modules and OXID eShop components. You can use the services in multiple ways:

Creating services

There is a step-by-step instruction 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, components 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 the ContainerFactory class to get a service. The service you want to get must be marked as public.

  Example:

  $moduleActivationService = ContainerFacade::get(ModuleActivationBridgeInterface::class);
  

Important

Consider the hints in the Stable OXID eShop Core Services section.

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 MyProject\CustomLogger, 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.

Make sure to always use the .yaml file extension, not .yml.

Important

Consider the hints in the Stable OXID eShop Core Services section.

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.

Reason: It could be used in the shop or modules as before. This 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 anymore.

Defining shop-specific system services

If you need a service specifically for a single eShop and do not want to apply it to all eShops, define/override the system services per store.

To do so, under var/configuration/shops/[SHOP_ID], create a file named configurable_services.yaml.

For the content and structure of the yaml file see the previous example under Replacing OXID eShop services in a project.

Example of the full path: var/configuration/shops/[SHOP_ID]/configurable_services.yaml

Using Stable OXID eShop Core Services

We do not recommend using or overwriting 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, see the README.md file in the internal directory.

Clearing the Service Container Cache

Normally, the container factory will get the container from a container cache file.

It resides in the tmp directory of your application and is called container_cache.php.

If this file is not found, the container will be set up fresh from its configuration.

If you change something in the container configuration, you need to delete container_cache.php to get a container that reflects your changes.